Migração do messenger-api para Hetzner Cloud via Coolify

TLDR: sair do Heroku para servidores próprios na Hetzner Cloud (US), com deploy gerenciado pelo Coolify — reduzindo custo e mantendo (ou melhorando) disponibilidade.

Contexto

A aplicação rodava no Heroku. O objetivo era migrar para uma infraestrutura gerenciada própria, mantendo a mesma disponibilidade ou melhorando a confiabilidade, com custo de operação menor. Os servidores rodariam na Hetzner Cloud, em território americano.

Objetivos

  • 2 servidores para a aplicação web.
  • 1 servidor para o worker de background jobs.
  • Aplicação e worker publicados como container Docker (targets production e worker de um único Dockerfile — arquivo removido do repositório na migração posterior para AWS EKS).
  • Banco de dados permanece no Heroku na primeira fase; migração do banco para Hetzner seria feita depois.
  • Uma instância Coolify responsável por build e armazenamento das imagens, além do deploy em produção.
  • Apenas o ambiente de produção seria movido nesta fase.

Fora de escopo

  • Migração do banco de dados (ficaria para uma fase posterior).
  • Ambientes de staging/desenvolvimento.

Mudanças

  • Imagem Docker publicada em um registro privado, rodando como serviço do Coolify.
  • 3 servidores provisionados em Ashburn, VA (USA) (us-east na Hetzner), Ubuntu 24.04:
    • 2 servidores web (2 vCPU, 2 GB RAM, 40 GB disco).
    • 1 servidor worker (2 vCPU, 2 GB RAM, 40 GB disco).
    • 1 load balancer com round robin na frente dos servidores web; certificados SSL provisionados e geridos pela Hetzner.
  • Todos os servidores em rede privada, comunicando-se por IP privado quando necessário. O Coolify acessa os servidores via SSH e provisiona as dependências.
  • Ao adicionar um novo servidor, era necessário liberar acesso à internet via NAT gateway antes do provisionamento no Coolify (configuração única, ver artigo da Hetzner — lá o servidor é chamado de client server).
  • No Coolify, projeto Messenger HUB com ambiente production, contendo os recursos messenger-api e messenger-worker:
    • Tipo de aplicação: Git based, servidor principal selecionado, app do Github pré-configurada para repositórios privados da IBFT.
    • Build Pack: Dockerfile.
    • Nome do recurso ajustado (messenger-api / messenger-worker), domínios próprios removidos (tráfego servido pelo load balancer).
    • Porta mapeada 3000:3000.
    • Em messenger-api, comando de pós-deploy: bundle exec rails db:migrate.
    • Variáveis de ambiente copiadas do Heroku (DATABASE_URL, HEROKU_POSTGRESQL_IVORY_URL, RAILS_MASTER_KEY, SECRET_KEY_BASE, REDIS_URL, entre outras).
  • Deploy para produção automático a cada merge na main: o Coolify monitora a branch e dispara o release. Falha de build ou de boot da aplicação não gera alerta — falha silenciosamente.

Como verificar

  • Confirmar que o deploy dispara automaticamente após merge na main.
  • Confirmar que a API responde no domínio configurado.
  • — (não registrado na spec original: critério explícito de sucesso da migração)

Documentação

Esta migração foi superada: em 2026-07 a aplicação foi migrada da Hetzner/Coolify para AWS EKS (motivo: queda de serviço na Hetzner, aproveitada para adotar o padrão de infraestrutura AWS EKS da organização). Estado atual, pendências e detalhes da nova infraestrutura não fazem parte desta spec histórica.

Pendências ainda abertas na spec original, nunca formalizadas: - Tagging strategy — não definida. - Manutenção de servidores — não definida. - Observabilidade/alarmes de deploy — não implementados.