Docker Compose en producción en 2026: corrí mi stack real durante 30 días y estos son los números

Un docker-compose.yml en producción es básicamente como el taller mecánico del barrio. No tiene la infraestructura del concesionario oficial, no tiene el sistema de diagnóstico con pantalla táctil, no tiene el técnico certificado con tres especializaciones. Pero el mecánico del barrio conoce cada tornillo de tu auto, lo arranca en diez minutos cuando el concesionario tardaría tres días, y cobra un tercio. Y una vez que entendés eso, dejás de pedirle disculpas por usarlo.

Esa es la tensión que reopenó un hilo de Hacker News hace unos días con 398 puntos: ¿Docker Compose en producción es una herramienta legítima o una deuda técnica disfrazada de conveniencia? Me quedé mirando los comentarios durante veinte minutos. Había gente con argumentos sólidos en ambas direcciones. Y yo ahí, con mi stack corriendo en Railway desde hace meses, pensando: tengo los logs, tengo los números, ¿por qué estoy mirando opiniones ajenas?

Así que lo hice en serio. Treinta días de métricas propias. Restart loops, resource limits, networking edge cases, uptime real. Esto es lo que encontré.

Docker Compose en producción 2026: el estado del debate y mi postura

Mi tesis es directa: Compose en producción no es un antipatrón, es una decisión de ingeniería con trade-offs conocidos. Lo vergonzoso no es usarlo — es usarlo sin saber qué te cuesta.

El argumento en contra que más se repite en el hilo es que Compose no tiene orquestación real, que si un nodo se muere no hay nada que lo levante automáticamente, que no escala horizontalmente. Todo eso es cierto. Y también es irrelevante para el 60% de los proyectos que no necesitan escala horizontal ni tolerancia a fallas de nivel bancario.

Lo que me cansa del debate es que siempre compara Compose con Kubernetes como si fueran opciones equivalentes para el mismo problema. No lo son. Kubernetes resuelve problemas que la mayoría de los proyectos no tiene. Compose resuelve problemas que casi todos tienen: levantar servicios, conectarlos, manejar variables de entorno, reiniciar en falla.

Vengo de 32 años con tecnología. A los 16 diagnosticaba cortes de conexión en un cyber a las 11pm con el local lleno de gente esperando. No había manual. Había el problema y la presión. Aprendí ahí que la herramienta correcta es la que te deja resolver el problema antes de que el local se vacíe. No la más sofisticada.

El experimento: 30 días de métricas reales en Railway

Mi stack de producción en este período:

• Next.js (frontend + API routes)
• PostgreSQL 16 (servicio separado en Railway)
• Redis 7 (caché y sesiones)
• Worker de background (procesamiento de jobs)

El docker-compose.yml que corrí en staging/producción durante el experimento:

# compose.prod.yml — stack real, comentarios honestos
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 es la diferencia entre dormir o no dormir
    restart: always
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    # Límites reales — sin esto el container come toda la RAM y Railway te mata el servicio
    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 con límite: no quiero loops infinitos si hay un bug de código
    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:

Los números de los 30 días

Uptime: 99.3%. Hubo dos caídas. Una por un deploy roto mío (error humano, no de Compose). Otra por un restart loop del worker que entró en on-failure y tardó 4 minutos en estabilizarse.

Restart loops registrados: 7 en total. 5 del worker, 2 de la app. Todos resueltos automáticamente. Ninguno requirió intervención manual.

Tiempo promedio de recuperación ante falla: 23 segundos. Con restart: always y un healthcheck bien configurado, el tiempo entre "el proceso murió" y "el proceso responde de nuevo" fue consistentemente menor a 30 segundos.

Consumo de recursos: La app vivió entre 180MB y 340MB de RAM. El límite de 512M nunca fue tocado. El worker, entre 80MB y 150MB.

