Heroku auto-hospedado em 2026: o estado do segmento

Em 28 de novembro de 2022, a Salesforce desligou o plano gratuito do Heroku. A empresa que comprou a Heroku em 2010 cumpriu o aviso publicado três meses antes — todas as dynos free, todos os bancos hobby, todos os redises gratuitos foram terminados na mesma janela. Centenas de milhares de hobby projects, MVPs, demos de portfólio e protótipos universitários sumiram do ar de uma só vez.

A reação foi previsível. Quem tinha cobrança no cartão migrou pro plano pago e seguiu. Quem não tinha procurou outro lugar. E nas semanas seguintes, um movimento que existia em estado adormecido desde 2013 explodiu: "Heroku auto-hospedado".

Em 2026, três anos e meio depois, o segmento amadureceu. Há pelo menos seis produtos sérios disputando atenção, mais um punhado de projetos hospedados que se vendem como "Heroku-like" sem o auto. Esse post é o mapa.

Por que "Heroku auto-hospedado" virou uma categoria

A primeira coisa que precisa ser dita é que o Heroku resolveu o problema certo. Em 2010, deploy de aplicação web tinha duas formas: subir tarball pra um servidor que você administrava, ou pagar caro pra alguém administrar pra você. O Heroku inventou o terceiro caminho — git push heroku main, slider de escala, banco gerenciado embutido, certificado emitido automaticamente, sub-domínio funcional em segundos.

Esse padrão ficou. O conceito de "deploy é um push, escala é um slider, TLS é automático" virou a expectativa-base de qualquer desenvolvedor formado depois de 2012. Tudo que veio depois — Render, Railway, Fly.io, Vercel pra frontend, Cloud Run, App Runner — é variação em cima desse modelo.

Mas três coisas mudaram entre 2010 e 2022.

Cloud bare-metal ficou barato. Em 2010, um servidor virtual decente custava US$40/mês. Em 2026, US$5/mês compra um VPS com 1 vCPU, 2 GB de RAM, 50 GB de disco e 2 TB de tráfego — mais do que suficiente pra rodar cinco aplicações pequenas. A economia de fechar dynos pra rodar containers próprios se inverteu.

Docker virou padrão. A grande virtude do Heroku original eram os "buildpacks" — receitas que pegavam seu código Ruby ou Node e produziam um artefato isolado pronto pra rodar. Docker tornou esse encapsulamento commodity. Hoje qualquer um produz uma imagem reproduzível em três linhas de Dockerfile, e qualquer servidor com 100 MB de RAM livre pode hospedá-la.

A comunidade aprendeu a operar. Em 2010, "rodar um servidor Linux" era ofício de SRE. Em 2026, qualquer desenvolvedor full-stack já configurou nginx, lidou com certbot, montou systemd unit, debugou OOM-killer pelo dmesg. O nível médio subiu. Aquilo que justificava pagar US$25/mês pra Heroku cuidar virou um exercício de uma tarde.

Quando o gratuito morreu, montar "seu próprio Heroku" deixou de ser exercício de orgulho de hacker e virou conta de padaria. US$10/mês de VPS contra US$25/mês mínimo no Heroku-pago — e isso por aplicação. Cinco aplicações no Heroku custam US$125/mês. Cinco aplicações num VPS de US$10/mês continuam custando US$10/mês.

A categoria que respondeu a essa conta tem cinco subgêneros distintos hoje. Vale separar.

O segmento em 2026

Single-server simples — "instalo num VPS e esqueço"

O subgênero mais antigo e mais habitado. A premissa é direta: um único servidor, um instalador, um painel ou CLI, e você tem dynos. Sem cluster, sem alta disponibilidade, sem complicação.

Dokku é o vovô do segmento, ativo desde 2013. O motor é Bash mais Docker. UX é majoritariamente CLI — você empurra código via git remoto, ele constrói com buildpacks Heroku-compatíveis, sobe o container, registra no roteador interno. A comunidade é pequena mas leal, o produto é estável, e a curva de aprendizado é íngreme nos primeiros dias e plana depois disso. Quem passou desses primeiros dias raramente troca. Está fora de moda no sentido de que a comunidade nova prefere painéis web — mas o produto continua sólido, com mais de doze anos de operação real em produção em milhares de instalações pelo mundo.

