Blog

Docker, CI/CD e deploy com Coolify para Laravel, Node e WordPress

Atualizado: 14 min de leitura
DockerCI/CDCoolifyDevOpsLaravelWordPress

"Funciona na minha máquina" sai caro. O objetivo de Docker + CI/CD + Coolify é reprodutibilidade: o mesmo artefato que passou nos testes chega a staging e, se tudo correr bem, a produção.

Aplica-se a APIs Laravel, apps Node, frontends modernos (incluindo Astro SSR) e, quando faz sentido, WordPress containerizado. Em projetos com checkout ou gateways, o pipeline é parte do produto.

Pipeline mínimo recomendado

  1. PR: lint + typecheck + testes unitários (e e2e críticos se aplicável).
  2. Build multi-stage: dependência → build → runtime pequeno.
  3. Tag imutável: registry/app:gitsha.
  4. Scan básico de imagem.
  5. Deploy em staging no Coolify com as mesmas variáveis (valores distintos).
  6. Smoke / healthcheck.
  7. Promote para produção do mesmo digest/tag.

Multi-stage (Laravel / Node)

  • deps: instala Composer/npm com cache.
  • build: npm run build, php artisan optimize, assets.
  • runtime: imagem final com usuário não-root, sem toolchain, sem secrets.

Detalhes que evitam incidentes:

  • Camadas ordenadas para não invalidar cache do Composer a cada mudança.
  • npm ci no CI, não npm install solto.
  • Usuário não-root + permissões em storage e bootstrap/cache.

Checklist de release no Laravel

  1. Imagem multi-stage com PHP-FPM ou Octane.
  2. Variáveis no Coolify/secrets do CI, nunca na imagem.
  3. Migrações como passo explícito do deploy.
  4. Filas e scheduler com restart policy.
  5. Healthcheck: rota barata que verifica app + DB.
  6. Rollback: redeploy da tag SHA anterior.

WordPress no Docker

  • Volume persistente para wp-content/uploads.
  • Secrets via env / wp-config gerado em runtime.
  • Object cache (Redis) como serviço separado quando o tráfego exige.
  • Multisite: cuidado com domínios, cookies e paths.
  • Backups de DB + uploads antes de updates maiores.

Configuração no Coolify

  • Variáveis e secrets fora do Dockerfile.
  • Healthcheck real (HTTP 200, não só "o processo existe").
  • Domínios: apex canônico; www com redirect 301.
  • SSL Let's Encrypt em ambos os hosts.
  • Restart policies e logs acessíveis.
  • Staging e produção separados.

Checklist pré-produção

  • Tag = git SHA (não só latest)
  • Secrets ausentes do repo e das camadas Docker
  • Healthcheck verde em staging
  • Migrações ensaiadas + backup recente
  • Apex/www e SSL verificados
  • Workers/cron vivos após o deploy
  • Plano de rollback escrito

Erros comuns

  • Rebuild diferente em prod e já não se sabe o que roda.
  • Healthcheck que bate em / com redirect 301 e marca unhealthy em loop.
  • Volumes WordPress com dono root.
  • Rodar migrate --force duas vezes em paralelo.
  • Esquecer o worker de filas: a web está up mas os webhooks não são processados.

Um checkout mal deployado é uma bomba. O pipeline conecta com pagamentos e auditoria de segurança .

Perguntas frequentes

O Coolify substitui um pipeline de CI?

Não totalmente. O Coolify brilha em deploy, SSL, variáveis e reinícios. O CI (lint/testes/build) continua sendo responsabilidade do GitHub Actions, GitLab CI ou outro runner. O habitual é combiná-los.

Dá para colocar WordPress no Docker?

Sim, com cuidado: volumes para uploads, permissões corretas e nunca deixar wp-config com secrets na imagem. Para sites simples às vezes não vale a pena; para equipes que já vivem em containers, sim.

Deve-se usar tag latest em produção?

Convém evitar `latest` como única referência. Tags com git SHA permitem rollback exato.

O que fazer com migrações de banco de dados?

Migrações versionadas, executadas como passo controlado do release, com plano de reverse quando aplicável. Não como processo oficial "manual em produção".

www e SSL também são configurados?

Sim. No proxy/Coolify define-se apex canônico, SSL Let's Encrypt e redirect www→non-www. DNS mal configurado é bug de produto, não detalhe.