The team shipped to prod with docker compose up -d on a VPS: app, worker, cache, reverse proxy. It runs. Six months later, first real incident — full disk on the single node — cuts everything: web, queues, monitoring. DR plan says "fail over to second server," but Compose was never configured to orchestrate two hosts.
Docker Compose excels at describing multiple containers and links. It is not a datacenter orchestrator. Confusing "I have a working yaml" with "I have resilient infra" hurts at the first single point of failure.
What Compose does well — and where it stops
Compose v2 handles depends_on, healthcheck, volumes, overlay networks on one Docker engine. Ideal to reproduce prod locally and launch a coherent stack.
| Need | Compose | Orchestrator (Kubernetes, Nomad) |
|---|---|---|
| Multi-container on 1 host | ✅ | ✅ (overkill) |
| Rolling update without downtime | ⚠️ manual / script | ✅ native |
| Multi-node / no single point | ❌ | ✅ |
| Horizontal autoscaling | ❌ | ✅ |
| Secret rotation | ⚠️ limited | ✅ integrated |
On a single server at a European host, Compose stays honest if you assume maintenance and off-compose backups.
Compose documents your stack; it does not make it available by magic.
Single host, volumes, forgotten backups
Named volumes survive stops without deletion — handy, dangerous if nobody snapshots DB. Image update refreshes app but not automatically Postgres volume backup strategy.
Verify: tested off-node backups, disk monitoring and alerts, centralized logs — not just local container logs. Externalizing DB reduces risk without jumping to Kubernetes.
Deploy, downtime, healthcheck
Without healthcheck, proxy may route to still-booting container — temporary server errors. Pattern: HTTP check on app endpoint, proxy sending traffic only to healthy backends, deploy script waiting for health.
Zero-downtime multi-instance update on one host stays artisanal. Limits become concrete: you reinvent what orchestrators do natively.
Network, TLS, port exposure
Publishing database port exposes PostgreSQL to Internet if host firewall is lax. Prefer internal compose network plus single reverse proxy on secure port.
Observability and overnight on-call
Compose provides no cluster dashboard. Container metrics need a dedicated agent, logs a collector — add both explicitly. Document who SSHes, how to restart a service, where env files live, and who responds to a 3 a.m. alert.
The peak: Compose as deferred debt
Decide and move forward without blind spots
If you stay on Compose, treat these points as an audit before the next incident:
- Externalize the database to a managed offer or tested off-node backups — Docker volumes alone do not protect your data.
- Add health checks on every exposed service and configure the proxy to send traffic only to healthy backends.
- Test backups with a timed restore, not just the presence of a cron script.
- Script deployment with health wait and documented maintenance window.
- Deploy monitoring for disk, containers and centralized logs — Compose does not do this natively.
- Plan migration threshold based on traffic, team size and SLA promised to clients.
- Simulate disk failure: how long to restore service and data? If the answer is vague, Compose is not prod-ready for you yet.
Compare suitable hosts via the directory and comparison tool.
Frequently asked questions
Is Docker Compose meant for production?
Compose mainly targets development and simple deployments on one or few hosts. At scale in production it lacks native primitives for multi-node rolling updates, autoscaling and fine-grained secret rotation. That does not forbid it — but defines its limits.
When does Compose remain a good choice?
On a single server, with a small team, stable stack and tolerance for a short maintenance window. Internal tools, MVPs and early-stage SaaS often fit — provided the single point of failure is assumed and documented.
How to manage secrets with Compose?
Use environment variables via an unversioned file, Docker secrets in swarm mode or CI injection at deploy. Never commit passwords to the repository. Rotate secrets after any suspected leak.
How to migrate without big bang to Kubernetes?
Externalize state first (managed DB, managed cache), containerize cleanly, then move service by service. Compose and Kubernetes can coexist during transition — no need to switch everything on a Friday night.
Compose holds as long as you can name your single point of failure — and explain how you survive it.