Imagine uma fábrica em que cada produto sai com o mesmo molde, a mesma etiqueta e um controle de qualidade antes de chegar ao cliente. Isso é um bom pipeline de Docker + CI/CD + Coolify: não “subir na mão o que funcionou no meu laptop”, e sim um processo repetível que transforma código em um release confiável.
Este artigo explica, em linguagem clara e com passos concretos, como fazer deploy de APIs Laravel, apps Node e sites WordPress containerizados. Serve a donos de produto que querem menos incidentes, e a times técnicos que precisam de um runbook real — não só um Dockerfile solto.
Por que importa para o negócio
Cada deploy improvisado é risco: um pagamento que para de cobrar, um formulário que cai numa sexta, ou um rollback impossível porque ninguém lembra qual versão está rodando. Um pipeline bem feito reduz o tempo de saída, torna o staging crível e transforma o deploy numa operação mensurável — não num ritual de madrugada.
- Menos “funciona na minha máquina”: o mesmo artefato é testado e promovido.
- Rollback previsível: você volta à tag anterior em minutos, sem adivinhar.
- Auditoria: você sabe qual commit está em produção e quem o promoveu.
- Escala do time: um júnior consegue fazer deploy sem quebrar o ritual do sênior.
Conceitos-chave (simples + técnicos)
Docker: a caixa lacrada
O Docker empacota o app com suas dependências numa imagem. Pense num contêiner de carga: o cais (servidor) pode mudar, o conteúdo viaja igual. Tecnicamente: camadas, Dockerfile multi-stage e um runtime sem toolchain de build nem segredos.
CI/CD: a linha de montagem
CI (integração contínua) valida cada mudança: lint, testes, build. CD (entrega/deploy contínuo) leva o artefato ao staging e, com portões de qualidade, à produção. O Coolify brilha no deploy (SSL, variáveis, reinícios); o CI continua no GitHub Actions, GitLab CI ou outro runner.
Tags imutáveis vs latest
Marcar só como latest é como colocar “versão atual” numa caixa sem número de lote. Use registry/app:gitsha: você sabe exatamente o que roda e pode redeployar esse digest.
| Peça | Analogia | O que faz na prática |
|---|---|---|
| Imagem Docker | Produto empacotado | Mesmo binário/artefato em staging e prod |
| Pipeline CI | Controle de qualidade | Lint, testes, scan, build |
| Coolify | Armazém + envio | Deploy, SSL, env vars, healthcheck |
| Tag SHA | Número de lote | Rollback exato e rastreabilidade |
Guia prático: pipeline mínimo
- PR: lint + typecheck + testes unitários (e e2e críticos se houver checkout).
- Build multi-stage: deps → build → runtime pequeno.
- Tag imutável:
registry/app:gitsha(nunca sólatest). - Scan básico da imagem (CVEs óbvias, usuário root, segredos em camadas).
- Deploy em staging no Coolify com as mesmas variáveis (valores diferentes).
- Smoke / healthcheck: rota barata que verifique app + DB.
- Promote para produção do mesmo digest/tag — sem rebuild diferente.
Multi-stage para Laravel / Node
- deps: Composer/npm com cache de camadas ordenadas.
- build:
npm ci+npm run build,php artisan optimize, assets. - runtime: usuário não-root, sem toolchain, sem
.envembutido. - Permissões corretas em
storageebootstrap/cache(Laravel).
WordPress no Docker
- Volume persistente para
wp-content/uploads. - Segredos via env /
wp-configgerado em runtime — nunca na imagem. - Object cache (Redis) como serviço separado quando o tráfego exigir.
- Multisite: domínios, cookies e paths documentados.
- Backup de DB + uploads antes de updates maiores.
Configuração no Coolify
- Variáveis e secrets fora do Dockerfile.
- Healthcheck real (HTTP 200 numa rota estável, não só “o processo existe”).
- Domínio apex canônico;
wwwcom redirect 301. - SSL Let's Encrypt nos dois hosts.
- Staging e produção separados; restart policies e logs acessíveis.
Erros comuns
- Rebuild diferente em prod: você não sabe mais o que roda nem como reproduzir o bug.
- Healthcheck em
/com redirect 301 → loop de unhealthy. - Volumes do WordPress com dono
root→ uploads quebrados. - Rodar
migrate --forceduas vezes em paralelo. - Esquecer o worker de filas: a web responde, os webhooks não processam.
- Segredos no Git ou em camadas Docker “por comodidade”.
Checklist pré-produção
- Tag = git SHA (não só
latest). - Secrets ausentes do repo e das camadas Docker.
- Healthcheck verde em staging com a mesma imagem.
- Migrações ensaiadas + backup recente.
- Apex /
wwwe SSL verificados. - Workers e cron vivos depois do deploy.
- Plano de rollback escrito (redeploy do SHA anterior).
- Nomes de variáveis alinhados entre staging e prod; valores diferentes.
Um checkout mal implantado é uma bomba. O pipeline conecta com pagamentos e auditoria de segurança .