Render vs Railway vs Fly.io: comparativo brasileiro 2026

Em agosto de 2022 a Salesforce anunciou o fim do plano gratuito do Heroku. A decisão foi escrita em duas linhas num post de blog corporativo, virou meme em três horas, e em três meses estava reescrevendo o mapa de PaaS hospedado pra todo dev indie do mundo. Brasileiro pegou o golpe duas vezes: perdeu o tier grátis e ainda viu o dólar subir de R$5,20 pra R$5,90 no mesmo período.

Três produtos pegaram a maior parte da herança: Render, Railway e Fly.io. Cada um aposta numa filosofia diferente — preço fixo previsível, pay-as-you-go com UI bonita, ou edge multi-região com primitivas de baixo nível. Pra dev brasileiro, a escolha mistura DX, custo em USD que vira reais, latência pra São Paulo, e o teto de escala antes do projeto começar a doer no bolso.

Esse artigo é o mapa honesto. Sem ranking de "melhor", porque não existe — existe o melhor pra cada estágio. E no fim da linha, quando os três ficam caros, existe o caminho do auto-hospedado, que é onde o HeroCtl entra. Mas vamos por partes.

A herança do Heroku

Pra entender o que cada um copiou e o que cada um descartou, vale lembrar o que o Heroku fez bem nos seus dez anos de glória.

A primeira coisa foi git push heroku main. Aquele comando virou o padrão mental de deploy pra uma geração inteira de devs. Não tinha pipeline a configurar, não tinha registro de imagem a popular, não tinha arquivo de orquestração a escrever. Você empurrava código pro repositório remoto e a plataforma cuidava do resto — buildpack detectava a linguagem, instalava dependências, subia o processo. Render e Railway herdaram isso quase intacto. Fly.io trocou por fly deploy, que tem a mesma cara mas trabalha com imagem de contêiner explícita.

A segunda coisa foi a noção de "dyno" como unidade de cobrança e escala. Você não pensava em servidor, vCPU ou RAM — pensava em quantos processos web e quantos workers. Render manteve essa simplificação no plano Starter. Railway abandonou e cobra pelo recurso real consumido. Fly.io trocou dyno por VM com tamanho declarado.

A terceira coisa foi o marketplace de addons: Postgres, Redis, MongoDB, e-mail transacional, tudo a um clique. Esse é o pedaço onde os três sucessores divergem mais. Render tem alguns addons gerenciados nativos. Railway tem um marketplace de templates que cobre o básico. Fly.io te empurra pra rodar seu próprio Postgres num app dedicado, com toda a responsabilidade que isso traz.

E a quarta coisa, a dolorosa, foi o vendor lock-in disfarçado de simplicidade. Quem tinha cinquenta serviços no Heroku descobriu em 2022 que migrar custaria meses. Os três sucessores prometem ser melhores nesse quesito; veremos.

Render: o "Heroku 2.0 previsível"

Render é o sucessor mais conservador. A premissa é simples: você descreve o serviço num arquivo render.yaml ou pelo painel, conecta o repositório, e cada push em main dispara um deploy. Build, certificado TLS, domínio customizado, tudo automático.

Filosofia. Preços fixos por instância. A instância Starter mais barata custa US$7/mês — e custa US$7/mês independente de você fazer cinco requests por dia ou cinquenta mil. Existe um plano free, mas com asterisco grande: o serviço dorme depois de quinze minutos sem tráfego e leva uns trinta segundos pra acordar no primeiro request. É exatamente o mesmo trade-off do Heroku free de 2015. Funciona pra portfolio, não funciona pra produto sério.

Pontos fortes. A previsibilidade do orçamento é o grande chamariz pra time pequeno. Você sabe que três serviços Starter vão custar US$21/mês, ponto. Não tem surpresa de fim de mês porque um cron rodou em loop. Postgres e Redis gerenciados existem como produtos próprios, com backup automático e versão recente. O painel é limpo, foca em fazer poucas coisas bem. Latência pra São Paulo a partir do datacenter de Ohio fica em torno de 120ms — não é ideal, mas é viável pra app web típico onde o gargalo costuma ser query de banco.

