Heroku em Modo de Manutenção: Como Migrar e as Melhores Alternativas em 2026

skail · 2026-07-20 · 9 min

TL;DR: Em 6 de fevereiro de 2026, a Heroku anunciou modo de "sustaining engineering" — sem novas features, sem novo contrato Enterprise. Nada quebra amanhã, mas o roadmap parou. Veja o checklist de migração e onde entra durabilidade depois do host novo.

O que a Heroku anunciou, e quando

Em 6 de fevereiro de 2026, Nitin T. Bhat, SVP e General Manager da Heroku, publicou "An Update on Heroku" no blog oficial da plataforma. O anúncio: a Heroku entra em modelo de sustaining engineering — foco em estabilidade, segurança e suporte, sem desenvolvimento de novas funcionalidades. O roadmap agora é defensivo: patch de segurança, correção de estabilidade, manutenção de infraestrutura. Nada além disso.

Dois pontos concretos do anúncio:

• Sem novo contrato Enterprise. Clientes Enterprise existentes podem renovar; novos clientes Enterprise não são mais aceitos.
• Cliente de cartão de crédito segue normal. Preço, cobrança, serviço e uso do dia a dia não mudam para quem usa Heroku no plano padrão — apps, pipelines, times e add-ons continuam funcionando como antes.

Ou seja: nada quebra amanhã. Mas o motivo por trás do anúncio importa tanto quanto o anúncio em si — a Salesforce redirecionou o foco estratégico para Agentforce e produtos de IA. Heroku deixou de ser prioridade de crescimento. Uma plataforma em modo de manutenção, por definição, para de evoluir junto com o ecossistema ao redor dela.

Por que vale planejar a migração agora, não depois de quebrar

Três razões concretas para tratar isso como um projeto planejado, não uma reação de última hora:

A complexidade só aumenta com o tempo. Cada add-on novo, cada variável de ambiente, cada integração que sua equipe adiciona na Heroku hoje é mais uma peça para mapear no dia da migração. Migrar agora, com o sistema do tamanho que ele tem hoje, é mais simples do que migrar daqui a dois anos.

A plataforma vai ficando defasada, não quebrada. Sem novas features, o gap entre o que a Heroku oferece e o que o resto do ecossistema evolui só cresce. Isso não é uma falha pontual — é uma tendência que se acumula mês a mês.

Migração planejada supera migração de crise, sempre. Migrar com tempo para testar, validar e ter um plano de rollback é um projeto de engenharia normal. Migrar depois de um add-on descontinuado sem aviso, ou de um incidente que a equipe não consegue mais debugar porque a plataforma parou de evoluir, é uma crise de produção.

Checklist de migração

1. Mapeie a configuração atual da Heroku. Liste dynos (web, worker, quantos de cada), add-ons (Postgres, Redis, filas, monitoramento) e todas as variáveis de ambiente. Rode heroku config e heroku addons para gerar o inventário — não confie na memória do time.

2. Escolha a plataforma de destino. Render, Fly.io e Railway são as opções mais citadas como sucessoras diretas do modelo PaaS da Heroku — deploy simples, git push, sem gerenciar servidor. Se a sua equipe já tem apetite operacional maior, uma VPS ou instância cloud própria (EC2, DigitalOcean) dá mais controle, ao custo de mais responsabilidade de infraestrutura.

3. Migre o banco de dados primeiro. Faça backup do Postgres (heroku pg:backups:capture + pg:backups:download), restaure no destino, e valide com uma amostra de queries reais antes de mover qualquer coisa mais. Banco de dados é a parte da migração com menor margem para erro — teste isso isoladamente, antes de tocar no resto.

4. Configure o ambiente novo. Replique as variáveis de ambiente mapeadas no passo 1. Não copie e cole configuração antiga sem revisar — esse é o momento de descartar variáveis mortas que ninguém mais usa.

5. Valide antes do corte de DNS. Rode a aplicação nova em paralelo à antiga, com um domínio de staging, antes de qualquer mudança de DNS. Compare comportamento lado a lado — não assuma que "buildou sem erro" significa "funciona igual em produção".

6. Atualize o DNS e lance. Corte o DNS por último, com plano de rollback pronto caso algo apareça nas primeiras horas. Mantenha a Heroku antiga ativa por um período de segurança antes de desligar de vez.

O que muda depois que você sai do PaaS

Aqui está o ponto que a maioria dos guias de migração de Heroku não menciona: sair de um PaaS como a Heroku significa herdar responsabilidades que a plataforma escondia de você. Worker dynos com retry manual, filas para processar job em background, lógica de "se isso falhar no meio, como eu retomo" — a Heroku abstraía boa parte disso. Uma VPS ou uma instância cloud própria não abstrai.

É exatamente esse pedaço — o processo de múltiplos passos que precisa lembrar onde parou, sobreviver a um restart, e retomar sem reprocessar tudo do zero — que skail resolve. skail não hospeda sua aplicação e não compete com Render, Fly.io ou Railway nisso — ele roda na infraestrutura que você escolher, como uma camada de execução durável em cima do host novo. Você anota um método com [SkailFunction] e os passos internos com [SkailCommand]; cada passo fica persistido automaticamente, e se o worker cair no meio de um job, ele retoma do passo em que parou — sem fila extra, sem reconstruir estado na mão.

[SkailFunction]
public async SkailTask ProcessarJobEmBackground(Guid jobId)
{
    var dados = await CarregarDados(jobId);
    var resultado = await ProcessarDados(dados);
    await SalvarResultado(jobId, resultado);
    await NotificarConclusao(jobId);
}
[SkailCommand]
public async SkailTask<Dados> CarregarDados(Guid jobId)
{
    return await DadosRepository.Buscar(jobId);
}

Se ProcessarDados for o passo que falha — timeout externo, worker reiniciado, o que for — CarregarDados não roda de novo. O quickstart em C#/.NET mostra o resto do padrão, incluindo como isso convive com o mesmo async/await que você já escreve hoje.

Perguntas frequentes

Preciso migrar imediatamente? Não. Clientes de cartão de crédito continuam funcionando normalmente hoje. Mas "sem urgência hoje" não é o mesmo que "sem prazo" — quanto mais o gap entre a Heroku e o resto do ecossistema cresce, mais cara fica a migração.

Vou precisar reescrever a aplicação? Não, na maioria dos casos. A aplicação em si (o código da sua API, seus workers) geralmente roda sem alteração no destino novo — o trabalho está em replicar configuração, add-ons e o pipeline de deploy, não em reescrever lógica de negócio.

Quanto tempo leva uma migração assim? Depende do número de add-ons e da complexidade do banco de dados, mas o checklist acima — mapear, escolher destino, migrar banco, configurar, validar, cortar DNS — é o mesmo roteiro para uma aplicação pequena ou uma com dezenas de add-ons. O que muda é o tempo em cada etapa, não as etapas.

Como escolher entre Render, Fly.io, Railway ou uma VPS própria? Se o objetivo é manter a simplicidade de deploy da Heroku com o menor atrito possível, Render, Fly.io e Railway são o caminho mais direto. Se a equipe já opera infraestrutura própria ou precisa de mais controle sobre workers e processos de longa duração, uma VPS ou instância cloud abre espaço para adicionar execução durável nesse pedaço específico, sem depender de mais um add-on de terceiros para orquestrar retry.