Publicado em
Que alternativas brasileiras existem para sair do Railway, Heroku ou Vercel?
Existem três tipos, e a escolha depende de quanto da operação você quer assumir. Para manter o deploy por push, o HTTPS automático e o banco gerenciado, sem administrar servidor, há PaaS brasileiras como a Zenifra. Para ter mais controle, há nuvens nacionais como a Magalu Cloud e VPS em provedores brasileiros, onde você monta o ambiente. Todas rodam no país e cobram em real. Abaixo estão a comparação, os custos e o passo a passo para migrar um app Docker.
Por que times brasileiros procuram sair
Railway, Heroku e Vercel são boas plataformas, e quase ninguém sai delas por causa da experiência de deploy. Os motivos costumam ser outros quatro, e eles aparecem juntos quando os usuários estão no Brasil.
O primeiro é a distância. Heroku, Render e Railway não têm região na América do Sul, e a Vercel roda as funções em Washington por padrão. Em 30/10/2026, medimos a partir de uma conexão de fibra na região de São Paulo o tempo de ida e volta até servidores em quatro regiões.
| Região do servidor | Ida e volta medida |
|---|---|
| São Paulo, Brasil | 11 ms |
| Virgínia, EUA | 130 ms |
| Frankfurt, Alemanha | 155 ms |
| Califórnia, EUA | 181 ms |
O segundo é a fatura em dólar, só no cartão, com 3,5% de IOF e o câmbio do dia. O terceiro é o suporte em inglês, em outro fuso horário. O quarto aparece no começo do projeto: os planos de entrada que hibernam sem tráfego e o fim do plano grátis do Heroku, em 2022.
As alternativas brasileiras, por tipo
Uma PaaS brasileira é o substituto mais direto. Você conecta o repositório do GitHub ou aponta uma imagem Docker, e a plataforma faz o build, publica com HTTPS, mostra os logs e escala. O fluxo de trabalho fica parecido com o que você já tem, e o banco gerenciado roda na mesma região. Na Zenifra, por exemplo, aplicação, PostgreSQL, Valkey e IA por API ficam no mesmo console, com infraestrutura em São Paulo.
Uma nuvem nacional, como a Magalu Cloud, oferece máquinas virtuais, Kubernetes, armazenamento e banco gerenciado com MySQL e PostgreSQL, com preços em real. É uma boa opção para quem já opera Kubernetes ou quer montar o próprio ambiente, mas o deploy a partir do GitHub e o HTTPS por aplicação ficam por sua conta.
Um VPS em um provedor nacional é o mais barato e o mais trabalhoso. Ferramentas de código aberto como Coolify e Dokku recriam parte da experiência de uma PaaS em cima do VPS, mas atualizações de segurança, backup do banco e o que fazer quando o servidor cai continuam sendo responsabilidade sua.
Por fim, AWS, Google Cloud e Azure têm regiões em São Paulo. Não são alternativas brasileiras, mas resolvem a latência. Em troca, você monta rede, balanceador, banco e escala, e precisa conferir em que moeda o contrato é faturado.
| Critério | PaaS brasileira | Nuvem nacional | VPS nacional | Nuvem global em São Paulo |
|---|---|---|---|---|
| Deploy a cada push no GitHub | Pronto | Você monta | Você monta | Você monta |
| HTTPS e domínio | Automático | Você configura | Você configura | Você configura |
| Banco gerenciado | Sim | Sim | Não | Sim |
| Atualizações de segurança do servidor | A plataforma | Você, nas máquinas virtuais | Você | Você, nas máquinas virtuais |
| Moeda | Real | Real | Real | Depende do contrato |
O que muda ao sair de cada plataforma
Do Railway, a migração costuma ser a mais simples. Cada serviço vira um projeto, as variáveis de ambiente são copiadas e o PostgreSQL sai com um pg_dump usando a URL pública do banco. Se você usa MySQL ou MongoDB por templates, confira antes se o destino oferece o mesmo banco. A Zenifra, por exemplo, tem PostgreSQL, MariaDB, ClickHouse e Valkey, mas não MongoDB.
Do Heroku, olhe o Procfile. O comando da linha web vira o comando de start do projeto, e a aplicação precisa escutar na porta configurada. As Config Vars saem com heroku config, e o banco com heroku pg:backups:capture seguido de heroku pg:backups:download. Add-ons de terceiros, como monitoramento e e-mail, continuam funcionando, porque são serviços externos acessados por variáveis de ambiente.
Da Vercel, a mudança é de modelo. As funções serverless viram um servidor sempre ligado: um app Next.js roda com next build e next start, e as variáveis saem com vercel env pull. Rotas de API, middleware e renderização no servidor continuam funcionando. O que muda é que o cache e a otimização de imagens passam a rodar no próprio servidor, e não numa CDN global. Para um público concentrado no Brasil, a troca costuma compensar. Para um público espalhado pelo mundo, nem sempre.
Como faço para migrar meu app do Docker para uma cloud brasileira com menor latência?
Se o app já roda em Docker, a migração é levar a mesma imagem para um registry, criar um projeto a partir dela em uma região no Brasil e mover o banco para a mesma região. O código não muda. Na prática, o trabalho fica em cinco etapas, e só a do banco exige uma janela de manutenção.
- Confirme que a imagem sobe sozinha com docker run, recebendo a configuração por variáveis de ambiente e escutando em uma porta conhecida. Se ela depende de arquivos montados da sua máquina, mova essa configuração para variáveis antes de continuar.
- Publique a imagem em um registry, como Docker Hub, GitHub Container Registry ou um registry privado. Na Zenifra, imagens privadas funcionam informando a credencial do registry ao criar o projeto.
- Crie o projeto a partir da imagem, informe a porta e cadastre as variáveis. Se a aplicação grava arquivos que precisam sobreviver a um novo deploy, ative o armazenamento persistente ou, melhor ainda, mande os uploads para um armazenamento de arquivos compatível com S3.
- Crie o banco na mesma região da aplicação, gere um dump com pg_dump --format=custom e restaure com pg_restore. Ligue a aplicação ao banco por uma conexão privada, sem expor o banco na internet.
- Teste na URL da plataforma. Um dia antes da virada, baixe o TTL do DNS para alguns minutos. Na virada, pare a escrita no banco antigo, faça o dump final, restaure e aponte o domínio. Mantenha o ambiente antigo ligado por um ou dois dias, caso precise voltar.
Se você usa docker compose, cada serviço com porta HTTP vira um projeto, o serviço postgres do compose vira um banco gerenciado e o redis vira um Valkey. Os volumes nomeados viram armazenamento persistente ou object storage, conforme o tipo de arquivo.
O ganho de latência vem da distância. Uma visita nova a um site com HTTPS faz pelo menos três idas e voltas antes do primeiro byte. Com o servidor na Virgínia, são cerca de 390 ms só de rede. Com o servidor no Brasil, cerca de 33 ms. E a diferença cresce quando a aplicação conversa com um banco em outro continente: 20 consultas em sequência a 130 ms cada somam 2,6 segundos de espera.
Quanto custa a troca
Para comparar planos de entrada parecidos, pegamos uma aplicação sempre ligada com cerca de meia CPU e 512 MB de memória. Os preços das outras plataformas foram conferidos nas páginas oficiais em 29/09/2026, e os da Zenifra na API pública de planos em 30/10/2026.
| Plataforma | Plano | Por mês | Como é cobrado |
|---|---|---|---|
| Railway | Hobby, com 0,5 vCPU e 0,5 GB usados o mês todo | US$ 15 | US$ 5 de assinatura com US$ 5 de uso incluso, mais US$ 20 por vCPU e US$ 10 por GB de memória ao mês |
| Heroku | Basic, 512 MB | US$ 7 | Dólar no cartão, mais IOF |
| Render | Starter, 0,5 CPU e 512 MB | US$ 7 | Dólar no cartão, mais IOF |
| Vercel | Pro | US$ 20 | Dólar no cartão, com US$ 20 de uso incluso |
| Zenifra | Basic, 0,5 vCPU e 512 MB | R$ 29,90 | Real, por PIX, boleto ou cartão |
Com o banco, a conta muda pouco de proporção. O menor PostgreSQL pago custa US$ 5 no Heroku e US$ 6 no Render. Na Zenifra, o plano Starter custa R$ 11,90 por mês, mais R$ 0,20 por GB de disco. Se a sua aplicação fica ligada só parte do tempo, a cobrança por hora da Zenifra começa em R$ 0,05 por hora no plano Basic.
Preço de tabela não é o único custo de uma migração. Conte as horas do time para mover variáveis, banco e domínio. Para um app com um serviço e um banco, isso costuma caber em uma tarde, e a maior parte do tempo vai para testar.
Antes de virar a chave
Uma migração bem feita começa pelo inventário. Liste cada serviço, o comando de start, a porta, as variáveis de ambiente, os bancos, os volumes, os domínios e as tarefas agendadas. Tarefas que rodam por cron dentro da aplicação merecem atenção, porque com mais de uma instância elas rodam em dobro. Em uma PaaS, o lugar delas é um Job agendado.
Depois, rode a aplicação no destino com uma cópia do banco e compare. Abra as páginas principais, faça um login, rode uma compra de teste se for o caso e confira os logs. Só então marque a janela da virada, de preferência em um horário de pouco movimento, e avise os usuários se houver alguns minutos sem escrita no banco.
Quando ficar onde você está
Nem toda aplicação ganha com a troca, e vale ser honesto sobre isso.
Se a maioria dos usuários está nos EUA, na Europa ou na Ásia, Render e Railway já estão mais perto deles. Se o projeto é um site em Next.js com muito conteúdo estático, a CDN da Vercel entrega esse conteúdo perto de qualquer usuário, inclusive no Brasil. Se você depende de add-ons específicos do Heroku ou de Private Spaces para compliance, a migração exige substituir cada peça.
E se o seu app usa MongoDB, MySQL ou outro banco que o destino não oferece como serviço gerenciado, você vai precisar de um fornecedor separado para o banco, o que reduz a vantagem de ter tudo no mesmo lugar.
Resumindo
As alternativas brasileiras existem e se dividem pelo trabalho que deixam com você. PaaS para quem quer manter o deploy por push sem administrar servidor, nuvem nacional para quem quer controle e já opera infraestrutura, VPS para quem tem tempo e orçamento curto. Em todas, servidor no país e fatura em real.
Se o seu app já está em Docker ou no GitHub, a Zenifra deixa testar a migração com um projeto e um banco grátis, antes de mexer no domínio.