Caprover ocupa o meio do espectro. Painel web, sistema de plugins, instalação razoavelmente fácil. O produto tem cerca de treze mil estrelas em repositórios públicos e uma comunidade ativa, ainda que menor que a dos concorrentes mais novos. A evolução é mais lenta — releases vêm em cadência mensal ou bimestral, e features grandes demoram. Pra quem prioriza estabilidade sobre novidades, é uma escolha defensável.

Coolify é o líder atual de mindshare. Por volta de quarenta mil estrelas, painel web moderno, ecossistema de plugins ativo, comunidade ruidosa em fóruns e em chat. O produto evoluiu rápido entre 2023 e 2025, agregando suporte a banco gerenciado embutido, deploy via git, certificados automáticos, monitoramento de containers. É a recomendação default que circula em fóruns de indie hackers hoje.

O defeito principal do Coolify, e a razão de ele aparecer também na seção sobre armadilhas mais abaixo, é arquitetural: foi desenhado single-server first. Multi-server foi adicionado depois, mas o painel central continua sendo um único processo num único servidor. Se esse servidor cai, você perde acesso a todos os outros.

Single-server moderno — "deploy sem painel"

Subgênero mais novo, com filosofia oposta à anterior. Em vez de painel web, ferramenta de linha de comando que opera por SSH.

Kamal é o representante quase exclusivo. Saiu do time da 37signals em 2024, escrito por gente próxima ao DHH. A premissa é radical: nenhum painel, nenhum control plane, nenhum agente residente nos servidores. Você escreve um arquivo de configuração, roda kamal deploy, ele faz SSH em cada servidor, faz pull da imagem, troca o container e segue. O DHH publicou em 2024 que economizou cerca de três milhões de dólares por ano migrando os apps próprios da Basecamp e do HEY do cloud pra hardware próprio com Kamal. Onde a tese do "sem orquestração" começa a doer está em HeroCtl vs Kamal.

A virtude é a transparência absoluta — não há nada acontecendo que você não veja no terminal. O defeito é que multi-server não é orquestração, é deploy paralelo. Não há eleição de líder, não há rebalanceamento, não há failover. Cada servidor é um destino independente. Se um cair, você notifica seu monitoramento e refaz o deploy excluindo aquele host.

Pra um time pequeno operando duas ou três aplicações em três a cinco servidores, com hábitos disciplinados de deploy, Kamal é elegante. Pra qualquer coisa que precise de "se um servidor cai, o cluster decide o que fazer sozinho", não é a ferramenta certa.

Cloud-native moderno — "Heroku reembrulhado"

Dokploy é o produto mais recente que entrou na conversa. Por volta de dez mil estrelas, em crescimento rápido, UX visualmente parecida com Coolify mas arquitetura subjacente sobre Docker Swarm. Atrativo principal: multi-server real "fora da caixa", sem precisar montar à mão. A leitura ponto a ponto da escolha técnica que o Dokploy fez está em HeroCtl vs Dokploy.

O defeito estrutural é a fundação. Docker Swarm está em modo de manutenção há anos — a Docker Inc. não investe em features novas desde 2019, e o roadmap público é essencialmente "manter funcionando". Construir produto novo em cima de tecnologia em manutenção é uma aposta. Se a Swarm for descontinuada formalmente, o Dokploy precisa migrar de fundação inteira ou reescrever — e o usuário paga essa conta no meio do caminho. O ecossistema de plugins ainda é menor que o do Coolify, mas vem subindo rápido.

Hospedado-mas-prefiro-self-hosted — "Vercel/Render mas no meu servidor"

Tecnicamente fora da categoria do título do post, mas vale mencionar porque muito time compara. Quem busca "alternativa ao Heroku" frequentemente acaba não no auto-hospedado, e sim em outro hospedado.

Render é o sucessor mais direto do Heroku no espírito. UX limpa, preços previsíveis, free tier generoso (mas não infinito — tem suspensão automática por inatividade). Banco Postgres e Redis gerenciados, deploy via git, build logs no painel. O preço sobe de forma linear com uso real, sem armadilhas grandes. É a escolha óbvia pra quem quer "Heroku que funciona em 2026" sem se preocupar com servidor.

Railway é hospedado, foco mais forte em devs solo, preço por uso de recursos (CPU/RAM/tráfego) em vez de tier fixo. Funciona bem pra hobby project que não vai escalar; pode ficar caro rápido se você esquecer um worker rodando.

