Docker Compose en producción: checklist de 10 puntos

Docker Compose se diseñó para el desarrollo: sus valores por defecto priorizan la simplicidad, no la robustez. Un contenedor no se reinicia tras un reinicio del host, sus logs crecen sin límite, puede consumir toda la RAM de la máquina y escucha en todas las interfaces de red. En desarrollo, ninguno de estos comportamientos supone un problema, porque usted relanza la stack a mano varias veces al día. En producción, esos ajustes ausentes se convierten en incidentes: disco lleno a las tres de la madrugada, base de datos perdida tras un docker compose down, servicio inaccesible tras un corte de corriente. La buena noticia: endurecer una stack Compose no exige reescribirla, solo una decena de añadidos concretos. Repase cada punto de esta lista antes de publicar y su servicio aguantará la carga y los reinicios sin vigilancia constante.

Antes de aplicar esta checklist, asegúrese de disponer de un VPS con Docker Engine y el plugin Compose v2 instalados (el comando es docker compose, sin guion, desde 2022). Compruebe la versión con docker compose version: la sintaxis deploy.resources fuera de Swarm exige Compose v2. Coloque su archivo en una carpeta de proyecto dedicada, por ejemplo /opt/monapp, con un archivo .env al lado y permisos restringidos (chmod 600 .env). Prevea un reverse proxy por delante — Traefik, Caddy o Nginx — porque varios ajustes, en particular el binding de puertos, dan por supuesto que el tráfico público nunca llega directamente a sus contenedores. Por último, mantenga una copia de su archivo Compose bajo control de versiones.

Si un contenedor se queda bloqueado en estado starting, su healthcheck está fallando: pruebe el comando test a mano con docker compose exec service sh y compruebe que devuelve 0. Un servicio que se reinicia en bucle (Restarting) suele esconder un error en el arranque — consulte docker compose logs -f service. Si deploy.resources.limits parece ignorarse, recuerde que en Compose v2 fuera de Swarm los límites sí se aplican, pero las reservations solo lo hacen en modo Swarm. Un puerto que sigue accesible pese a 127.0.0.1 suele señalar un cortafuegos ausente o una regla de Docker que esquiva UFW — compruébelo con ss -tlnp. Por último, si un docker compose down ha borrado sus datos, casi siempre es porque quedaba un -v de más o porque el volumen era anónimo en lugar de tener nombre.

CVE-2026-17106, bautizada CopyEscape, es una race condition en docker cp divulgada el 10 de agosto de 2026. Un contenedor no confiable puede producir un archivo tar incoherente que sigue un enlace simbólico fuera del destino, lo que acaba sobrescribiendo un archivo arbitrario en el host — incluido el binario runc. La superficie: todo VPS que ejecute docker cp desde un contenedor cuyo contenido usted no controla. La corrección está disponible en Docker Engine ≥ 29.7.2 y Docker Desktop ≥ 4.86.0. Compruebe su versión con docker version y actualice antes de exponer un nuevo servicio. Si no puede actualizar de inmediato, evite docker cp desde contenedores no confiables y aplique el principio de mínimo privilegio (--cap-drop ALL).

Las variables de entorno en claro dentro de un archivo Compose son la primera fuga de secretos en producción: aparecen en docker inspect, en los logs de error y en los volcados de proceso. El mecanismo secrets: de Docker — o un gestor externo como Vault o Infisical — monta los secretos en forma de archivos en /run/secrets/, fuera del alcance de inspect. Para una rotación sin downtime, el método recomendado consiste en versionar el secreto (crear un nuevo secreto db_password_v2 en paralelo al v1), actualizar el servicio para que lea v2, redesplegar en rolling update (docker compose up -d --no-deps service) y después eliminar v1 una vez validado el despliegue. Ninguna interrupción de servicio, ninguna ventana de secreto expuesto entre las dos versiones.

Copiar los archivos de un volumen PostgreSQL o MySQL en caliente con rsync o tar produce casi con toda seguridad una copia de seguridad corrupta: el motor escribe de forma continua durante la copia y las páginas de datos se capturan en puntos de control distintos. La regla es hacer siempre un dump SQL antes del snapshot del volumen: pg_dump o mysqldump producen un estado coherente que usted puede archivar o transferir. Para automatizar este enfoque en un VPS con Docker, herramientas como Restic y Offen Docker Backup orquestan la congelación de la base de datos, el dump SQL, el snapshot cifrado y el envío a un almacenamiento remoto. Documente cada volumen con nombre (paso 5 de la checklist) y asócielo a una estrategia de restauración probada: una copia de seguridad sin prueba de restauración es un dato no respaldado.

Estos diez ajustes convierten un archivo Compose de desarrollo en una stack de producción capaz de sobrevivir a los reinicios, a los picos de carga y a las noches sin vigilancia. Ninguno exige una herramienta adicional: todo cabe en el YAML que usted ya tiene. Adquiera la costumbre de recorrer esta checklist antes de cada puesta en línea, idealmente en forma de revisión de docker compose config integrada en su despliegue. Una vez asentados estos cimientos, puede añadir un reverse proxy como Traefik o Caddy, o una capa de orquestación como Coolify, con total confianza.