¿Estos compose.yaml están listos para producción?

No. Son puntos de partida pensados para desarrollo y aprendizaje en local. Cubren lo que más se olvida (volúmenes con nombre, healthchecks, secretos por variable, puertos no expuestos por defecto), pero producción necesita más: backups probados, TLS, secretos gestionados fuera de git, límites de recursos y, casi siempre, un orquestador o un proveedor gestionado. Cada guía dice explícitamente qué le falta para producción.

¿Qué stack elijo para empezar?

Si solo necesitas una base de datos para tu app, empieza por PostgreSQL. Si quieres administrarla con clics, PostgreSQL + pgAdmin. Si tu app vive en el mismo compose que la base de datos, Node.js + PostgreSQL te enseña a esperar a que la DB esté lista. Para caché o colas, Redis con contraseña. La tabla de arriba resume el caso de uso y el riesgo principal de cada uno.

¿Por qué casi ninguno expone el puerto de la base de datos?

Porque dentro de Compose los servicios se hablan por su nombre en la red interna (por ejemplo app se conecta a postgres:5432) sin publicar nada al host. Publicar 5432 o 3306 abre la base de datos a toda la red de tu máquina. En las guías solo publicamos un puerto cuando de verdad necesitas acceder desde el host, y entonces lo atamos a 127.0.0.1 para que no salga de tu equipo.

¿Puedo generar estos archivos en vez de copiarlos a mano?

Sí. Cada guía enlaza al generador de Docker Compose con su preset ya seleccionado: eliges opciones (healthcheck, volúmenes, puerto local) y obtienes el compose.yaml y el .env.example. También puedes pegar tu propio archivo en el validador para detectar secretos en texto plano, puertos de base de datos expuestos, imágenes con :latest y depends_on sin condición de salud.

¿Las contraseñas de los ejemplos son reales?

No. Todos los .env.example usan el placeholder CHANGE_ME a propósito. Debes sustituirlo por un valor propio en un archivo .env que nunca subes a git. Versiona solo el .env.example para documentar qué variables hacen falta, no sus valores.

Ejemplos de Docker Compose: stacks reales explicados

Biblioteca de ejemplos de Docker Compose por stack (PostgreSQL, Redis, Nginx, Node, WordPress, Prometheus + Grafana) con healthchecks, .env.example, puertos seguros y los errores reales que evita cada uno.

Copiar un compose.yaml de cualquier sitio es fácil; entender por qué está escrito así es lo que evita perder una tarde. Esta biblioteca recoge los stacks que más se montan en local y, en cada uno, explica las decisiones que de verdad importan: dónde viven los datos, cómo sabe Docker que un servicio está listo, dónde van las contraseñas y qué puertos conviene no abrir. Todos los ejemplos se ejecutan en tu navegador a través del generador; nada se envía a un servidor.

Elige tu stack

Stack	Para qué	Nivel	Healthcheck	Riesgo principal
PostgreSQL	Base de datos para una app en desarrollo	Básica	Sí	Cambiar la contraseña sin borrar el volumen viejo
PostgreSQL + pgAdmin	Administrar la base de datos con una interfaz web	Básica	Sí	Exponer pgAdmin a Internet sin protección
Redis con contraseña	Caché o cola para una app	Básica	Sí	Dejar Redis sin contraseña y con el puerto abierto
Node.js + PostgreSQL	App propia que arranca junto a su base de datos	Media	Sí	ECONNREFUSED por arrancar antes de que la DB esté lista
Nginx como reverse proxy	Poner una app detrás de un proxy en una red interna	Media	Sí	Error 502 por apuntar a un host o puerto equivocado
WordPress + MariaDB	WordPress local con su base de datos	Media	Sí	Perder los uploads por no tener su propio volumen
Prometheus + Grafana	Métricas y dashboards en local	Media	No	Creer que esto ya es observabilidad de producción

Qué elegir si...

Solo necesitas una base de datos: empieza por PostgreSQL. Es el caso más común y el que mejor enseña volúmenes y healthchecks.
Quieres ver y editar los datos con clics: añade pgAdmin con PostgreSQL + pgAdmin.
Tu app y su base de datos arrancan juntas: usa Node.js + PostgreSQL para aprender a esperar a que la DB acepte conexiones.
Necesitas caché o colas: Redis con contraseña cubre persistencia y autenticación.
Pones una app detrás de un proxy: Nginx como reverse proxy explica la red interna y cómo diagnosticar un 502.

Lo que comparten todos estos ejemplos

Tres decisiones se repiten en cada guía porque son las que más errores evitan. Si entiendes estas tres, el resto es detalle de cada servicio.

Datos en volúmenes con nombre. Sin un volumen, docker compose down se lleva tu base de datos. Con uno (postgres_data:/var/lib/postgresql/data), los datos sobreviven. Recuerda: un volumen no es un backup.
Salud antes que orden. Un healthcheck le dice a Docker si un servicio está listo, no solo si arrancó. Es lo que permite que depends_on espere de verdad, como se explica en la guía de healthchecks y depends_on.
Secretos por variable. Nada de contraseñas en el compose.yaml: van por ${VARIABLE} y viven en un .env fuera de git. Versiona solo un .env.example con CHANGE_ME.

Siguientes pasos

Genera cualquiera de estos stacks con el generador y validador de Docker Compose y pega tu propio archivo para revisarlo. Si quieres entender a fondo cómo se espera entre servicios, lee la guía de healthchecks, depends_on y secretos.

Preguntas frecuentes

¿Estos compose.yaml están listos para producción?: No. Son puntos de partida pensados para desarrollo y aprendizaje en local. Cubren lo que más se olvida (volúmenes con nombre, healthchecks, secretos por variable, puertos no expuestos por defecto), pero producción necesita más: backups probados, TLS, secretos gestionados fuera de git, límites de recursos y, casi siempre, un orquestador o un proveedor gestionado. Cada guía dice explícitamente qué le falta para producción.
¿Qué stack elijo para empezar?: Si solo necesitas una base de datos para tu app, empieza por PostgreSQL. Si quieres administrarla con clics, PostgreSQL + pgAdmin. Si tu app vive en el mismo compose que la base de datos, Node.js + PostgreSQL te enseña a esperar a que la DB esté lista. Para caché o colas, Redis con contraseña. La tabla de arriba resume el caso de uso y el riesgo principal de cada uno.
¿Por qué casi ninguno expone el puerto de la base de datos?: Porque dentro de Compose los servicios se hablan por su nombre en la red interna (por ejemplo app se conecta a postgres:5432) sin publicar nada al host. Publicar 5432 o 3306 abre la base de datos a toda la red de tu máquina. En las guías solo publicamos un puerto cuando de verdad necesitas acceder desde el host, y entonces lo atamos a 127.0.0.1 para que no salga de tu equipo.
¿Puedo generar estos archivos en vez de copiarlos a mano?: Sí. Cada guía enlaza al generador de Docker Compose con su preset ya seleccionado: eliges opciones (healthcheck, volúmenes, puerto local) y obtienes el compose.yaml y el .env.example. También puedes pegar tu propio archivo en el validador para detectar secretos en texto plano, puertos de base de datos expuestos, imágenes con :latest y depends_on sin condición de salud.
¿Las contraseñas de los ejemplos son reales?: No. Todos los .env.example usan el placeholder CHANGE_ME a propósito. Debes sustituirlo por un valor propio en un archivo .env que nunca subes a git. Versiona solo el .env.example para documentar qué variables hacen falta, no sus valores.