Pontos fracos. O free tier dormindo é triste pra qualquer coisa que não seja vitrine pessoal. Escalar custa caro porque é linear: quatro instâncias Starter custam quatro vezes US$7. Não há multi-region nativo no plano básico — você fica preso à região que escolheu. CDN e edge computing são limitados; quem precisa de cache geográfico pesado vai sofrer. E o Postgres gerenciado começa em US$7/mês, então o piso real de um app com banco é US$14/mês, o que pra MVP em estágio zero de receita já incomoda.

Custo em real. App simples sem banco: US$7/mês = R$36 a R$40 dependendo do câmbio. Com Postgres mínimo: US$14/mês = R$72 a R$80. Versão de produção com duas instâncias web e Postgres Standard (US$20/mês): US$34/mês = R$170 a R$190. Some domínio, e-mail transacional, monitoring e você está em R$300/mês fácil pra um SaaS pequeno. Não é caro pelo padrão americano. É caro pelo padrão brasileiro de quem tira o salário do próprio MRR.

Quando faz sentido. Indie hacker que já está no Heroku e quer migrar com o mínimo de fricção mental. Time de uma a três pessoas que valoriza orçamento previsível mais do que custo mínimo absoluto. App web tradicional sem requisitos de baixa latência geográfica. Projeto onde você prefere pagar US$30/mês e não pensar mais a pagar US$10/mês com possibilidade de explodir pra US$80 num mês ruim.

Railway: o "pay-as-you-go com UX premium"

Railway é o sucessor que ousou inverter o modelo de cobrança. Em vez de instância fixa, você paga pelo recurso real consumido — vCPU, RAM, network egress, storage. A premissa é que apps pequenos e jobs intermitentes ficam mais baratos no pay-as-you-go do que no instance-based.

Filosofia. Cobrança granular por uso real. Você não escolhe tamanho de máquina, você escolhe o app e o Railway decide quanto recurso entregar conforme a demanda, dentro de um teto. UI excelente — provavelmente a mais bonita do segmento PaaS hospedado. Templates one-click cobrem dezenas de combinações: Postgres, Redis, MongoDB, MeiliSearch, n8n, Strapi.

Pontos fortes. A UX vence no primeiro contato. Em quinze minutos você tem um app rodando com banco, Redis e dashboard de logs em tempo real. O marketplace de templates é amigável pra quem não quer escrever Dockerfile. Pra apps low-traffic o pay-as-you-go pode sair bem mais barato que instância fixa do Render — um cron que roda dez segundos por dia paga só esses dez segundos, não vinte e quatro horas.

Pontos fracos. Custo imprevisível é o calcanhar. O Railway tem teto suave de gasto, mas não rígido por padrão — um job em loop infinito pode queimar US$50 num fim de semana antes de você perceber. O pricing tem letras miúdas: o plano Hobby (US$5/mês) inclui US$5 de uso, então tecnicamente você começa do zero todo mês, mas a conta pode passar disso fácil. O plano gratuito original foi removido em 2023 — outra repetição do padrão Heroku. Datacenter é US-only, latência pra SP fica nos mesmos 120ms do Render. E houve histórico de mudanças de pricing que pegaram usuários de surpresa, tipo a remoção do trial mais generoso em meados de 2023.

Custo em real. Hobby plan: US$5/mês fixo = R$25 a R$28. Mas o uso real costuma puxar a conta pra US$10-20/mês num app com banco e workers leves = R$50 a R$110. Em mês ruim, com pico de tráfego, é fácil ver a conta encostar em US$30-40 = R$150 a R$220. O segundo desvio padrão é o que assusta.

Quando faz sentido. Time pequeno em fase de experimentação, lançando dezenas de testes por semana, onde a maioria nunca pega tráfego e seria desperdício pagar instância fixa. Apps low-traffic genuinamente pequenos onde pay-per-use sai mais barato no longo prazo. Devs que valorizam UI bonita e fluxo de deploy sem fricção acima de previsibilidade rígida de orçamento. Projetos pessoais que rodam em rajada.

Fly.io: o "edge multi-region pra workloads sérios"

Fly.io é o mais técnico dos três. A premissa é diferente desde a base: seu app não roda numa região, ele roda em várias. Quando um usuário no Brasil acessa, o request bate na região mais próxima — e Fly.io tem ponto em São Paulo, o GRU. Pra latência percebida pelo usuário brasileiro, isso é a coisa mais importante do mercado de PaaS hoje.

