I’m writing this from Bengaluru Airport.
University has ended, and I’m heading home to work remotely at a startup.
It feels strange.
The university chapter is over, but the laptop and work are coming with me.
While waiting for my flight, one startup lesson keeps coming back:
Start with the simplest thing that works.
That brings me to Docker Compose.
This is not one exact production incident. It is a pattern almost every engineer sees after deploying enough side projects and startup products.
You have an application: a frontend, an API, PostgreSQL, Redis, and one background worker.
You buy a VPS, install Docker, and write a compose.yaml.
Then you run:
docker compose up -dFive containers start.
The website opens. The API connects to the database. Everything works.
For a few minutes, you feel like the DevOps engineer of the year. Honestly, you should.
You took an application from your laptop and put it on the internet with one YAML file and one command. That is powerful.
Then Monday Morning Arrived
The product slowly gets users.
One morning, a customer uploads a large file. The background worker starts processing it.
CPU usage goes up. Memory usage goes up. The API becomes slow.
The worker, API, database, and Redis are all running on the same machine. Starting three more worker containers will not create more CPU or memory.
You created more containers.
You did not create more capacity.
That is the first crack.
Restart Is Not High Availability
Next week, the API crashes because of a bug. Docker restarts it because you configured a restart policy.
Nice.
But then comes one uncomfortable question:
What happens when the server itself goes down?
If the VPS has a disk, network, or provider problem, every container disappears together.
Compose can restart a failed container. It cannot move that container to another healthy machine when there is only one machine.
This is not really a Compose failure. It is a single-server architecture doing exactly what a single-server architecture does.
Obviously, I Started Reading About Kubernetes
This is the stage where many of us open the Kubernetes documentation.
Suddenly five services need Deployments, Services, Ingress, Secrets, probes, persistent volumes, and an entire cluster.
The product has not become Netflix, but the YAML folder is trying very hard.
Kubernetes is powerful. It can schedule workloads across machines, replace failed containers, maintain replicas, and perform controlled rollouts.
It also adds a distributed system that somebody must understand and maintain.
Moving to Kubernetes only because “real companies use it” is not engineering. It is peer pressure with YAML.
Compose Was Still Enough
After all that reading, look at the actual requirements.
Can the application survive a short deployment interruption? Does one server still have enough capacity? Is the team small? Are traffic and deployments predictable?
If yes, improve the Compose setup first.
Add restart policies, health checks, monitoring, off-server backups, and a documented restore process. Docker officially supports using Compose in production, and it supports health-check-based startup conditions.
Sometimes the next step is not Kubernetes. It may be moving PostgreSQL to a managed database or running heavy workers on a separate machine.
When Should You Move Beyond Compose?
Stay with Compose when:
- One server has enough capacity
- Short interruptions are acceptable
- Services generally scale together
- Backups and restores are tested
- The setup is simple to operate
Consider moving beyond it when:
- One host failure cannot take down everything
- Services need independent scaling across machines
- Deployments need automatic rolling updates
- Workloads need rescheduling and failover
- You are building too much custom orchestration around Compose
Do not migrate because of one scary blog post.
Look at your incidents, traffic, deployment pain, and recovery requirements.
Then choose.
Final Thought
Docker Compose is not a beginner tool that every serious engineer must leave behind.
For many applications, one well-managed server is enough.
Use Compose. Harden it. Back it up. Monitor it.
When one server or manual coordination is no longer acceptable, move to the next thing with a clear reason.
Not because Kubernetes looks good in an architecture diagram.
Move because your system finally asked for it.
Docker Compose is enough until your requirements prove that it isn’t.