Heroku morreu. E agora?

Em 6 de fevereiro de 2026, a Heroku publicou um comunicado que muitos desenvolvedores já temiam há anos: a plataforma está entrando em “modo de engenharia sustentável”.

Traduzindo, isso significa o seguinte: F

Sem novos recursos, sem novos contratos enterprise para novos clientes, e foco exclusivo em manter as luzes acesas.

É o começo do fim de uma era.

Para quem construiu produtos inteiros em cima do Heroku, a notícia é um misto de nostalgia e urgência.

A plataforma que pioneirizou o git push para deploy, que tornou a infraestrutura acessível para desenvolvedores que só queriam escrever código — essa plataforma está, oficialmente, em modo de manutenção.

Se você ainda roda aplicações no Heroku, este artigo é para você.

O que é Heroku? 🤔
Se você caiu aqui de paraquedas e está por fora do assunto, o Heroku é uma plataforma em nuvem baseada em contêineres, classificada como uma PaaS (Platform as a Service — Plataforma como Serviço). Na prática, ele permite que desenvolvedores criem, executem e gerenciem aplicativos inteiramente na nuvem, sem se preocupar com a infraestrutura do servidor subjacente — um dos fatores que popularizou o serviço ao longo da última década (além da aquisição pela SelasForce que também impulsionou a plataforma).

O que realmente significa “engenharia sustentável”

Vamos ser diretos: “engenharia de sustentação” é a forma polida de dizer que o produto, literalmente, parou no tempo.

Não haverá novas funcionalidades, sem novos updates, e não haverá novos contratos enterprise para clientes entrantes.

O time vai manter o que existe funcionando, e só…

A comunidade de desenvolvedores reagiu com uma combinação de tristeza e urgência — e com razão.

Porque a plataforma estava estagnada há anos, e esse anúncio apenas tornou oficial o que muitos já sabiam.

A questão agora não é se você deve migrar, mas quando — e para onde.

---

Por que você deveria migrar imediatamente

A tentação é esperar.

Afinal, a plataforma não vai cair amanhã.

Mas há boas razões para não procrastinar:

1. A migração fica mais complexa com o tempo. Dependências acumulam, configurações ficam desatualizadas, e o conhecimento de quem subiu a aplicação original vai embora. Quanto mais você espera, mais trabalhoso fica.
2. A plataforma vai defasar ainda mais. Sem novos recursos, o Heroku vai ficar cada vez mais para trás em relação a alternativas modernas — em segurança, performance e integração com o ecossistema atual.
3. Migrar no seu ritmo é muito melhor que migrar sob pressão. Equipes que fazem a transição de forma planejada consistentemente têm resultados melhores do que as que migram às pressas quando algo quebra.

Migrar agora significa ter controle. Esperar significa reagir.

E todos sabemos o que acontece quando esse tipo de operação é feita às pressas… 😬

Como fazer a migração — ckecklist completo

Independente da plataforma que você vai escolher, a estrutura da migração é parecida.

Aqui está o processo que funciona na prática:

1. Mapeie o que você tem no Heroku

Antes de mover qualquer coisa, documente tudo:

# Liste todas as suas aplicações (em um time/organização)
heroku apps --team SEU_TIME

# Para cada aplicação, colete as informações essenciais:

# Dynos em execução e tipos (web, worker, clock...)
heroku ps --app NOME_DO_APP

# Tipo de dyno contratado (Standard-1X, Standard-2X, Performance...)
heroku ps:type --app NOME_DO_APP

# Todas as variáveis de ambiente — guarde isso com segurança
heroku config --app NOME_DO_APP

# Add-ons ativos (Postgres, Redis, Scheduler, Papertrail...)
heroku addons --app NOME_DO_APP

# Domínios customizados configurados
heroku domains --app NOME_DO_APP

# Conteúdo do Procfile (processos da aplicação)
heroku run cat Procfile --app NOME_DO_APP

Anote tudo em um documento de migração: tipos de dynos, add-ons com planos contratados, variáveis de ambiente, domínios customizados e cada linha do Procfile.

Esses são os inputs para configurar o ambiente equivalente na nova plataforma.

2. Escolha a plataforma de destino

