Blog

Docker, CI/CD y deploy con Coolify para Laravel, Node y WordPress

Actualizado: 14 min de lectura
DockerCI/CDCoolifyDevOpsLaravelWordPress

"Funciona en mi máquina" sale caro. El objetivo de Docker + CI/CD + Coolify es la reproducibilidad: el mismo artefacto que pasó tests llega a staging y, si todo va bien, a producción.

Aplica a APIs Laravel, apps Node, frontends modernos (incluido Astro SSR) y, cuando tiene sentido, WordPress containerizado. En proyectos con checkout o pasarelas, el pipeline es parte del producto.

Pipeline mínimo recomendado

  1. PR: lint + typecheck + tests unitarios (y e2e críticos si aplica).
  2. Build multi-stage: dependencia → build → runtime pequeño.
  3. Tag inmutable: registry/app:gitsha.
  4. Scan básico de imagen.
  5. Deploy a staging en Coolify con las mismas variables (valores distintos).
  6. Smoke / healthcheck.
  7. Promote a producción del mismo digest/tag.

Multi-stage (Laravel / Node)

  • deps: instala Composer/npm con caché.
  • build: npm run build, php artisan optimize, assets.
  • runtime: imagen final con usuario no-root, sin toolchain, sin secretos.

Detalles que evitan incidentes:

  • Capas ordenadas para no invalidar caché de Composer en cada cambio.
  • npm ci en CI, no npm install suelto.
  • Usuario no-root + permisos en storage y bootstrap/cache.

Checklist de release en Laravel

  1. Imagen multi-stage con PHP-FPM u Octane.
  2. Variables en Coolify/secrets del CI, nunca en la imagen.
  3. Migraciones como paso explícito del deploy.
  4. Colas y scheduler con restart policy.
  5. Healthcheck: ruta barata que verifique app + DB.
  6. Rollback: redeploy del tag SHA anterior.

WordPress en Docker

  • Volumen persistente para wp-content/uploads.
  • Secretos vía env / wp-config generado en runtime.
  • Object cache (Redis) como servicio aparte cuando el tráfico lo pide.
  • Multisite: cuidado con dominios, cookies y paths.
  • Backups de DB + uploads antes de updates mayores.

Configuración en Coolify

  • Variables y secrets fuera del Dockerfile.
  • Healthcheck real (HTTP 200, no solo "el proceso existe").
  • Dominios: apex canónico; www con redirect 301.
  • SSL Let's Encrypt en ambos hosts.
  • Restart policies y logs accesibles.
  • Staging y producción separados.

Checklist pre-producción

  • Tag = git SHA (no solo latest)
  • Secrets ausentes del repo y de capas Docker
  • Healthcheck verde en staging
  • Migraciones ensayadas + backup reciente
  • Apex/www y SSL verificados
  • Workers/cron vivos después del deploy
  • Plan de rollback escrito

Errores comunes

  • Rebuild distinto en prod y ya no se sabe qué corre.
  • Healthcheck que pega a / con redirect 301 y marca unhealthy en loop.
  • Volúmenes de WordPress con dueño root.
  • Correr migrate --force dos veces en paralelo.
  • Olvidar el worker de colas: la web está up pero los webhooks no se procesan.

Un checkout mal desplegado es una bomba. El pipeline conecta con pagos y auditoría de seguridad .

Preguntas frecuentes

¿Coolify reemplaza un pipeline CI?

No del todo. Coolify brilla en deploy, SSL, variables y reinicios. El CI (lint/tests/build) sigue siendo responsabilidad de GitHub Actions, GitLab CI u otro runner. Lo habitual es combinarlos.

¿Se puede meter WordPress en Docker?

Sí, con cuidado: volúmenes para uploads, permisos correctos, y nunca dejar wp-config con secretos en la imagen. Para sitios simples a veces no vale la pena; para equipos que ya viven en containers, sí.

¿Se debe usar tag latest en producción?

Conviene evitar `latest` como única referencia. Los tags con git SHA permiten rollback exacto.

¿Qué hacer con las migraciones de base de datos?

Migraciones versionadas, ejecutadas como paso controlado del release, con plan de reverse cuando aplica. No como proceso oficial "a mano en producción".

¿También se configura www y SSL?

Sí. En proxy/Coolify se deja apex canónico, SSL Let's Encrypt y redirect www→non-www. El DNS mal puesto es un bug de producto, no un detalle.