Migrar

Migre para a Railyard.

Toda migração funciona do mesmo jeito: faça o deploy ao lado da sua plataforma atual, teste em uma URL temporária e depois mude o DNS. Sua aplicação fica no ar o tempo todo. Escolha de onde você está saindo.

1/4Hoje seu domínio aponta para a sua plataforma atual.2/4Faça o deploy de uma cópia no seu próprio servidor e teste em uma URL temporária.3/4Traga seu banco de dados. Os usuários continuam vendo a app antiga.4/4Troque o DNS. O tráfego passa para o seu servidor e a app nunca saiu do ar.

Vindo do Heroku

A conta dos dynos sobe a cada processo e add-on, o free tier acabou, e nada disso é seu.

Ler o guia →

Vindo do Hatchbox.io

Mesma aposta, seus servidores, push para fazer deploy, mas uma camada mais fina, e um projeto de uma pessoa só com futuro incerto.

Ler o guia →

Vindo do Cloud 66

O mesmo modelo BYO-server, mas fechado, mais pesado e com preço para equipes maiores.

Ler o guia →

Vindo do Elestio

Hospedagem open-source com um clique, cobrada por recurso com uma assinatura de suporte extra.

Ler o guia →

Vindo do Render

DX ótima, mas é a infraestrutura do Render, as regiões do Render, e a conta do Render.

Ler o guia →

Vindo do Fly.io

Máquinas ótimas, mas as regiões do Fly, a conta do Fly, e um Postgres que no fim você mesmo acaba rodando.

Ler o guia →

Vindo do Railway

Ótimo para começar; o preço baseado em uso fica imprevisível, e não existe um caminho para "rodar na minha própria máquina".

Ler o guia →

Vindo do Vercel

Ótimo pra frontends e funções serverless; um backend que roda continuamente precisa de um servidor, o que o Vercel não oferece.

Ler o guia →

Vindo do Netlify

Ótimo para frontends estáticos, não feito para um backend que roda continuamente.

Ler o guia →

Vindo do Supabase

Um backend-as-a-service na infraestrutura do Supabase, não um lugar para rodar seu próprio código.

Ler o guia →

Vindo do Firebase

O backend-as-a-service do Google, cobrado por uso na própria infraestrutura.

Ler o guia →

Vindo do Cloudflare Pages

Sites estáticos e edge functions na rede do Cloudflare, não um servidor tradicional.

Ler o guia →

Vindo do Dokku

Um PaaS git-push gratuito e autogerenciado em um servidor, sem nenhuma ferramenta do dia dois.

Ler o guia →

Vindo do Kamal

Uma ferramenta de deploy gratuita e open source, sem dashboard, sem bancos de dados gerenciados e sem controle de acesso por equipe.

Ler o guia →

Vindo do CapRover

Um PaaS gratuito e autogerenciado com um marketplace de apps em um clique, mas sem backups gerenciados.

Ler o guia →

Vindo do Laravel Cloud

Totalmente gerenciado pela equipe do Laravel no próprio AWS deles, cobrado por uso.

Ler o guia →

Vindo do Laravel Forge

Um painel de gestão de servidores, cobrado separadamente dos servidores que ele gerencia.

Ler o guia →

Vindo do Ploi

Uma alternativa ao Forge mais leve e barata, ainda cobrada separadamente dos servidores que gerencia.

Ler o guia →

Vindo do Zeabur

Um marketplace de templates cobrado por uso, na própria nuvem do Zeabur por padrão.

Ler o guia →

Vindo do Koyeb

Containers com autoscaling na própria rede edge global do Koyeb, sem opção de usar sua própria nuvem.

Ler o guia →

Vindo do Northflank

Kubernetes na sua própria conta de nuvem, com preço por recurso em cima da sua fatura de nuvem.

Ler o guia →

Vindo do Porter

Um cluster Kubernetes gerenciado na sua conta AWS, com custo-base próprio antes mesmo do seu app rodar.

Ler o guia →

Vindo do Qovery

Kubernetes na sua própria conta de nuvem, com preço por assento a partir de centenas de dólares por mês.

Ler o guia →

Vindo do Clever Cloud

Um PaaS europeu com infraestrutura própria, com preço por tamanho de instância e uso.

Ler o guia →

Vindo do Aptible

Hospedagem gerenciada focada em compliance, com planos de produção comumente a partir de quase 499 dólares por mês.

Ler o guia →

Vindo do Scaleway

Containers serverless que só rodam na própria nuvem do Scaleway.

Ler o guia →

Vindo do Neon

Um banco de dados Postgres serverless, não um lugar para rodar sua aplicação.

Ler o guia →

Vindo do Flightcontrol

Deploys só na AWS via ECS, com ambientes de preview bloqueados num plano de 397 dólares por mês.

Ler o guia →

Vindo do Appliku

Uma plataforma de deploy só para Django, em servidores que você possui, com preço por servidor.

Ler o guia →

Vindo do Laravel Vapor

Laravel serverless na sua conta AWS, cobrado pelo Vapor em cima da sua conta AWS.

Ler o guia →

Vindo do Anywhere else

Fly, App Platform, Coolify, Dokku, uma VPS configurada na mão. O formato da migração é o mesmo.

Ler o guia →

Passos

Toda migração segue os mesmos seis passos.

  1. 01 Adicione um servidor: um que você já tem, ou um que a Railyard cria na sua conta na nuvem.
  2. 02 Adicione seu repositório. Dockerfile, buildpacks ou Procfile são lidos como estão.
  3. 03 Traga suas variáveis de ambiente. Conecte Postgres, MySQL ou Redis com as strings de conexão já configuradas pra você.
  4. 04 Faça o deploy em uma URL temporária e teste.
  5. 05 Restaure o dump do seu banco de dados no add-on gerenciado.
  6. 06 Mude o DNS. A plataforma antiga continua respondendo até o registro mudar, e depois você cancela a conta.

Não exclua a aplicação antiga até que tráfego real esteja chegando na Railyard. Mantenha a plataforma antiga por uma semana, depois cancele.

Faça o deploy ao lado da sua plataforma atual e depois mude.

Comece no plano Free ou em um teste Pro de 14 dias, sem cartão. Nada muda até você apontar o DNS pra lá.

Plano grátis, sem cartão, e 14 dias de Pro para cada equipe nova. Um preço fixo por equipe.