Filosofia. Aplicação global por padrão. VMs reais (não contêineres compartilhados) em cima do Firecracker. Primitivas de baixo nível — você lida com fly.toml, com volumes persistentes regionais, com rede privada entre apps via WireGuard, com IPs anycast. Mais poder, mais responsabilidade.

Pontos fortes. O datacenter GRU é vantagem real e mensurável: latência pra usuário em São Paulo cai de 120ms (Render/Railway via US) pra 30-60ms. Pra app interativo, isso é a diferença entre "rápido" e "instantâneo". Multi-region é nativo — você roda o mesmo binário em três continentes, e o roteamento bate na região mais perto do usuário. Volumes persistentes regionais permitem patterns como Postgres com Litestream replicando pra storage de objeto. O pricing começa muito barato: US$1.94/mês pela menor VM (shared-cpu-1x, 256MB), mais frações de centavo por GB transferido.

Pontos fracos. Curva de aprendizado real. flyctl, fly.toml, conceitos de Machines vs Apps, redes WireGuard — tudo isso você tem que digerir. Não é "abre painel e clica deploy", é "leia a doc por uma tarde". Pricing variável tipo Railway, com a mesma armadilha: app que cresce de repente pode triplicar o custo num mês. A comunidade é menor que Render/Railway, especialmente em PT-BR — encontrar tutorial brasileiro recente é tarefa. E houve incidentes de estabilidade reportados publicamente em 2023-2024 que afetaram confiança da base; melhoraram, mas a memória ainda pesa.

Custo em real. App pequeno com VM mínima e storage modesto: US$2-6/mês = R$10 a R$32. Postgres rodado como app dedicado (você é responsável pelo backup): mais US$2-10/mês = R$10 a R$50. App produção sério com duas regiões e bandwidth real: US$15-40/mês = R$80 a R$220. A faixa baixa é imbatível pra projeto pessoal; a faixa alta começa a competir com auto-hospedado em VPS dedicada.

Quando faz sentido. B2B SaaS com clientes distribuídos em múltiplas regiões — app que precisa estar em US-East e em GRU simultaneamente sem você operar dois clusters. App onde latência pra usuário brasileiro é diferencial competitivo. Time confortável com primitivas tipo VM, rede mesh, storage block regional — tipicamente devs que têm background em DevOps ou que migraram de bare-metal. Projeto pessoal de hobby onde os US$2/mês pagam cinco apps de uma vez.

Tabela comparativa

A tabela esconde nuance que vale explicitar: nenhum dos três é "melhor" em tudo. Render ganha em previsibilidade. Railway ganha em UX. Fly.io ganha em performance pra usuário brasileiro. A escolha é função do que você está otimizando.

O que os três têm em comum (e onde o HeroCtl entra)

Quatro pontos os três compartilham, e cada um deles é um motivo pra eventualmente sair.

Primeiro: cobrança em USD. Nenhum dos três fatura em real. Câmbio sobe, sua conta sobe junto, e você descobre em fevereiro que a infra que custava R$300 em janeiro custa R$340 sem nenhuma mudança técnica. Pra time bootstrapped sem proteção cambial, isso é exposição que ninguém pediu pra ter.

Segundo: você não controla o servidor. Você não escolhe o kernel, não tem acesso SSH, não roda processo em background fora do que a plataforma permite. Pra noventa por cento dos casos isso é vantagem. Pros dez por cento restantes — quando você precisa de fine-tuning, de daemon customizado, de alguma capability específica do sistema operacional — você está limitado.

Terceiro: free tiers minguando ano após ano. Heroku matou o free em 2022. Railway removeu o trial generoso em 2023. Render mantém free com sleep mas tem reduzido limites. O padrão é claro: o free tier serve pra adquirir dev em estágio zero de receita; quando o produto cresce, a empresa precisa monetizar e o free encolhe. Não é traição, é economia. Mas implica que sua estratégia de longo prazo não pode depender do free continuar como está.

Quarto e mais importante: quando a startup cresce, o custo escala desproporcionalmente. App pequeno US$15/mês é desprezível. App real com cinco serviços, dois bancos, Redis, e dois ambientes (staging + prod) começa em US$80-150/mês — entre R$450 e R$850. Some workers, jobs em background, monitoring, e você passa de US$200/mês fácil. É nesse ponto que o auto-hospedado deixa de ser hobby de DevOps e vira economia clara.

