Deploy no Coolify e na Hostinger

A composição contém web, API, worker, migração e PostgreSQL. Somente web acessa a rede do proxy público; a infraestrutura existente é preservada.

Configuração

Gere segredos novos de produção para banco, criptografia, chaves e sessões. Guarde o arquivo privado fora das releases. Credenciais do dono do banco entram apenas no PostgreSQL e na migração; a aplicação usa um papel restrito.

Use APP_URL=https://magnum.lat. Configure Resend com RESEND_API_KEY e RESEND_FROM autorizado, ou mantenha SMTP com SMTP_URL e MAIL_FROM. Se RESEND_FROM estiver vazio, o Resend usa MAIL_FROM. SMTP em produção exige TLS. Mantenha AUTH_ALLOW_SIGNUP=false até validar uma entrega real autorizada; depois habilite o cadastro explicitamente. Configure contato público e identificação jurídica reais. Configure FOUR_P_API_KEY somente no ambiente privado da API e do worker, sob gestão do operador do Magnum. O estabelecimento não configura nem recebe essa credencial global; cadastra seus endereços fixos por rede e ativo nas configurações autenticadas. A chave e os destinos salvos não ativam pagamentos reais, que dependem de autorização expressa da 4P para o modelo comercial.

Proxy existente

Combine compose.yaml e compose.hostinger.yaml, usando a rede externa coolify. A configuração publica diagnóstico somente em 127.0.0.1:13100 e reserva rotas exclusivas de magnum.lat. Ela não toma as portas 80/443 nem reinicia o proxy compartilhado.

Use TRUST_PROXY_HOPS=1 apenas nesta topologia protegida: Traefik sanitiza os headers, web encaminha a cadeia e a API confia em um salto. Não exponha a porta interna publicamente.

Mantenha TRAEFIK_ENABLED=false até confirmar DNS e smoke tests. Altere apenas A/AAAA do site, preservando MX/TXT de e-mail. Depois habilite a rota e confira certificado Let's Encrypt e HTTPS. Uma rota configurada não comprova publicação.

docker compose --env-file /opt/magnum/shared/.env -f compose.yaml -f compose.hostinger.yaml config --quiet
docker compose --env-file /opt/magnum/shared/.env -f compose.yaml -f compose.hostinger.yaml build
docker compose --env-file /opt/magnum/shared/.env -f compose.yaml -f compose.hostinger.yaml up -d

Não imprima docker compose config sem --quiet: a saída contém segredos resolvidos.

Deploy automático a partir da main

.github/workflows/ci.yml valida pull requests e pushes na main com instalação pelo lockfile, migrações no PostgreSQL local, typecheck, testes, build de produção e formatação. O deploy exige validação concluída na main. Uma execução manual do workflow na main usa a mesma validação; pull requests nunca publicam. Os deploys são serializados sem cancelar uma publicação em andamento.

Configure estes secrets do repositório no GitHub Actions:

O workflow exige verificação estrita da chave do servidor e envia somente deploy <SHA de 40 caracteres>. O comando restrito instalado em /opt/magnum/shared/deploy-main.sh rejeita outros comandos, adquire um lock, busca origin/main usando chave somente de leitura específica do repositório e confere se seu topo ainda corresponde ao SHA solicitado. Uma revisão ultrapassada ou já publicada é ignorada.

O servidor cria a release imutável em /opt/magnum/releases/main-<12-primeiros-caracteres-do-SHA>, registra REVISION, gera imagens separadas de api, worker, migrate e web com o SHA completo e grava as referências exatas em compose.images.yaml. A configuração privada de banco e produção permanece fora do Git em /opt/magnum/shared/.env.

Antes de migrar, o deploy executa /opt/magnum/shared/backup.sh. Depois executa a imagem de migração da release, inicia apenas os serviços da aplicação com imagens fixadas, aguarda a saúde dos contêineres e verifica a raiz HTTPS pública. Somente após essas verificações atualiza /opt/magnum/current e /opt/magnum/shared/deployed-commit.

Falha ao iniciar a aplicação ou na verificação HTTPS restaura as imagens fixadas de api, worker e web da release anterior. Esse rollback não rebaixa o banco nem restaura um dump automaticamente. Uma falha de migração interrompe o deploy antes de substituir os serviços da aplicação. As migrações precisam continuar compatíveis com a versão anterior da aplicação.

Release e rollback

Fontes em /opt/magnum/releases/<release-id>, configuração em /opt/magnum/shared e link current para a release selecionada. O projeto Compose permanece magnum para preservar o volume de dados.

Antes de atualizar, verifique dump PostgreSQL, backup da configuração afetada e manifesto de checksums. Valide PT/EN, capacidades, saúde da API, worker, papel do banco e políticas de iframe. Verifique entrega real pelo Resend ou SMTP antes de liberar cadastro. Aceite pelo provedor não comprova chegada à caixa de entrada. Reinicie contêineres e confirme persistência.

Cada deploy deve preservar um compose.images.yaml com as imagens de web, API, worker e migração fixadas às tags da release ou a digests imutáveis. Mantenha essas imagens localmente ou em um registro autorizado. Trocar apenas o diretório de código não basta: a composição base contém builds e pode reutilizar uma imagem diferente da esperada.

Para reverter, entre na release anterior verificada e use seu manifesto de imagens com a mesma configuração privada, nome de projeto e volumes:

test -f compose.images.yaml
docker compose --env-file /opt/magnum/shared/.env \
  -f compose.yaml -f compose.hostinger.yaml -f compose.images.yaml config --quiet
docker compose --project-name magnum --env-file /opt/magnum/shared/.env \
  -f compose.yaml -f compose.hostinger.yaml -f compose.images.yaml \
  up -d --no-build --no-deps --wait api worker web

Esse rollback manual da aplicação exclui PostgreSQL e o serviço de migração. Confirme que as imagens fixadas existem antes de alterar o serviço e repita as verificações de rotas, banco e worker. Atualize o link current e o registro da revisão publicada somente após validar a restauração. Para uma correção adiante, publique uma nova revisão verificada na main; o script rejeita intencionalmente um SHA antigo que não seja mais origin/main. Sem esse manifesto, reconstrua explicitamente o código anterior verificado antes de reiniciar; um diretório antigo não identifica sozinho um binário antigo. Confira a compatibilidade das migrações. Não reverta esquema destrutivamente sem revisão e backup.

Na primeira release, docker compose down com os arquivos exclusivos do Magnum remove somente seus serviços e rotas. Não use --volumes. Preserve o proxy e todos os outros sites.

O Dockerfile aceita build_resolv opcional para ambientes com DNS de build inacessível. O arquivo é montado apenas durante o build, sem alterar o DNS do host nem entrar na imagem.