Docker Compose: el contrato de entornos que se pueden reproducir.

Docker Compose es el documento que dice «así arranca este producto». Imágenes pinneadas —versiones fijas, no «la última» que cambió ayer—, volúmenes para datos, redes internas y un .env que no viaja al repositorio. En Ambigram lo usamos para web, workers y servicios de apoyo: el agente que «funciona en mi máquina» deja de ser un argumento.

En lenguaje llano: Compose levanta varios contenedores —cajas con tu app y sus dependencias— con un solo comando. Tu portátil y el servidor de staging leen el mismo compose.yaml. Piénsalo como la receta del cocido: mismos ingredientes, mismo resultado; no «eché un poco de sal a ojo».

El error es tratar Compose como orquestador de producción masiva —como Kubernetes, pensado para cientos de nodos— o, al revés, no versionarlo. Un compose.yaml en el repo, con healthchecks y sin bind-mounts peligrosos en el servidor, evita sorpresas al recrear el contenedor.

Human + IA aquí significa que el agente puede regenerar un Dockerfile —instrucciones para construir la imagen—, pero una persona decide qué se publica, qué puerto se expone y qué secreto nunca entra en la imagen. Las claves de API y contraseñas van en variables de entorno, no copiadas en el chat ni en la imagen.

Para clientes que operan su propio VPS o un servidor dedicado, Compose es el contrato que pueden leer sin un curso de orquestación. «docker compose up -d» y el stack arranca igual que en nuestra oficina. Eso reduce tickets de «en mi entorno no va».

Compose no es producción a escala infinita; es honestidad de entorno. Cuando el producto crece, puedes migrar a orquestación mayor; mientras, un compose bien mantenido es la base que humanos y agentes comparten para reproducir bugs y desplegar sin teatro.