A linha do tempo do PaaS self-hosted, e de onde a ideia realmente veio

Toda “alternativa ao Heroku” parece uma ideia nova até você olhar a linha do tempo real — a categoria vem sendo reconstruída por uma equipe nova a cada poucos anos desde o próprio Heroku, e o que continua mudando não é a promessa central (git push, tenha um app rodando), é quem é dono da infraestrutura por baixo dela.

A era do tudo-gerenciado

O Heroku (2007) definiu o formato que todo mundo ainda copia: buildpacks, dynos, add-ons, um git push que se torna um deploy. Comprado pela Salesforce em 2010, e por quase uma década “PaaS” basicamente significava “Heroku, ou algo tentando ser Heroku.” A troca sempre foi a mesma: facilidade extraordinária, numa infraestrutura que você nunca toca e nunca é dono.

O Fly.io (2017) e o Render (2018) mantiveram esse mesmo modelo de tudo-gerenciado, mas atacaram partes diferentes dele — o Fly se construiu em torno de rodar VMs perto dos usuários globalmente em vez de uma única região; o Render foi atrás da dor específica de equipes perdendo tempo de engenharia real com encanamento de infraestrutura em vez de trabalho de produto. Nenhum dos dois mudou quem é dono do servidor. O Railway (fundado em 9 de junho de 2020, por Jake Cooper) empurrou o mesmo modelo para uma energia de ativação quase zero — a menor distância possível entre “eu tenho código” e “está rodando.”

O outro ramo: nunca hospedar o app do cliente

A Cloud 66, fundada em 2012, fez uma aposta completamente diferente, anos antes de ser tendência: um plano de controle sobre servidores que o cliente já possui, em vez de uma plataforma que é dona dos servidores em si. Esse é o ponto de origem real do modelo que o Railyard segue — não uma ideia recente, uma de 2012 que levou muito tempo para se tornar obviamente correta conforme as contas de nuvem cresceram e o aprisionamento a fornecedor ficou caro demais para ignorar.

A Coolify retomou esse mesmo fio de BYO-server pelo lado open-source — lançada por primeira vez em 24 de março de 2021, e na primavera de 2026 já passando de 50.000 estrelas no GitHub, supostamente o PaaS self-hosted mais reconhecido até hoje. Gratuito, self-hosted, operado inteiramente por você, incluindo o próprio plano de controle.

Onde isso deixa a escolha real

O eixo real não é “qual plataforma tem mais recursos” — toda plataforma dessa lista converge eventualmente para buildpacks, bancos de dados gerenciados e deploys sem downtime. O eixo que ficou estável por mais de uma década é quem é dono da máquina: do Heroku ao Railway, eles alugam para você a stack inteira; da Cloud 66 ao Railyard e à Coolify, eles te dão um workflow em cima de uma infraestrutura que é sua. Dentro desse segundo grupo, a próxima pergunta é igualmente antiga — plano de controle hospedado que você não opera (Cloud 66, Railyard) versus plano de controle self-hosted que você também roda sozinho (Coolify). Nenhum dos dois é estritamente melhor; são respostas diferentes para quanta infraestrutura você pessoalmente quer operar, e essa já é a decisão real desde 2012, não uma nova.

Por que a categoria continua sendo reconstruída em vez de se consolidar

Ninguém venceu isso de forma definitiva porque a troca nunca se resolve numa única direção — a cada poucos anos, uma equipe nova decide que o líder atual se afastou demais em direção à complexidade, ou ao preço, ou ao aprisionamento, e constrói uma versão mais simples da mesma ideia central. Isso não é um sinal de que o problema está sem solução; é um sinal de que a resposta real é “depende de quanta infraestrutura você quer ser dono”, que não tem uma única resposta correta que torne o resto da categoria obsoleto.

Veja como o Railyard especificamente se compara: Heroku, Railway, Render, Fly, Cloud 66.