A faixa típica onde o trade-off vira: quando seu PaaS hospedado passa de US$50/mês de gastos consistentes, três VPS Hetzner de US$5 cada (~R$80 total) rodando uma plataforma de orquestração começam a fazer sentido financeiro. Você troca conveniência por economia, e ganha controle do servidor de quebra. O HeroCtl é desenhado pra essa faixa: instalação simples, alta disponibilidade real entre múltiplos servidores, certificados automáticos, painel web. Sem cerimônia operacional, sem time de SRE.

Decisão por estágio do projeto

A pergunta certa não é "qual é o melhor PaaS", é "qual é o melhor pro estágio onde estou agora".

Estágio hobby, zero receita. Render free tier (com sleep), ou Fly.io aproveitando a faixa mínima (US$2-3/mês cobre projeto pessoal), ou um VPS de US$5 mensais com Coolify rodando solo se você curte mexer. Railway perdeu posto aqui depois de remover o tier grátis original.

Estágio indie hacker, até US$5k MRR. Render se você prioriza orçamento previsível e o app tem perfil "instância roda 24/7 com tráfego constante". Railway se você está experimentando muito, quer UI bonita, e o pay-as-you-go vai te favorecer. Custo nessa faixa fica em US$15-50/mês, gerenciável.

Estágio startup early, US$5k a US$50k MRR. Hora de avaliar com seriedade. Se latência pra usuário brasileiro importa (B2C, app interativo), Fly.io vira candidato forte por causa do GRU. Se o time já tem um dev confortável com infra básica, auto-hospedado simples (Coolify num servidor, ou HeroCtl em três pra alta disponibilidade) começa a pagar. A conta nessa faixa em PaaS hospedado roda em US$80-300/mês — em auto-hospedado, R$150-400/mês com mais headroom.

Estágio startup com primeiro cliente B2B sério, SLA exigido. Aqui o PaaS hospedado começa a quebrar de outras maneiras: você precisa de SLA contratual, de redundância em múltiplos servidores, de janela de manutenção previsível, de logs de auditoria. Render e Railway não oferecem SLA forte no plano padrão. Fly.io oferece, mas a multi-region implica complexidade operacional que a equipe vai ter que aprender de qualquer jeito. Esse é o ponto onde o HeroCtl com cluster de três servidores entra como alternativa: alta disponibilidade real, painel administrativo, auditoria, sem o mensalidade de US$300+ do PaaS hospedado pra mesmo nível de robustez. A outra opção é o caminho oposto: AWS gerenciado se algum cliente puxa requisitos de compliance específicos.

Quando NÃO sair de Render, Railway ou Fly.io

Migração custa caro, e na maior parte dos casos é otimização prematura. Quatro situações claras pra ficar onde você está.

Time de uma ou duas pessoas sem nenhum tempo pra coisa operacional. Se você é fundador solo no produto e cada hora gasta em infra é uma hora não gasta em vendas, manter o PaaS é decisão correta. R$200/mês de hospedado é mais barato que dezessete horas suas no mês mexendo em servidor.

Custo de plataforma é desprezível comparado à receita. Regra simples: se a infra é menos de dois por cento do MRR, não otimize. SaaS de US$50k MRR gastando US$500/mês de hospedado está pagando um por cento de infra. É excelente. Mexer ali é micromizar pra economizar moedas.

Você usa addon proprietário sem substituto fácil. Se você depende de algum addon específico de Railway que não tem equivalente óbvio fora — algum template customizado com integração proprietária, alguma feature única — a migração não é só re-deploy, é re-arquitetura. Avalie o custo total antes.

Migração levaria mais de duas semanas e a empresa não pode parar pra isso. Há momentos em que o produto está em hiper-crescimento, ou em ciclo crítico de funding, ou simplesmente em sprint de feature que importa pro cliente. Não migre infra nessas janelas. Anote a dívida técnica e volte depois.

FAQ

Posso usar Render pra produção e Railway pra staging? Pode, e tem gente que faz. A justificativa é simples: produção exige previsibilidade (Render brilha aí), staging tem tráfego rajado e idealmente deveria custar pouco quando ninguém está usando (Railway pay-as-you-go vence). O custo de manter dois fornecedores é o overhead mental de duas dashboards e dois conjuntos de credenciais. Faz sentido pra time disciplinado, atrapalha pra time pequeno que prefere monocultura.