Existe um leque amplo de alternativas, cada uma com um perfil diferente:

Mais próximas da experiência Heroku (PaaS):

• Render — a alternativa mais parecida com o Heroku, com custos previsíveis e workflow familiar
• Fly.io — excelente performance com deploy global, ideal para aplicações sensíveis a latência
• Railway — setup rápido, ótimo para projetos de pequeno a médio porte
• Hatchbox — feito especificamente para Ruby/Rails, roda em cima de DigitalOcean ou Hetzner
• DigitalOcean App Platform — gerenciamento visual simples para times que querem simplicidade
• Porter — PaaS em cima da sua própria conta cloud (AWS, GCP, Azure)

Plataformas enterprise (mais controle, mais complexidade):

• AWS (ECS/Fargate) — máxima flexibilidade, curva de aprendizado mais íngreme
• Google Cloud Run — containers gerenciados com auto-scaling
• Azure App Service — sólido para quem já está no ecossistema Microsoft
• Hetzner — custo-benefício excelente para times confortáveis com self-managed

Não existe substituto mágico universal.

A melhor escolha depende do tamanho do time, orçamento, linguagem usada e requisitos de compliance.

3. Migre os bancos de dados primeiro

Regra de ouro: sempre migre os dados antes de mover a aplicação.

Uma migração com dados desatualizados é um problema; uma migração com dados corretos que falha no deploy é reversível.

Para o Heroku Postgres:

# 1. Ative o modo de manutenção para garantir consistência dos dados
heroku maintenance:on --app NOME_DO_APP

# 2. Capture um backup completo (formato custom do pg_dump)
heroku pg:backups:capture --app NOME_DO_APP

# 3. Baixe o arquivo de backup
heroku pg:backups:download --app NOME_DO_APP
# Gera o arquivo: latest.dump

# 4. Restaure no novo banco de dados (PostgreSQL na plataforma destino)
pg_restore --verbose --no-acl --no-owner \
  --dbname="postgresql://usuario:senha@host:5432/nome_banco" \
  latest.dump

# Para bancos grandes (acima de 20 GB), use paralelização para acelerar
pg_restore --verbose --no-acl --no-owner \
  --jobs=4 \
  --dbname="postgresql://usuario:senha@host:5432/nome_banco" \
  latest.dump

Atenção: após pg_restore, sempre verifique a integridade dos dados com SELECT count(*) nas tabelas principais e valide constraints e sequences antes de desativar o modo de manutenção.

Para o Heroku Redis:

Se você usa Redis apenas como cache (sessões, fragmentos de view, rate limiting), muitas vezes não é necessário migrar os dados — basta criar um novo Redis na plataforma destino e apontar a aplicação para ele. O cache se reconstrói naturalmente.

Se o Redis é usado como fila persistente (Sidekiq, Resque, BullMQ), você precisa garantir que todos os jobs em andamento terminem antes de fazer o cutover, ou migrar a fila com a aplicação em modo de manutenção.

4. Configure a nova aplicação

Na plataforma escolhida:

• Crie o projeto e o ambiente equivalente (production, staging, etc.)
• Copie todas as variáveis de ambiente capturadas no passo 1, substituindo as connection strings pelas novas (banco, Redis, serviços externos)
• Configure o processo de build: a maioria das plataformas modernas aceita Dockerfile ou os mesmos buildpacks do Heroku (Cloud Native Buildpacks / Heroku Buildpacks)
• Para aplicações com múltiplos processos definidos no Procfile (ex.: web, worker, clock), crie serviços separados para cada processo — a maioria das plataformas PaaS modernas suporta isso nativamente

Exemplo de Procfile comum e o equivalente na nova plataforma:

# Procfile original (Heroku)
web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq -C config/sidekiq.yml
clock: bundle exec clockwork config/clock.rb

No Render, Railway ou Fly.io, cada linha se torna um serviço independente com seu próprio scaling e configuração de recursos.

5. Valide antes de cortar o DNS

Antes de apontar seu domínio para a nova plataforma, valide tudo na URL temporária gerada pela plataforma:

