Vindo do Fly.io

Por que as equipes deixam o Fly

O Fly facilita rodar containers perto dos usuários. Mas a cobrança baseada em uso é difícil de prever, a plataforma decide quais regiões e tamanhos de máquina você recebe, e o “Fly Postgres” é um Postgres que você mesmo gerencia em máquinas do Fly.

O Railyard te dá o mesmo fluxo container-first em um servidor Linux na sua própria conta de nuvem (como DigitalOcean, Hetzner, Vultr ou AWS), ou em qualquer máquina Ubuntu que você acesse por SSH. Seu provedor cobra você direto, no preço dele, e o Railyard gerencia Postgres, Redis e backups para você.

O jeito rápido: o importador (beta)

Applications → New app → Import from Heroku / Render / Fly. Escolha Fly.io, cole um token de fly tokens create org e informe sua organização do Fly (o padrão é personal). Escolha um app, revise o que será copiado, depois importe e faça o deploy. O Railyard guarda seu token só durante essa importação e o esquece depois de 30 minutos.

O que o importador traz da Machines API do Fly:

• A imagem exata que o Fly está rodando, baixada usando seu token como senha do registry, então nada é rebuildado.
• Variáveis de ambiente da configuração da máquina, e a porta interna.
• Nomes dos secrets. O Fly nunca revela os valores dos secrets, então a página de revisão os lista para você digitar de novo.

O que ele só sinaliza para você:

• Outros process groups (um worker, por exemplo) não são copiados. Adicione eles como workers.
• Volumes começam vazios. Copie os arquivos deles você mesmo (veja abaixo).
• Dados do Postgres não são copiados pelo importador do Fly. Mova com um dump (veja abaixo).
• Domínios são listados, não conectados. Adicione quando o novo app estiver no ar.

Beta: o importador é testado contra as respostas documentadas da API do Fly, e em produção ele acessa a API real do Fly. Ainda não foi testado de ponta a ponta contra uma conta real do Fly. Se algo não vier corretamente, use os passos manuais abaixo e fale com a gente.

O jeito manual

1. Adicione um servidor. O Railyard pode criar um na sua conta de nuvem, ou você pode conectar um que já tem. Veja Add a server.
2. Crie o app. Se seu repositório tem um Dockerfile, como a maioria dos apps do Fly, aponte o Railyard para o repositório e ele builda a partir dele. Ou faça deploy da imagem que você já envia para um registry. Veja Deploy a Docker image.
3. Defina a porta. Use o internal_port da seção [http_service] ou [[services]] do seu fly.toml.
4. Traga sua configuração. Copie o bloco [env] do fly.toml para Variables. O fly secrets list mostra os nomes dos secrets; cole os valores de onde você os guarda.
5. Adicione um banco de dados. Conecte o Postgres (e o Redis, se você usar). O Railyard cria o banco de dados e define DATABASE_URL / REDIS_URL.
6. Faça o deploy e confira o app no endereço temporário sslip.io.
7. Mova os dados. Abra um túnel com fly proxy 15432:5432 -a <your-postgres-app>, rode pg_dump -Fc contra localhost:15432, depois envie o dump em Resources → Import data no app do Railyard. O upload mostra o progresso, e você pode cancelá-lo. Para arquivos em um volume do Fly, use fly ssh sftp get (ou tar via fly ssh console) e restaure no volume ou bucket do app.
8. Troque o DNS. Adicione seu domínio no Railyard, depois aponte o registro para o seu servidor. O Fly continua servindo até o registro mudar, então nada fica fora do ar. Depois, escale o app do Fly para zero e exclua ele.

Como os conceitos do Fly se traduzem

Fly	Railyard
Machines em várias regiões	Um ou mais servidores seus. O processo web de um app pode rodar em vários servidores atrás do primário
Process groups ([processes])	Tipos de processo: web e workers, de um Procfile ou definidos manualmente
release_command	Comando de release, roda uma vez antes da nova versão receber tráfego
Health checks	Um caminho de health check. A nova versão precisa passar nele antes de o tráfego ser movido
Volumes	Volumes no servidor, com backups
Fly Postgres / Managed Postgres	Postgres gerenciado no seu servidor ou em um servidor de banco de dados, com backups verificados e restore point-in-time
fly deploy	git push, railyard deploy, ou um push para o GitHub
fly logs / fly ssh console	railyard logs --follow / railyard run e a aba Console
Auto-stop machines	Sleep do app: stagings ociosas dormem e acordam na próxima requisição

O que é diferente

O Railyard não roda uma borda anycast. Seu app é servido a partir da região do seu servidor, e ainda não existe roteamento automático multi-região. Em troca, a conta é um preço fixo de servidor que você consegue prever, as máquinas são suas, e se você parar de usar o Railyard, seu app continua rodando.