Every senior engineer I asked told me the same thing: Docker Compose isn't production-ready. Use Kubernetes. Compose is for your laptop. So I put Docker Compose in production — a real app, real users, real load — and it just worked. Not "barely survived" worked. Reliably, quietly, for months.
This is the story of that decision, the numbers behind it, and why the hardest part had nothing to do with technology.
Three days that rewired how I think about infrastructure
My first ever docker-compose.yml was WordPress and MySQL. It took me three days.
Three days of port conflicts. Three days of staring at a database that flat-out refused to accept connections. Three days of not understanding the difference between a container and an image — I genuinely thought they were the same thing. The killer bug: port 3306 was already in use, because MySQL was running natively on my machine and I didn't even know it had been installed. I burned an entire evening on that one line.
Today the exact same stack takes me three minutes. But I don't regret those three days for a second — they permanently changed how I think about infrastructure. Because inside that tiny compose file were all the real production problems in miniature: service discovery, networking, volumes, configuration, dependency ordering. Compose is a scale model of every hard infrastructure question you'll ever face.
What "production" actually looked like
Fast-forward. The application: a web service with a database, a cache, and background workers. Moderate, predictable traffic. Around 500 users.
Here's the whole thing:
- Docker Compose on a single VM
- Nginx as a reverse proxy with SSL
- Health checks and automatic restart policies
- Blue-green deployments driven by one boring bash script
- Prometheus + Grafana for monitoring
- Automated backups, pushed off the box
Total infrastructure cost: $40 a month.
The Kubernetes equivalent — a managed control plane plus nodes — I estimated at $200–400 a month, before counting the hours of my life spent operating it. Uptime over six months: 99.9%. No 3 a.m. pages. No mystery evictions. No service-mesh debugging sessions I'd have to explain to anyone.
The lesson from that first compose file still holds
Everything that made that first painful WordPress file worthwhile is exactly what made the production system solid:
- Infrastructure as code. The whole environment lives in a file you can read, diff, and roll back.
- Reproducible environments.
docker compose upgives you the same thing every time. - Isolated, composable services. Each piece does one job and talks over a defined network.
A 500-user application does not need container orchestration. It needs a VM, a Compose file, and an engineer who actually understands the trade-offs. Over-engineering isn't sophistication — it's still an engineering failure, just a more expensive and more respectable-looking one.
The hardest part wasn't the tech
Let me be honest about the part nobody warns you about: the technology was the easy bit. Defending the decision was the war.
Every code review, someone asked about Kubernetes. Every architecture meeting, someone raised scaling concerns — for traffic that did not exist and, on any honest projection, wasn't going to exist for a long time. The industry has a genuine complexity addiction, and "we might need to scale one day" is its favourite phrase.
So I kept one dead-simple document: current users, current load, projected growth. Every time the Kubernetes question came up, I pointed at the numbers. The numbers never justified the complexity. They still don't.
Match complexity to the problem, not the résumé
The lesson here is not "never use Kubernetes." Kubernetes is excellent when your problem is genuinely Kubernetes-shaped. The lesson is narrower and more useful: match your infrastructure complexity to your problem complexity.
The best infrastructure decision I made that year was choosing not to build something impressive. Boring tech, running quietly in production, outperformed every clever alternative on the table — on cost, on uptime, and on my own sleep.
So here's my question for you, the same one I put to my feed: what's the most boring tech decision you ever made that saved you the most headaches? Because in my experience, the boring, obvious choice is usually the most professional one in the room.