• Teste a aplicação na nova URL e confirme que ela responde corretamente
• Acompanhe os logs em tempo real durante os testes (fly logs, railway logs, render logs)
• Confirme que as conexões com banco e Redis estão funcionando e com latência aceitável
• Valide as migrations de banco (schema atualizado, sequences corretas)
• Teste os fluxos críticos da aplicação: autenticação, pagamento, operações com escrita no banco, envio de e-mail, integrações com serviços externos
• Verifique o comportamento dos workers e jobs agendados

6. Atualize o DNS e vá ao ar

Quando tudo estiver validado:

• Adicione seu domínio customizado na nova plataforma (a maioria provisiona certificados TLS automaticamente via Let’s Encrypt)
• Reduza o TTL do DNS para 300 segundos (5 minutos) com antecedência para acelerar a propagação durante o cutover
• Atualize os registros DNS (CNAME ou A) para apontar para a nova plataforma
• Monitore erros e latência nos primeiros minutos após o cutover
• Mantenha o Heroku rodando em paralelo por 48–72 horas como fallback, com modo de manutenção ativo, antes de desprovisionar

O que acontece com o Heroku no longo prazo?

A plataforma continuará funcionando e contratos existentes serão honrados.

Mas o futuro é previsível: sem novos recursos, sem novos clientes enterprise, sem crescimento.

É a Salesforce dizendo, de forma educada, que o Heroku parou de ser prioridade.

O produto que uma vez definiu como pensamos em deploy de aplicações agora entra em modo de manutenção.

O Heroku ainda pode funcionar por meses ou anos.

Mas a janela para migrar com calma — no seu ritmo, para a plataforma certa e sem pressão — vai se fechando a cada dia.

Migrar resolve a infra — mas e a arquitetura?

Mover sua aplicação de plataforma resolve onde sua aplicação roda, mas não resolve como ela roda.

Se você usa Heroku e lida com jobs longos, filas de processamento, workers, retries, cron jobs ou fluxos complexos de integração, a migração é uma ótima oportunidade para repensar a arquitetura — não apenas a infraestrutura.

Muitas equipes descobrem que, ao sair do Heroku, surge um novo desafio:

Toda a orquestração que antes era invisível agora precisa ser construída, operada e monitorada manualmente.

Portanto, se a sua dor vai além do “onde rodar” e envolve “como construir aplicações que escalam sem virar um pesadelo de manutenção”, você precisa conhecer o skail.

O skail não é uma plataforma de hosting — é uma camada que roda junto com sua aplicação e cuida do que torna sistemas distribuídos complexos: execução resiliente, hibernação de estado, retries automáticos, observabilidade nativa e suporte a fluxos longos (horas ou dias) sem depender de workers, filas ou cron jobs manuais.

Você continua codando do jeito que já sabe, em C# ou Java, usando um único decorator [SkailFunction].

A aplicação ganha robustez, rastreabilidade e escala desde o início — sem reescrever do zero, sem trocar de infraestrutura e sem transformar a equipe em especialista em orquestração.

Saca só 👇

[SkailFunction]
public async Task FollowUpClienteAsync(Guid pedidoId)
{
    // Notifica o cliente que o pedido foi entregue
    await notificacaoCmds.EnviarConfirmacaoEntrega(pedidoId);

    // Espera 3 dias — sem timers, jobs ou banco
    // A execução é hibernada e não consome recursos
    await SkailTask.DelayHours(72);

    // Após o período, retoma de onde parou
    var pedido = await pedidosSrv.ObterPedido(pedidoId);
    if (!pedido.AvaliacaoRecebida)
        await notificacaoCmds.EnviarSolicitacaoAvaliacao(pedidoId);
}

Isso é o que o skail chama de escrever código como se falhas não existissem: chamadas de API que falham, updates com timeout, serviços que crasham — nada disso é mais problema seu.

E quando algo dá errado em produção?!

Em vez de vasculhar logs soltos, você usa o Time Travel Debug: volte no tempo, simule exatamente o que aconteceu com os dados reais, e publique um hotfix em minutos.

Se você está migrando do Heroku e quer aproveitar a oportunidade para construir aplicações 10x mais confiáveis, 10x mais rápidas de entregar, coloque o skail à prova.

FAQ