El edge case de networking más feo: cuando el container de Redis reiniciaba por una actualización de imagen, la app tardaba exactamente 12 segundos en detectar que Redis estaba de vuelta. Durante esos 12 segundos, las requests que necesitaban caché fallaban con ECONNREFUSED y no tenían fallback. Ese fue mi gotcha más costoso del mes.

Los gotchas reales que nadie menciona en los tutoriales

1. depends_on no es lo que creés

Este es el error que cometí en la primera semana. depends_on con condition: service_healthy espera que el healthcheck pase antes de iniciar el servicio dependiente. Suena perfecto. El problema: si el healthcheck de Postgres tarda 40 segundos en pasar porque la base está inicializando datos, la app va a esperar. Pero si hay un error en las migraciones que corre la app al arrancar, vas a ver un restart loop que parece un problema de Compose cuando en realidad es un problema de la app.

# Para debuggear esto, lo primero que hago:
docker compose logs --follow --timestamps app

# Si ves esto, es un problema de startup, no de Compose:
# 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. Los resource limits en deploy solo funcionan con docker compose up si tenés la versión correcta

En Docker Desktop 4.x y Docker Engine 24+, los deploy.resources.limits funcionan sin swarm. Antes no. Si corrés Compose en un servidor con Docker Engine viejo y te preguntás por qué tu container come toda la RAM disponible, es esto.

# Verificar versión antes de asumir que los límites funcionan
docker version --format '{{.Server.Version}}'
# Necesitás 24.0+ para que deploy.resources funcione sin swarm

3. Los volúmenes nombrados sobreviven a docker compose down

Esto me quemó en staging una vez. Hice docker compose down pensando que limpiaba todo para empezar de cero con una base fresca. Los volúmenes nombrados (pg_data, redis_data) siguen ahí. Para borrarlos necesitás docker compose down -v. Si no sabés esto y estás debuggeando un problema de datos corruptos, podés dar vueltas un buen rato.

4. El networking edge case de Redis que mencioné antes

La solución que implementé fue un retry con backoff exponencial en el cliente de Redis:

// lib/redis.ts — retry real, no el de los tutoriales
import { createClient } from "redis";

const client = createClient({
  url: process.env.REDIS_URL,
  socket: {
    // Reintento con backoff: no martillo el servidor que está levantando
    reconnectStrategy: (retries) => {
      if (retries > 10) {
        console.error("Redis: demasiados reintentos, abandonando");
        return new Error("Reintentos agotados");
      }
      // Espera incremental: 100ms, 200ms, 400ms...
      const delay = Math.min(retries * 100, 3000);
      console.warn(`Redis: reintento ${retries} en ${delay}ms`);
      return delay;
    },
  },
});

// Fallback para operaciones de caché: si Redis no responde, seguir sin caché
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 caído no es error fatal — es degradación graceful
    console.warn("Cache miss forzado por Redis no disponible:", err);
  }
  return fallback();
}

Este patrón me salvó las requests durante los 12 segundos de reconexión. Sin él, el 100% de las requests que tocaban caché devolvían 500.

FAQ: Docker Compose en producción 2026

¿Docker Compose puede correr en producción de verdad en 2026? Sí. Con restart: always, healthchecks bien configurados y resource limits definidos, Compose es perfectamente capaz de sostener un servicio en producción con uptime de 99%+. Lo que no puede hacer es orquestación multi-nodo, rolling deploys sin downtime o escala horizontal automática. Si necesitás eso, Compose no es la herramienta. Si no lo necesitás, Compose es más que suficiente.

¿Qué diferencia hay entre Docker Compose y Kubernetes en producción? Kubernetes resuelve problemas de escala, tolerancia a fallas distribuidas y orquestación de cientos de servicios. Compose resuelve el problema de correr varios containers relacionados en un mismo nodo. Son herramientas para contextos distintos. Usar Kubernetes para un proyecto con 3 servicios y 500 usuarios diarios es como contratar un equipo de 10 ingenieros para mantener un blog.

