Docker Compose in Production in 2026: I Ran My Real Stack for 30 Days and Here Are the Numbers
A docker-compose.yml in production is basically the neighborhood mechanic shop. No dealer-level infrastructure, no touchscreen diagnostic system, no certified tech with three specializations. But the neighborhood mechanic knows every bolt on your car, gets it running in ten minutes when the dealer would've taken three days, and charges a third of the price. Once you understand that, you stop apologizing for using it.
That's the tension that blew up a Hacker News thread a few days ago — 398 points — asking whether Docker Compose in production is a legitimate tool or technical debt dressed up as convenience. I sat there reading comments for twenty minutes. People with solid arguments on both sides. And me, sitting there with my stack running on Railway for months, thinking: I have the logs, I have the numbers, why am I reading other people's opinions?
So I did it properly. Thirty days of my own metrics. Restart loops, resource limits, networking edge cases, real uptime. Here's what I found.
Docker Compose in Production 2026: the State of the Debate and My Take
My thesis is straightforward: Compose in production is not an antipattern — it's an engineering decision with known trade-offs. The embarrassing thing isn't using it. It's using it without knowing what it costs you.
The most repeated argument against it in the thread is that Compose has no real orchestration, that if a node dies nothing brings it back automatically, that it doesn't scale horizontally. All true. Also irrelevant for the 60% of projects that don't need horizontal scale or bank-level fault tolerance.
What exhausts me about this debate is that it always compares Compose to Kubernetes as if they're equivalent options for the same problem. They're not. Kubernetes solves problems most projects don't have. Compose solves problems almost everyone has: spin up services, connect them, manage environment variables, restart on failure.
I've been in tech for 32 years. At 16 I was diagnosing connection drops in a cybercafe at 11pm with a room full of people waiting. No manual. Just the problem and the pressure. I learned then that the right tool is the one that lets you solve the problem before the room empties out. Not the most sophisticated one.
The Experiment: 30 Days of Real Metrics on Railway
My production stack during this period:
- Next.js (frontend + API routes)
- PostgreSQL 16 (separate Railway service)
- Redis 7 (cache and sessions)
- Background worker (job processing)
The docker-compose.yml I ran in staging/production during the experiment:
# compose.prod.yml — real stack, honest comments
version: "3.9"
services:
app:
build:
context: .
dockerfile: Dockerfile.prod
ports:
- "3000:3000"
environment:
- NODE_ENV=production
- DATABASE_URL=${DATABASE_URL}
- REDIS_URL=${REDIS_URL}
# restart: always is the difference between sleeping or not sleeping
restart: always
depends_on:
db:
condition: service_healthy
redis:
condition: service_healthy
# Real limits — without these the container eats all RAM and Railway kills your service
deploy:
resources:
limits:
cpus: "1.0"
memory: 512M
reservations:
memory: 256M
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/api/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
worker:
build:
context: .
dockerfile: Dockerfile.worker
environment:
- DATABASE_URL=${DATABASE_URL}
- REDIS_URL=${REDIS_URL}
restart: on-failure:5
# on-failure with a limit: I don't want infinite loops when there's a code bug
deploy:
resources:
limits:
cpus: "0.5"
memory: 256M
redis:
image: redis:7-alpine
restart: always
volumes:
- redis_data:/data
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 5
db:
image: postgres:16-alpine
restart: always
environment:
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
volumes:
- pg_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
interval: 10s
timeout: 5s
retries: 5
volumes:
redis_data:
pg_data:
The Numbers from 30 Days
Uptime: 99.3%. Two outages. One from a broken deploy I pushed (human error, not Compose). Another from a worker restart loop that hit on-failure and took 4 minutes to stabilize.
Restart loops recorded: 7 total. 5 from the worker, 2 from the app. All resolved automatically. None required manual intervention.
Average recovery time after failure: 23 seconds. With restart: always and a properly configured healthcheck, the time between "process died" and "process is responding again" was consistently under 30 seconds.
Resource consumption: The app lived between 180MB and 340MB of RAM. The 512M limit was never touched. The worker, between 80MB and 150MB.
The ugliest networking edge case: when the Redis container restarted due to an image update, the app took exactly 12 seconds to detect that Redis was back. During those 12 seconds, requests that needed cache failed with ECONNREFUSED and had no fallback. That was my most expensive gotcha of the month.
The Real Gotchas Nobody Mentions in Tutorials
1. depends_on Is Not What You Think It Is
This is the mistake I made in the first week. depends_on with condition: service_healthy waits for the healthcheck to pass before starting the dependent service. Sounds perfect. The problem: if Postgres's healthcheck takes 40 seconds because the database is initializing data, the app waits. But if there's an error in the migrations the app runs on startup, you'll see a restart loop that looks like a Compose problem when it's actually an app problem.
# First thing I do to debug this:
docker compose logs --follow --timestamps app
# If you see this, it's a startup problem, not a Compose problem:
# app-1 | 2026-01-15T03:12:44Z Error: connect ECONNREFUSED 127.0.0.1:5432
# app-1 | 2026-01-15T03:12:44Z Process exited with code 1
2. resource limits in deploy Only Work With docker compose up If You Have the Right Version
On Docker Desktop 4.x and Docker Engine 24+, deploy.resources.limits work without swarm. Before that, they didn't. If you're running Compose on a server with an old Docker Engine and wondering why your container is eating all available RAM, this is why.
# Check version before assuming limits are working
docker version --format '{{.Server.Version}}'
# You need 24.0+ for deploy.resources to work without swarm
3. Named Volumes Survive docker compose down
This burned me in staging once. I ran docker compose down thinking it would clean everything up so I could start fresh with a clean database. Named volumes (pg_data, redis_data) are still there. To remove them you need docker compose down -v. If you don't know this and you're debugging a corrupted data problem, you can spin your wheels for a while.
4. The Redis Networking Edge Case I Mentioned
The fix I implemented was a retry with exponential backoff on the Redis client:
// lib/redis.ts — real retry, not the tutorial version
import { createClient } from "redis";
const client = createClient({
url: process.env.REDIS_URL,
socket: {
// Retry with backoff: don't hammer a server that's still coming up
reconnectStrategy: (retries) => {
if (retries > 10) {
console.error("Redis: too many retries, giving up");
return new Error("Retries exhausted");
}
// Incremental wait: 100ms, 200ms, 400ms...
const delay = Math.min(retries * 100, 3000);
console.warn(`Redis: retry ${retries} in ${delay}ms`);
return delay;
},
},
});
// Fallback for cache operations: if Redis doesn't respond, keep going without cache
export async function getCached<T>(
key: string,
fallback: () => Promise<T>
): Promise<T> {
try {
const cached = await client.get(key);
if (cached) return JSON.parse(cached) as T;
} catch (err) {
// Redis being down is not a fatal error — it's graceful degradation
console.warn("Forced cache miss due to Redis unavailable:", err);
}
return fallback();
}
This pattern saved my requests during those 12 seconds of reconnection. Without it, 100% of requests touching cache returned 500.
FAQ: Docker Compose in Production 2026
Can Docker Compose actually run in production in 2026?
Yes. With restart: always, properly configured healthchecks, and defined resource limits, Compose is perfectly capable of sustaining a production service at 99%+ uptime. What it can't do is multi-node orchestration, rolling deploys with zero downtime, or automatic horizontal scaling. If you need those things, Compose isn't the tool. If you don't, Compose is more than enough.
What's the difference between Docker Compose and Kubernetes in production?
Kubernetes solves problems of scale, distributed fault tolerance, and orchestrating hundreds of services. Compose solves the problem of running several related containers on a single node. They're tools for different contexts. Using Kubernetes for a project with 3 services and 500 daily users is like hiring a 10-engineer team to maintain a blog.
How do I handle zero-downtime deploys with Compose?
With pure Compose, you can't do rolling deploys natively without downtime. My strategy: build new image → push → docker compose pull → docker compose up -d --no-deps app. Downtime is 5 to 15 seconds depending on the healthcheck. For most of my projects, that's acceptable. If it's not acceptable for yours, you need a reverse proxy with health routing or an orchestrator outright.
What happens if the node goes down? Does Compose recover it?
No. Compose lives on a single node. If the server dies, the services die. For that you need multi-node orchestration (Swarm, Kubernetes, Nomad) or a provider like Railway that manages node availability for you. On Railway, the underlying infrastructure has its own availability guarantees. Compose manages the containers within that node.
Do Compose healthchecks actually work?
More than most people think, and less perfectly than some expect. The healthcheck determines when a container is ready to receive traffic and when depends_on with condition: service_healthy releases the next service. What it doesn't do is automatically route traffic to an alternative container when the primary fails — for that you need a load balancer. But for managing container lifecycle on a single node, they're essential.
Is it worth migrating from Compose to Kubernetes in 2026?
Depends entirely on what problem you have. If you have more than 50 services, need automatic horizontal scaling, or handle loads that vary 10x in hours, Kubernetes starts to be worth the operational cost. If you have 3-10 services and a relatively predictable load, Kubernetes complexity is a cost you'll probably never recover. My rule: migrate when the pain of Compose is more expensive than the cost of operating Kubernetes. Not before.
What 30 Days Confirmed for Me
I keep coming back to something I wrote in the post about agentic coding and real productivity: the difference between a tool that works and a tool that looks like it should work. Compose works. Not the way Kubernetes works. The way the neighborhood mechanic works: know its limits, trust what it knows how to do, and don't ask it to be something it's not.
The 30-day numbers tell me my stack handled 7 automatic failures without human intervention, recovered in under 30 seconds every time, and hit 99.3% uptime with the only significant downtime being a deploy mistake I made. That's not an antipattern. That's practical engineering.
What I actually learned — and what the HN thread never says clearly — is that the difference between Compose in production that works and Compose in production that explodes is almost always three things: correct healthchecks, defined resource limits, and a fallback strategy for external dependencies. Without those three things, the problem isn't Compose. It's the absence of serious operations.
Back in 2022, a query taking 40 seconds dropped to 80ms by adding a composite index. That day I understood that the difference between "broken" and "works" is almost never the tool — it's knowing it. Compose in production is the same. Same as when I was wiring networks in a cybercafe at 16: didn't have ISP-grade equipment, but I knew every cable.
If the HN thread made you doubt whether Compose is legitimate in production, the right answer isn't "yes" or "no." It's: do you know exactly what it costs you? If yes, keep going. If not, that's the work you still need to do.
I have real Railway logs with uptime metrics showing how an apparently minor infrastructure detail can break an entire pipeline. The lesson is always the same: measure first, opine after.
Source: Hacker News
This article was originally published on juanchi.dev
