Imagina una fábrica donde cada producto sale con el mismo molde, la misma etiqueta y un control de calidad antes de llegar al cliente. Eso es un buen pipeline de Docker + CI/CD + Coolify: no “subir a mano lo que funcionó en mi laptop”, sino un proceso repetible que convierte código en un release confiable.
Este artículo explica, en lenguaje claro y con pasos concretos, cómo desplegar APIs Laravel, apps Node y sitios WordPress containerizados. Sirve a dueños de producto que quieren menos incidentes, y a equipos técnicos que necesitan un runbook real — no solo un Dockerfile suelto.
Por qué importa para el negocio
Cada deploy improvisado es riesgo: un pago que deja de cobrar, un formulario que cae un viernes, o un rollback imposible porque nadie recuerda qué versión corre. Un pipeline bien hecho reduce tiempo de salida, hace el staging creíble y convierte el deploy en una operación medible — no en un ritual de medianoche.
- Menos “funciona en mi máquina”: el mismo artefacto se prueba y se promueve.
- Rollback predecible: vuelves al tag anterior en minutos, no a adivinar.
- Auditoría: sabes qué commit está en producción y quién lo promovió.
- Escalado del equipo: un junior puede desplegar sin romper el ritual del senior.
Conceptos clave (simple + técnico)
Docker: la caja sellada
Docker empaqueta la app con sus dependencias en una imagen. Piensa en un contenedor de envío: da igual el muelle (servidor), el contenido viaja igual. Técnicamente: capas, Dockerfile multi-stage y un runtime sin toolchain de build ni secretos.
CI/CD: la línea de ensamblaje
CI (integración continua) valida cada cambio: lint, tests, build. CD (entrega/despliegue continuo) lleva el artefacto a staging y, con puertas de calidad, a producción. Coolify brilla en el deploy (SSL, variables, reinicios); el CI sigue en GitHub Actions, GitLab CI u otro runner.
Tags inmutables vs latest
Etiquetar solo como latest es como poner “versión actual” en una caja sin número de lote. Usa registry/app:gitsha: sabes exactamente qué corre y puedes redeployar ese digest.
| Pieza | Analogía | Qué hace en la práctica |
|---|---|---|
| Imagen Docker | Producto empaquetado | Mismo binario/artefacto en staging y prod |
| Pipeline CI | Control de calidad | Lint, tests, scan, build |
| Coolify | Almacén + envío | Deploy, SSL, env vars, healthcheck |
| Tag SHA | Número de lote | Rollback exacto y trazabilidad |
Guía práctica: pipeline mínimo
- PR: lint + typecheck + tests unitarios (y e2e críticos si hay checkout).
- Build multi-stage: deps → build → runtime pequeño.
- Tag inmutable:
registry/app:gitsha(nunca sololatest). - Scan básico de imagen (CVEs obvias, usuario root, secretos en capas).
- Deploy a staging en Coolify con las mismas variables (valores distintos).
- Smoke / healthcheck: ruta barata que verifique app + DB.
- Promote a producción del mismo digest/tag — no rebuild distinto.
Multi-stage para Laravel / Node
- deps: Composer/npm con caché de capas ordenadas.
- build:
npm ci+npm run build,php artisan optimize, assets. - runtime: usuario no-root, sin toolchain, sin
.envhorneado. - Permisos correctos en
storageybootstrap/cache(Laravel).
WordPress en Docker
- Volumen persistente para
wp-content/uploads. - Secretos vía env /
wp-configgenerado en runtime — nunca en la imagen. - Object cache (Redis) como servicio aparte cuando el tráfico lo pide.
- Multisite: dominios, cookies y paths documentados.
- Backup de DB + uploads antes de updates mayores.
Configuración en Coolify
- Variables y secrets fuera del Dockerfile.
- Healthcheck real (HTTP 200 en una ruta estable, no solo “el proceso existe”).
- Dominio apex canónico;
wwwcon redirect 301. - SSL Let's Encrypt en ambos hosts.
- Staging y producción separados; restart policies y logs accesibles.
Errores comunes
- Rebuild distinto en prod: ya no sabes qué corre ni cómo reproducir el bug.
- Healthcheck a
/con redirect 301 → loop de unhealthy. - Volúmenes de WordPress con dueño
root→ uploads rotos. - Correr
migrate --forcedos veces en paralelo. - Olvidar el worker de colas: la web responde, los webhooks no se procesan.
- Secretos en Git o en capas Docker “por comodidad”.
Checklist pre-producción
- Tag = git SHA (no solo
latest). - Secrets ausentes del repo y de capas Docker.
- Healthcheck verde en staging con la misma imagen.
- Migraciones ensayadas + backup reciente.
- Apex /
wwwy SSL verificados. - Workers y cron vivos después del deploy.
- Plan de rollback escrito (redeploy del SHA anterior).
- Variables de staging y prod alineadas en nombres, no en valores.
Un checkout mal desplegado es una bomba. El pipeline conecta con pagos y auditoría de seguridad .