Hay una discusión que aparece cada cierto tiempo: si Docker Compose sirve o no para producción. Mi respuesta corta es que depende del contexto. No es la herramienta universal, pero tampoco es ese pecado técnico que a veces pintan.
En entornos controlados, con stacks claros, pocos servicios y una operación disciplinada, Compose puede resolver muy bien. Lo que no se puede hacer es usarlo como si fuera magia y luego culpar la herramienta por falta de orden.
Dónde sí lo usaría
Lo usaría en servicios internos, aplicaciones medianas, plataformas con pocos nodos y equipos que necesitan desplegar rápido sin montar una orquestación más pesada. Allí Compose da velocidad, legibilidad y una curva operativa razonable.
Además, para PYMEs o equipos pequeños, tener todo el stack descrito en un solo archivo bien mantenido simplifica respaldos, recuperación y troubleshooting.
Lo que cambia cuando ya es producción
El archivo compose por sí solo no basta. En producción hacen falta healthchecks, reinicio controlado, manejo correcto de volúmenes, secretos, logs, métricas y procedimientos claros para rollback.
También hay que pensar en cómo se actualiza un servicio sin romper el resto. Allí la disciplina operativa pesa más que el YAML.
Los errores más comunes que he visto
Meter credenciales en texto plano, no fijar versiones de imagen, mezclar datos persistentes sin orden y no probar restauración. Esos errores no son de Docker Compose: son de gobernanza técnica.
Otro error común es no separar bien reverse proxy, aplicación y base de datos. Cuando todo se resuelve en un bloque improvisado, el mantenimiento se vuelve frágil.
Mi checklist mínimo
Variables fuera del repositorio, respaldos probados, observabilidad básica, healthchecks, restart policies coherentes y una guía simple para que otro técnico pueda levantar o recuperar el servicio sin adivinar.
Si además sumas pipelines, escaneo de imágenes y documentación clara, Compose se vuelve una base bastante digna para muchos escenarios reales.
No todo proyecto necesita Kubernetes desde el día uno. A veces la mejor decisión técnica es la que equilibra estabilidad, velocidad y capacidad real del equipo.