Fly.io GRU region é confiável? Hoje sim, com asterisco. Funciona bem desde 2023, latência mensurada pra SP/RJ é o que promete (30-60ms tipicamente). O asterisco é que GRU é uma região menor no portfólio do Fly, então capacidade pode ficar apertada em picos e features novas costumam chegar em US-East primeiro. Pra produção séria, vale rodar em pelo menos duas regiões (GRU + uma US) com failover.

Como migro de Render pra HeroCtl sem downtime? Roteiro pragmático: provisione três VPS, instale o HeroCtl, suba a aplicação em paralelo apontando pra um domínio temporário. Replique o banco com pg_dump + carga inicial, depois mantenha em sincronia com replicação lógica até o switchover. Quando estiver pronto, troque o DNS do domínio principal pro novo cluster com TTL baixo. A janela de risco fica em torno do TTL do DNS — tipicamente cinco a dez minutos. Bancos pequenos (até alguns GB) migram numa tarde; bancos grandes pedem janela coordenada.

Postgres gerenciado nesses três é bom? Render Postgres é decente, com backup automático e versão atualizada — equivalente ao Heroku Postgres clássico. Railway Postgres via template funciona, mas o backup é mais manual e a configuração default é conservadora. Fly.io não tem Postgres gerenciado próprio; você roda como app, o que dá controle e responsabilidade. Pra time que não quer cuidar de banco, Render leva nesse quesito. Pra time que prefere controle, Fly.io.

Qual desses tem suporte em português? Nenhum oficialmente. Documentação é toda em inglês, suporte por chat/e-mail é em inglês. Há comunidades não-oficiais em PT-BR no Discord e no Twitter pra cada um, mas a maioria dos tickets sérios você abre em inglês. Pra time desconfortável com isso, é variável que pesa.

E performance pra app Rails / Django / Node? Pros três frameworks os três PaaS funcionam bem. Render tem buildpack Rails maduro e roda Sidekiq fácil. Railway detecta Django e Node automaticamente via templates. Fly.io tem documentação específica pra Rails e pra Phoenix, com deploy guides oficiais. A diferença prática aparece em detalhes: Rails com asset pipeline pesado fica mais rápido em Render por causa do build cache previsível; Node com workers em background ganha no Railway pelo pay-as-you-go; qualquer framework ganha em Fly.io se o usuário está no Brasil por causa do GRU.

Preview deploys por PR funcionam nos três? Sim nos três, com nuances. Render tem o melhor: cada PR vira uma URL temporária automaticamente, sem configuração extra. Railway oferece via integração com o repositório, configuração simples. Fly.io faz via CLI (fly deploy --config preview.toml) e exige um pouco mais de setup manual ou um workflow de CI customizado. Pra time que prioriza preview deploys como parte do code review, Render é o mais fluido.

Fechamento

A escolha entre Render, Railway e Fly.io não tem resposta universal. Render é o conservador previsível. Railway é o experimentador com UI bonita. Fly.io é o técnico com vantagem real de latência pro Brasil. Os três são honestos sobre o que são, e os três têm o mesmo destino estrutural: a partir de certo ponto de crescimento, o custo em USD escala mais rápido que sua receita em real, e o auto-hospedado começa a fazer sentido.

Quando esse ponto chegar, considere o HeroCtl. Três servidores Linux, alta disponibilidade real entre eles, certificados automáticos, painel web embutido, sem cerimônia operacional. Plano Community gratuito pra sempre, planos Business e Enterprise pra quando o time precisar de SSO, auditoria e suporte com SLA. Sem mudança retroativa de contrato.

Pra começar:

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

Se quiser ler antes, dois posts complementares: Heroku auto-hospedado em 2026 cobre a tese geral de quando largar o PaaS hospedado, e Alternativas brasileiras ao Kubernetes entra no mérito de qual orquestrador faz sentido pra time pequeno fora dos três PaaS deste artigo.

A escolha boa é a que cabe no seu estágio agora, não a que parece sofisticada. Comece simples, migre quando o custo justificar, e nunca antes.