Fly.io tem proposta diferente: hospedagem distribuída em múltiplas regiões, primitivas mais cruas, próxima de "VM como serviço com TLS automático" do que de "PaaS no estilo Heroku". É a escolha de quem quer baixa latência mundial sem montar isso à mão. A curva de aprendizado é maior que Render ou Railway.

Os três são opções legítimas. A nota importante é o que vem na seção de armadilhas: free tier de hospedado pisa mais a cada ano, e o caminho histórico do Heroku — começou gratuito, virou US$25/mês mínimo — é a previsão default pra qualquer plano gratuito de empresa privada.

Cluster real — "preciso de alta disponibilidade"

Categoria curta, com poucos produtos sérios. Aqui a premissa não é "rodar deploy em mais de um servidor", é "se um servidor cair, o cluster continua funcionando sozinho sem intervenção humana". A diferença é grande, e a maioria do segmento não atravessa essa linha.

HeroCtl é o produto que estamos construindo. Plano de controle replicado entre três ou mais servidores desde o primeiro dia. Eleição automática de coordenador em cerca de sete segundos quando o servidor que coordena cai. Roteador integrado, certificados automáticos, métricas e logs embutidos no próprio binário. Modelo comercial com Community gratuito permanente, Business e Enterprise pagos com preço publicado. Faixa ideal: de um a quinhentos servidores.

A diferença operacional importa quando o cliente entra. Enquanto o painel central de um Coolify multi-server é um ponto único de falha, em HeroCtl não há central — qualquer um dos três primeiros servidores pode coordenar, e a transição entre eles é automática.

Tabela comparativa

A coluna que separa o segmento em duas metades é "alta disponibilidade real". À esquerda dela, todos os produtos compartilham a mesma premissa: multi-server é destino de deploy, não cluster com consenso. À direita, o painel/control plane é replicado e sobrevive à perda de qualquer servidor.

Decisão por perfil de uso

Quatro perfis cobrem a maioria dos casos.

Solo dev, hobby project, um VPS. Dokku se você gosta de CLI e quer estabilidade. Coolify se você prefere painel web. Kamal se você está num stack Rails ou Node e já trabalha bem com SSH e arquivos de configuração. Qualquer um dos três resolve. A escolha é mais de gosto do que de capacidade técnica.

Indie hacker com um a três SaaS pequenos, ainda um servidor. Coolify ou Dokploy. A diferença prática é o ecossistema de plugins (Coolify tem mais) e a fundação técnica (Dokploy aposta em Swarm). Pros próximos doze meses, qualquer um dos dois funciona; a migração entre eles é factível porque ambos rodam containers Docker padrão. A decisão arquitetural importante é diferente: quando você passar de um servidor pra dois, vai sentir o ponto único de falha do painel — e essa é a hora de avaliar se a próxima migração é Dokploy multi-server ou um cluster de verdade.

Startup com primeiro cliente sério, SLA contratual entrando em vigor. HeroCtl. Aqui o painel single-server vira passivo legal — qualquer SLA escrito em contrato comercial assume que a infraestrutura sobrevive à perda de um nó, e nenhum painel single-server faz isso. Você pode tentar montar redundância manual em cima de Coolify ou Dokploy, mas o resultado vai ser frágil e custoso de operar. A regra simples é: na hora que o contrato com cliente menciona "uptime", o cluster com consenso deixa de ser luxo.

Empresa estabelecida, cinquenta servidores ou mais, time de plataforma com três pessoas dedicadas. Aqui a conversa muda. K8s gerenciado em provedor cloud passa a ser a opção sensata, porque o ecossistema de operadores é maior e o time tem competência pra absorver a complexidade. HeroCtl roda nessa faixa também — testamos centenas de nós em laboratório, dezenas em produção de clientes — mas acima de cem servidores o teto da nossa biblioteca de operadores especializados começa a aparecer.

As três armadilhas do segmento

"Multi-server" não significa "alta disponibilidade real"

A confusão mais cara. A maioria dos painéis lista "multi-server" como feature, e o leitor casual interpreta isso como "se um servidor cair, o sistema continua funcionando". Não é o que está sendo oferecido. Multi-server na maioria dos painéis significa: o painel central, rodando num servidor único, é capaz de fazer deploy em vários servidores remotos.

Quando o servidor do painel cai, você perde controle. Os containers em produção continuam rodando — Docker não para por causa disso — mas você não consegue mais fazer deploy, ler logs centralizados, reiniciar serviço, escalar. Fica esperando voltar.