¿Cómo manejo los deploys sin downtime con Compose? Con Compose puro, no podés hacer rolling deploys sin downtime de forma nativa. La estrategia que uso es: build nueva imagen → push → docker compose pull → docker compose up -d --no-deps app. El downtime es de 5 a 15 segundos dependiendo del healthcheck. Para la mayoría de mis proyectos, eso es aceptable. Si no lo es para el tuyo, necesitás un proxy reverso con health routing o directamente un orquestador.

¿Qué pasa si el nodo se cae? ¿Compose lo recupera? No. Compose vive en un solo nodo. Si el servidor muere, los servicios mueren. Para eso necesitás orquestación multi-nodo (Swarm, Kubernetes, Nomad) o un proveedor como Railway que maneja la disponibilidad del nodo por vos. En Railway, la infraestructura subyacente tiene sus propias garantías de disponibilidad. Compose gestiona los containers dentro de ese nodo.

¿Los healthchecks de Compose realmente sirven? Sirven más de lo que la mayoría cree, y peor de lo que algunos esperan. El healthcheck determina cuándo un container está listo para recibir tráfico y cuándo depends_on con condition: service_healthy libera el siguiente servicio. Lo que no hace es enrutar tráfico automáticamente a un container alternativo cuando el principal falla — para eso necesitás un load balancer. Pero para gestionar el ciclo de vida de containers en un solo nodo, son esenciales.

¿Vale la pena migrar de Compose a Kubernetes en 2026? Depende exclusivamente del problema que tenés. Si tenés más de 50 servicios, necesitás escala horizontal automática, o manejás cargas que varían 10x en horas, Kubernetes empieza a valer el costo operativo. Si tenés 3-10 servicios y una carga relativamente predecible, la complejidad de Kubernetes es un costo que probablemente no recuperás nunca. Mi regla: migrá cuando el dolor de Compose sea más caro que el costo de operar Kubernetes. No antes.

Lo que los 30 días me confirmaron

Me quedé pensando en algo que escribí en el post sobre agentic coding y productividad real: la diferencia entre una herramienta que funciona y una herramienta que parece que debería funcionar. Compose funciona. No de la manera que funciona Kubernetes. De la manera que funciona el mecánico del barrio: conocé sus límites, confiá en lo que sabe hacer, y no le pidas que sea algo que no es.

Los números de 30 días me dicen que mi stack toleró 7 fallos automáticos sin intervención humana, se recuperó en menos de 30 segundos en todos los casos, y tuvo un uptime de 99.3% con el único downtime significativo siendo un error mío en un deploy. Eso no es un antipatrón. Es ingeniería práctica.

Lo que sí aprendí — y que el hilo de HN no dice claramente — es que la diferencia entre Compose en producción que funciona y Compose en producción que explota está casi siempre en tres cosas: healthchecks correctos, resource limits definidos y una estrategia de fallback para las dependencias externas. Sin esas tres cosas, el problema no es Compose: es la falta de operación seria.

En 2022, una query que tardaba 40 segundos la bajé a 80ms agregando un índice compuesto. Ese día entendí que la diferencia entre "roto" y "funciona" casi nunca está en la herramienta — está en conocerla. Compose en producción es lo mismo. Igual que cuando armaba redes en el cyber a los 16: no tenía el equipamiento del ISP, pero conocía cada cable.

Si el hilo de HN te hizo dudar de si Compose es legítimo en producción, la respuesta correcta no es "sí" ni "no". Es: ¿sabés exactamente qué te cuesta? Si la respuesta es sí, seguí. Si no, ese es el trabajo que falta.

Tengo logs reales de Railway con uptime metrics que muestran cómo un detalle de infraestructura aparentemente menor puede romper un pipeline entero. La lección siempre es la misma: medir primero, opinar después.

Fuente original: Hacker News