Ask HN: Solo-preneurs, how do you DevOps to save time?

If we're talking a plain saas type deal, I'd keep it simple, elastic bean stalk, or use a heroku or render.com like setup until you grow to the point of hiring a team. If it's just a basic saas, I don't see how a 1 man team could really out grow this setup. I've seen 100 person teams using heroku.

K8s is just way too much work. Even cloud formation is to much for my tiny show.

Use the automated backups setup by your host for your db. If you need to roll back, just redeploy your previous git hash. I typically use GitHub actions to deploy, so rolling back is just a matter of force pushing the prod branch to the sha I want to deploy

Skip micro services, they are too much work for a small time thing, and don't really provide much benefit.

- docker

- dokku

- sqlite

- litestream

I've done this since writing my first CGI app in 2003. And it hasn't changed other than the commands I call. Back then it was manual through GUIs (visual source safe and FTP) and now it is git and scp, but 80% of the process hasn't changed in almost 2 decades.

If it breaks (which it shouldn't, but inevitably does), I just git checkout the previous commit and scp again, and try and fix the issue.

If I have a "high availability" product (which I hate doing), I will release onto a clone of the production server, then test it, swap to that clone, deploy to the others, swap back and kill the clone. It is a much more involved process that I really don't like doing, so I've stopped making high availability applications.

But that is web, so it's super simple. Also to avoid issues regarding data schemas, I always try to make sure my changes are additive. And on startup, my web server checks the database version then runs any upgrade scripts if needed. If the deploy fails, the db changes stay, and the code just gets updated. This is sloppy, but it's simple.

When a real schema change needs to happen, I abandon the project (just kidding). I usually do it in multiple updates. New table with the schema changes, upgrade script transfers the data, and code to point to new table. Manually verify that all of the data copied. Backup the old table and drop it. Then another update to rename the new table to the old name (if needed) and it's done with minimal disruption in service.

- use tech-stacks that I know

- even simpler – use node.js / express (i.e. use only one programming language)

- Standard AWS EC2, S3, Postgres instances

- scale vertically before scaling horizontally

- use GitHub Actions as much as possible

- deploys and rollbacks are done manually

- I keep a list of useful CLI commands in Notion

If you're a small team you shouldn't need to think about kubernetes tbh.

If I want to set it up on a new server, I start a fresh Debian machine, do "apt install mariadb-server" and I am good to go.

I don't like managed services (like Heroku) because:

1: I cannot easily replicate the setup locally.

2: It creates vendor lock-in which will cause me trouble when the vendors service changes in a way I don't like.

3: I would not be able to put the whole setup of my project in one setup script. It is so nice to just have a single script that contains all the steps that need to be done (Like the "apt install mariadb-server") to run the project on a fresh machine.