Alta disponibilidade real exige consenso entre múltiplos servidores: pelo menos três processos do painel rodando, eleição automática de coordenador, replicação do estado entre eles. Se o coordenador cai, outro assume em segundos. Essa é uma arquitetura diferente, mais cara de construir e mais cara de operar. Por isso poucos produtos do segmento entregam.

A pergunta concreta pra fazer ao avaliar qualquer produto: "se o servidor onde roda o painel for desligado agora, em quanto tempo o sistema volta a aceitar deploys, e essa volta é automática ou manual?". Se a resposta envolve um humano abrindo SSH em algum lugar, não é alta disponibilidade.

"Plugin ecosystem" pode ser dependência disfarçada

Os painéis com loja de plugins parecem completos: você instala um plugin pra ter Postgres gerenciado, outro pra Redis, outro pra Sentry-like, outro pra backup automático, outro pra monitoramento. Cada um resolve um pedaço, e o conjunto soma um Heroku.

O problema aparece dois anos depois. O plugin de backup foi escrito por um voluntário em 2024 e parou de receber commits em 2025. A versão nova do painel quebrou compatibilidade com ele e ninguém atualizou. Você descobre na hora que precisa restaurar um backup — e a restauração nunca foi testada com a versão atual.

Esse padrão se repete pra cada plugin. Quanto mais funcionalidades dependem do ecossistema externo, maior a superfície de risco. A defesa estrutural é simples: dê preferência a produtos com bateria incluída — onde Postgres, métricas, logs, certificados, roteamento são parte do produto principal e mantidos pelo mesmo time que mantém o resto. Plugin é cômodo no curto prazo e custoso no médio.

"Free tier" do hospedado não é gratuito longo prazo

Render, Railway, Fly.io têm planos gratuitos generosos hoje. O Heroku tinha em 2021. A história do segmento mostra um padrão consistente: free tiers de empresas privadas pisam mais a cada rodada de levantamento de capital. Primeiro suspende por inatividade, depois reduz cota, depois adiciona limite de horas, depois transforma em trial de trinta dias, depois encerra.

Não é maldade — é matemática de negócio. Hospedar workload custa dinheiro, e o investidor cobra retorno. A única exceção estrutural é hospedagem subsidiada por outro produto da mesma empresa (cloud cobrindo PaaS gratuita pra atrair desenvolvedores ao cloud principal), e mesmo essas mudam quando muda o CFO.

Auto-hospedado é a única defesa estrutural. Você paga a conta do VPS direto pro provedor de infraestrutura, sem intermediário. Quando o intermediário some, sua aplicação não some junto.

Quando ficar no Heroku, Render ou Railway sem ironia

Vale dizer com clareza: nem todo time precisa sair de hospedagem gerenciada. Há três situações em que ficar é a decisão correta.

Time pequeno sem competência operacional disponível pra cuidar de servidor. Se a equipe inteira é dois desenvolvedores de produto, nenhum com experiência prévia em Linux/Docker/networking, o custo cognitivo de operar infraestrutura é maior do que a economia mensal. Pague os US$200/mês de Render e mantenha foco em produto.

Aplicação cujo custo de plataforma é desprezível comparado ao revenue. Se a empresa fatura US$50k/mês e a conta do Heroku é US$300, otimizar essa conta é trabalho mal alocado. O retorno marginal de migrar é baixo, e o risco operacional não compensa.

Equipe alocada em produto, não em infra. Algumas startups são tão dependentes de iteração rápida em produto que qualquer hora gasta em infra é hora roubada do diferencial competitivo. Pra essas, o trade-off de pagar a mais pra não pensar em servidor é valor real, não desperdício.

A regra simples: se a infra é commodity invisível pro seu negócio, deixe alguém cobrar pra ser invisível pra você. Se a infra é capacidade que diferencia o produto (latência baixa, regiões específicas, compliance específico, uptime contratual), o controle compensa o trabalho.

HeroCtl no segmento

Posicionamento honesto: HeroCtl não compete com Dokku ou Coolify no caso de hobby project em um VPS. Pra esse caso, é mais máquina do que precisa. Um indie hacker com uma aplicação Django num servidor de US$5/mês deve usar Dokku ou Coolify e seguir o dia.

Onde HeroCtl compete é onde Coolify multi-server, Dokploy e Nomad também competem: o caso de cliente sério com SLA, em que single-server vira passivo legal. Aqui a diferença que oferecemos é cluster com consenso desde o primeiro dia, bateria incluída em vez de cinco produtos pra montar (roteador, certificados, métricas, logs e criptografia entre serviços já no binário), e contrato comercial publicado e congelado — sem mudança retroativa de termos.

