Pular para o conteúdo principal

Deploy

Última atualização: 16/09/2026.

Como o AMPLIA sobe em cada ambiente, o que a imagem faz e como reverter.

Ambientes​

AmbienteUsoRuntime típico
localdesenvolvimentodocker compose na 8080 ou Laragon
HMLhomologação / QAmesma imagem, APP_ENV ≠ production, tokens MOVINGPAY_*_HML
produçãooperaçãoimagem app, TLS no proxy, TRUST_PROXY=1, SESSION_SECURE=1

Não há GitHub Actions nem GitLab CI neste repositório. O pipeline real é: build da imagem → push no registry do host → atualizar env no painel → recriar o container.

Artefato​

Dockerfile multi-stage:

  1. css — Node 22, npm ci, npm run build:css
  2. vendor — Composer --no-dev --optimize-autoloader
  3. runtime — php:8.3-fpm-alpine + nginx, extensões mysqli/pdo_mysql/gd/zip/opcache/mbstring

A pasta docker/ é copiada e apagada no final da imagem (RUN rm -rf docker). O entrypoint já está em /entrypoint.sh.

Healthcheck da imagem: wget http://127.0.0.1/ (porta 80 interna). O endpoint de diagnóstico de negócio é /backend/api/health.php.

Variáveis por ambiente​

Checklist mínimo de produção (valores só no cofre / painel, nunca no git):

  • APP_ENV=production, APP_URL=https://..., APP_PORT no host
  • DB_* apontando para o MySQL de prod (não o de HML)
  • MOVINGPAY_TOKEN_USAGE_*=PROD e tokens de produção
  • SMTP_*, AUTENTIQUE_*, OPENAI_API_KEY
  • Drive: preferir GOOGLE_DRIVE_SERVICE_ACCOUNT_JSON (uma linha) em vez de bind mount
  • TRUST_PROXY=1 se houver load balancer / Cloudflare
  • SESSION_SECURE=1

HML: os mesmos nomes, tokens *_HML e MOVINGPAY_TOKEN_USAGE_*=HML quando quiser forçar sandbox. Nunca misture customer_id de prod em HML.

Sequência de subida​

  1. Backup do banco (dump lógico) antes de migration nova.
  2. Aplicar migrations pendentes em ordem, no mesmo banco do ambiente. Scripts são idempotentes, mas ALTER mal escrito ainda quebra dado.
  3. Build: docker compose build --no-cache (ou o comando do registry).
  4. Recriar o container com o .env do ambiente.
  5. Smoke: health.php, login, um fluxo de leitura (dashboard) e um de escrita (salvar rascunho / lead) com usuário de teste.
  6. Conferir docker compose logs app por WARNING de DB_* ou Drive.

Uploads e sessões estão em volumes nomeados (uploads, sessions, app-logs). Recriar o container não deve apagá-los. Trocar o host sem migrar volume perde arquivos locais (Drive continua no Google).

Estratégia de rollback​

Não há blue/green no repo. Rollback é:

  1. Imagem: apontar o serviço de volta para a tag anterior e recriar o container. Código PHP/CSS volta; volumes permanecem.
  2. Config: restaurar o .env anterior (tokens, APP_URL).
  3. Banco: não há down-migration. Se a release adicionou coluna/tabela compatível, a imagem antiga em geral continua funcionando. Se a release renomeou (ex.: Entrepay → Adquirente) ou quebrou contrato, restaure o dump tirado no passo 1.
  4. Sessões: rollback de imagem pode invalidar sessão se o path/cookie mudou; peça relogin.

Janela: prefira releases em horário comercial baixo para financeiro/comissões.

O que o nginx já protege​

Negado por location: .env, composer.json, vendor/, database/, tools/, docs/, docker/, backend/src, backend/config, backend/logs.

Ainda assim: não publique a imagem com JSON de service account em layer. Use env em runtime.

Sem Docker (legado de hospedagem)​

Alguns ambientes ainda fazem upload/FTP da raiz. Nesse caso:

  • envie vendor/ e assets/css/app.css já buildados;
  • não envie .git, .env, node_modules, tools/_tmp_*;
  • confira permissão de uploads e backend/logs;
  • rode as migrations via CLI SSH, nunca via URL HTTP.

Pós-deploy​

  • Confira rate limit de login (tabela backend_rate_limits).
  • Rotacione segredo se ele passou pelo clipboard do painel compartilhado.
  • Atualize CHANGELOG.md se a tag for release formal.