How to Move a Side Project From Laptop to Production

Moving a side project from your laptop to production is a short checklist, not a rewrite: get the config out of the code, put a real database on the box with backups, terminate TLS, set up a repeatable deploy, and add basic monitoring. Do those five things on a single VPS and your side project is genuinely in production, reachable by real users and safe to run unattended. Most people either skip these and get burned, or over-engineer and never ship. The middle path is an afternoon of work on one box.

What does production actually require?

Production is not a bigger version of your dev setup. It is a small set of properties your laptop does not have: the app survives a reboot, secrets are not in the code, data is backed up, traffic is encrypted, and you can deploy a fix without SSHing in to edit files by hand. Nail those and you are production-ready. Everything beyond them is optimization you can do later.

The trap is thinking production means Kubernetes, load balancers, and a CI pipeline with ten stages. It does not, and reaching for that stack is how side projects die before launch. One VPS running Docker Compose covers all five properties, which is the whole argument in Docker Compose is enough for a side project. Ship on that, then improve.

The move-to-production checklist

Work through these in order. Each is small and each removes a real way your project could break in front of users.

Externalize config and secrets. Get database URLs, API keys, and passwords out of the code and into an env file the app reads. Never commit secrets. Manage them without a cloud vendor the way I describe in manage secrets without a cloud vendor.
Run a real database with backups. Move off SQLite-on-your-laptop to Postgres on the box, with a named volume so it survives restarts, and a nightly backup that leaves the machine. Test one restore. Untested backups are not backups, which is the point of own your backups when you self-host.
Terminate TLS. Put Caddy or nginx in front for automatic HTTPS. Users and browsers expect it, and it is free. Add Cloudflare in front for a second layer, covered in put Cloudflare in front of your own server.
Set up a repeatable deploy. No hand-editing files on the server. A git-push flow or a one-command rebuild, so shipping a fix is boring and reversible. See git-push deploy on your own box.
Add basic monitoring and restart policies. restart: unless-stopped so crashes self-heal, plus alerts on disk, memory, and whether the site responds.

Five items. Half a day. That is the whole gap between a laptop project and a production one.

Harden the box before you point a domain at it

The moment your project is reachable on the public internet, it is being scanned. Before you announce anything, lock the front door. Use key-only SSH, turn off password login, put a firewall in front that only opens the ports you actually serve, and add fail2ban. This is a fifteen-minute pass through the SSH hardening checklist for a VPS, and skipping it is how side projects become someone else's crypto miner.

Turn on automatic security updates so you are not the person running a six-month-old kernel with a known hole. The setup is in automatic security updates on your VPS. Hardening is not optional theater. It is the difference between a server that runs quietly and one that gets owned in week one.

Size the box and ship

Do not agonize over the machine. Estimate your load, pick a VPS with comfortable headroom, and go, using the reasoning in how to size a VPS for your workload. You can scale up later in minutes if you need to, and a side project rarely needs much to start. Buying a huge box for traffic you do not have is just wasted money.

The point of all this is that production is achievable on one box you fully control, without a platform team or a cloud bill. Run it on HostSSH, work the five-item checklist, harden the box, and your side project is live and safe. Then get back to the actual work: making the thing good enough that people want to use it. The infrastructure is the easy part once you stop over-thinking it.

What does production actually require?

The move-to-production checklist

Work through these in order. Each is small and each removes a real way your project could break in front of users.

Externalize config and secrets. Get database URLs, API keys, and passwords out of the code and into an env file the app reads. Never commit secrets. Manage them without a cloud vendor the way I describe in manage secrets without a cloud vendor.

Run a real database with backups. Move off SQLite-on-your-laptop to Postgres on the box, with a named volume so it survives restarts, and a nightly backup that leaves the machine. Test one restore. Untested backups are not backups, which is the point of own your backups when you self-host.

Terminate TLS. Put Caddy or nginx in front for automatic HTTPS. Users and browsers expect it, and it is free. Add Cloudflare in front for a second layer, covered in put Cloudflare in front of your own server.

Set up a repeatable deploy. No hand-editing files on the server. A git-push flow or a one-command rebuild, so shipping a fix is boring and reversible. See git-push deploy on your own box.

Add basic monitoring and restart policies. restart: unless-stopped so crashes self-heal, plus alerts on disk, memory, and whether the site responds.

Five items. Half a day. That is the whole gap between a laptop project and a production one.

Harden the box before you point a domain at it

Size the box and ship