Docker Compose Is Enough for a Side Project in Production

If you are running a side project and reaching for Kubernetes, stop. One VPS and a single docker-compose.yml file will run your web app, your database, a background worker, and a reverse proxy in production, and it will keep running for years without you touching it. I run production workloads this way across a portfolio. Compose is not a toy you outgrow at launch. It is the correct tool right up until you have real traffic and a real team, and most side projects never get there.

Do I need Kubernetes for a side project?

No. Kubernetes solves problems you do not have. It manages scheduling across a fleet of machines, rolling updates for dozens of services, and self-healing when nodes die. A side project has one machine and maybe five containers. The control plane alone eats more RAM than your whole app. You would spend your first month writing YAML and debugging networking instead of shipping features.

The honest test: if you cannot name the specific failure Kubernetes prevents for your project, you do not need it. "It scales" is not a failure you have. I wrote a whole piece on this because the reflex is so common: you don't need Kubernetes for almost anything you are building right now.

Compose gives you the parts that actually matter. Services defined in one file. A private network so containers reach each other by name. Named volumes so your database survives a restart. Restart policies so a crashed process comes back. That covers the real needs of a production side project.

What a real Compose stack looks like

A production side project usually has four things: the web process, a Postgres database, a job queue worker, and something terminating TLS. All four fit in one file.

• The web service builds from your Dockerfile, reads secrets from an env file, and depends on the database.
• Postgres runs from the official image with a named volume mounted at its data directory. Nothing fancy. Set a real password and do not expose the port to the internet.
• The worker is the same image as the web service with a different command, pulling jobs off the queue.
• A reverse proxy like Caddy or nginx sits in front, handling HTTPS and routing. Caddy gets you automatic certificates with three lines of config.

Set restart: unless-stopped on everything. Now a reboot brings the whole stack back on its own. Put the database on the same box to start, and split it out only when you have a reason. I cover that tradeoff in should Postgres share the app's box or get its own.

When does Compose actually stop being enough?

There is a real line, and it is further out than people think. Compose stops being enough when you need more than one machine, when you need zero-downtime rollouts across many replicas, or when a team of engineers is deploying independently many times a day. That is a genuine scaling problem, and by the time you have it you will have revenue to pay for the complexity.

Everything before that line, Compose handles. Deploying an update is git pull and docker compose up -d --build. Add a git-push flow and it gets even cleaner, which I walk through in git-push deploy on your own box. Rolling back is checking out the previous commit and running the same command. Logs are docker compose logs. You do not need a platform team to operate this.

The mistake is treating your side project like it is already at Google scale. It is not. Build for the load you have plus a comfortable margin, not for a fantasy. HostSSH exists because the sane default for a single-box product is a VPS you control, not a managed platform charging you for elasticity you will never use.

Compose plus one good VPS beats a PaaS

A PaaS abstracts away the machine, which sounds nice until you hit its limits or its bill. You pay a premium for convenience, you inherit its quirks, and you cannot see what is actually running. Compose on a VPS gives you the same simplicity without the tax. You define the stack, you own the box, you read the logs directly.

Size the box for the workload, keep backups running, and put a firewall in front. Those are an afternoon of setup, covered in how to size a VPS for your workload. After that the thing just runs. My portfolio proves the model: many small products, each a Compose file on shared infrastructure, and I am not paged about any of them on a normal week. Start simple. Add complexity only when a real problem forces you to. Most of the time it never does.