Deployment
Every few months a new orchestration tool shows up and someone on the internet insists you're irresponsible for not using it. Meanwhile, plenty of profitable products run on a single server with a Compose file. Kubernetes solves real problems, but those problems belong to teams with dozens of services and dedicated platform engineers. If you're one person shipping a product, Compose gives you reproducible environments, sensible networking, and one-command startups without a control plane to babysit.
The core idea is simple: describe your services, their images, their environment, and their volumes in one YAML file, then run everything together. Your app container talks to your database container by service name, because Compose puts them on the same network. Ports, health checks, restart policies, and dependency ordering are all expressible. It's declarative enough to be version controlled and simple enough to read in one sitting.
Keep your database data in named volumes, never in the container filesystem. Containers are disposable; your data is not. Mount configuration as read-only files rather than baking it into images so you can change settings without rebuilding. Use separate Compose files for development and production, with an override file for local conveniences like bind mounts and exposed debug ports. The production file should pull prebuilt images; the dev file can build locally.
Health checks are the feature people forget and then regret. A health check lets Compose know whether a service is actually ready, not just running. Pair that with a restart policy and your app survives the classic race where it boots before the database accepts connections. For updates, a short script that pulls new images and runs compose up with the detached flag gets you a respectable deploy. Add a reverse proxy container in front, and you have TLS and routing in the same file.
Compose has limits. It runs on one host, so there's no failover if that host dies. Scaling beyond a single machine, zero-downtime deploys, and multi-tenant isolation are where it starts to strain. If you need those, that's a legitimate signal to look at something bigger. But notice that the signal is a real operational need, not a conference talk.
The honest advice is to start with Compose and let pain tell you when to leave. Document your services, keep secrets out of the file using environment files or a secret manager, and automate the boring parts with a small Makefile. You'll spend your time on your product instead of your platform, which is exactly the trade an indie developer should be making.