O cluster de demonstração roda quatro servidores totalizando cinco vCPUs e dez gigabytes de RAM, com dezesseis containers ativos servindo cinco sites. O plano de controle ocupa entre 200 e 400 MB por servidor. Comparativamente, o plano de controle de uma versão gerenciada do orquestrador grande começa em cerca de 700 MB por nó-mestre antes de qualquer aplicação subir.

O job spec típico tem cerca de cinquenta linhas — descreve serviço, ingress, secrets, recursos. O equivalente no orquestrador grande passa de trezentas linhas pra cobrir a mesma funcionalidade.

HeroCtl não compete com cloud gerenciado em escala de cem nós ou mais. A faixa ideal é um a quinhentos servidores. Acima disso, o ecossistema externo de operadores especializados ainda dá vantagem ao orquestrador grande, e ser honesto sobre isso é parte do contrato.

Perguntas que recebemos

Posso migrar do Heroku direto pro HeroCtl? Sim, com algumas adaptações. Aplicação web stateless com Postgres separado migra fácil — você containeriza com Dockerfile, descreve o job em cinquenta linhas, sobe. Workers separados (Sidekiq, Celery) viram jobs adicionais no mesmo cluster. O que precisa ser repensado é o que dependia de add-ons gerenciados.

E os add-ons (Postgres, Redis, Sentry)? Postgres você roda como job no próprio cluster, com volume persistente, e cuida de backup como humano cuida — não há operador automático que faça isso melhor do que você fazendo direito. Redis idem. Sentry self-hosted existe e roda em qualquer cluster Docker — e há produto comercial hospedado se preferir não operar. A regra geral: dados críticos rodam no cluster, observabilidade pode rodar fora.

Quanto custa em comparação? Tomando como base uma startup com cinco aplicações pequenas: Heroku-pago sai em torno de US$125/mês mínimo, sem add-ons. Render sai entre US$50 e US$150 dependendo do uso. Cluster próprio em VPS de três nós sai US$30 a US$60/mês total no provedor de infraestrutura. A economia direta é real, e fica mais expressiva conforme as aplicações crescem.

E se eu já estou no Coolify? Não há urgência de migrar enquanto você opera com um único servidor. A hora de considerar é quando o painel single-server vira ponto único de falha contratual — primeiro cliente sério com SLA escrito. Até lá, Coolify funciona bem.

E pra um app Django com Celery, ou Rails com Sidekiq? Funciona naturalmente. Você define um job pro processo web e outro job pro processo de worker, ambos compartilhando a mesma imagem mas com comandos diferentes. O cluster orquestra os dois independentemente, e o broker (Redis ou similar) é mais um job no mesmo cluster.

E pra um app Node.js com workers separados? Mesma história. Worker é só outro processo, definido como outro job. Não há distinção arquitetural entre "web" e "worker" no nível do orquestrador — são containers que rodam código.

Os preços do Business saem quando? A página de planos publica os valores. A linha de corte é desenhada pra que você só pague Business quando a empresa for grande o suficiente pra que SSO, RBAC granular e auditoria detalhada sejam exigências reais — não preferência. Pra todo o resto, Community resolve, e Community é gratuito permanente sem feature gate artificial.

Fechamento

O segmento de "Heroku auto-hospedado" amadureceu. Em 2026, há produtos sérios pra cada perfil de uso, e a decisão depende menos de "qual é o melhor" e mais de "qual cabe no meu caso". Hobby project não precisa de cluster com consenso. Cliente sério com SLA não cabe em painel single-server.

Pra quem está decidindo agora, três recomendações finais. Primeiro, leia o contrato comercial antes de adotar — fuja de termos que permitam mudança retroativa. Segundo, prefira bateria incluída a ecossistemas de plugins onde possível — superfície de risco menor. Terceiro, teste o caminho de falha antes do incidente real — desligue um servidor e veja o que acontece, com calma, durante o dia.

Pra começar com HeroCtl em três servidores Linux:

curl -sSL get.heroctl.com/install.sh | sh

Se quiser ler mais antes, há dois posts adjacentes: HeroCtl vs Coolify explica a comparação direta com o líder de mindshare do segmento single-server, e Por que criamos o HeroCtl explica o raciocínio que levou à existência do produto.

Orquestração de containers, sem cerimônia.