Migrar do Railway

Migre os serviços do Railway com a base de dados e as variáveis.

Um projeto Railway é um conjunto de serviços ligados por referências a variáveis. Na Nodion, um serviço com código próprio passa a ser uma aplicação, os workers do mesmo código passam a ser processos adicionais dessa aplicação e as bases de dados passam a ser bases de dados geridas que associa à aplicação. A Nodion não lê railway.json nem railway.toml; o próprio Railway vai descontinuar o Config as Code (data-limite: 1 de dezembro de 2026), por isso as definições têm de ser transferidas manualmente.

O que corresponde a quê

1. Crie o projeto e as bases de dados

Crie um projeto e, dentro dele, as bases de dados que o seu projeto Railway usa, na região onde as aplicações devem correr. Para o Postgres, escolha uma versão pelo menos tão recente como a utilizada no Railway. Em vez de Redis, a Nodion oferece Valkey, também associado como REDIS_URL. Um Valkey vazio só serve para caches ou filas que deixe esvaziar primeiro; se precisar das chaves do Redis, migre-as antes de eliminar o projeto Railway. Mais informações em Bases de dados.

2. Copie a base de dados

As bases de dados do Railway são privadas por omissão. Para o dump, pode aceder-lhes de duas formas: ativar o acesso público em Settings, Networking; o Railway cria então um proxy TCP e define DATABASE_PUBLIC_URL (documentação do Railway) e fatura o tráfego que passa pelo proxy como egress. Ou manter a base de dados privada e abrir um túnel com a CLI do Railway, depois de ligar o projeto com railway link. Os backups de volumes integrados no Railway só podem ser restaurados no mesmo projeto, por isso uma migração exige pg_dump.

Pare as escritas dos seus serviços e, depois, crie o dump como indica o guia de backups do Railway. Com acesso público, use o valor de DATABASE_PUBLIC_URL das variáveis do serviço da base de dados:

bashpg_dump "postgresql://postgres:PASSWORD@PROXY_HOST:PROXY_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

Através do túnel, ligue primeiro o projeto com railway link, abra depois o túnel e, num segundo terminal, faça o dump a partir de localhost com a porta que a CLI mostra:

bashrailway link
railway connect postgres --tunnel-only

# second terminal
pg_dump "postgresql://postgres:PASSWORD@localhost:TUNNEL_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

Na Nodion, abra o separador Overview da base de dados e clique em Enable public access. Quando o endpoint deixar de mostrar Provisioning, copie o URL de ligação (sempre TLS) e adicione o seu próprio IP em Allowed sources. Depois, restaure:

bashpg_restore --verbose --no-owner --no-acl \
  --dbname "postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  railway.dump

Use um pg_restore pelo menos tão recente como o mais recente dos dois servidores. Verifique o número de linhas no separador Browse e, depois, desative novamente o acesso público, também no Railway.

3. Crie a aplicação e os respetivos processos

Crie uma aplicação por cada serviço de código, a partir do respetivo repositório Git. Se o Railway fazia o build com Railpack ou Nixpacks, use a estratégia Buildpacks (Buildpacks); se encontrava um Dockerfile, use a estratégia Dockerfile. Ao contrário do Railway, a Nodion não escolhe a estratégia automaticamente: defina-a manualmente.

O Railway injeta PORT nos seus serviços. A Nodion define PORT apenas para o processo web das aplicações com buildpacks; nas aplicações Dockerfile, a aplicação escuta na porta do processo web (caso contrário, no EXPOSE da imagem e, por fim, em 8080).

Se um segundo serviço corria a partir do mesmo repositório apenas com outro comando de arranque, por exemplo um worker, adicione-o em Processes, New process como outro processo da mesma aplicação e introduza aí o comando de arranque. Passe um comando pre-deploy para uma linha release: no Procfile (buildpacks) ou para o comando de release da aplicação (Settings, no cartão Preview environments, onde o campo aparece depois de ativar as pré-visualizações, ou release_command através da API). É executado uma vez por deploy, antes do web; se falhar, a release anterior continua ativa.

4. Transfira as variáveis

Mostre as variáveis de um serviço como linhas KEY=value (Railway CLI):

bashrailway variable list --kv > railway.env

Cole as linhas em Environment, Add many. A CLI do Railway não mostra as sealed variables (documentação do Railway); defina-as manualmente, como segredos, com nodion env set KEY=value --secret. Verifique os valores com aspas e defina os valores com várias linhas através da CLI ou da API.

A Nodion não tem referências como ${{shared.KEY}} ou ${{otherService.KEY}}. Verifique cada variável importada: deve conter o valor real e não o texto da referência. Onde uma referência apontava para outro serviço, defina antes o hostname interno desse serviço na Nodion (<app>.app.internal) ou associe a base de dados.

Depois, elimine as variáveis importadas que apontam para uma base de dados do Railway (DATABASE_URL, REDIS_URL): uma variável definida manualmente substitui o valor de uma base de dados associada. Associe as bases de dados com Attach database. Dentro da Nodion, a ligação é feita sem TLS (sslmode=disable); se o seu código forçar SSL, desative-o para este URL.

5. Transfira as tarefas cron

No Railway, uma tarefa cron é um serviço próprio que é executado e termina (documentação do Railway). Na Nodion, adiciona-a no separador Cron da aplicação de cujo código precisa: um agendamento de cinco campos em UTC, o comando, um tempo limite de até 30 minutos, até 8 tarefas por aplicação. É executada com a release ativa e as variáveis de ambiente da aplicação.

6. Faça deploy, transfira o domínio, desligue o Railway

Faça deploy e verifique o separador Logs. Depois, adicione o domínio no separador Domains e crie os dois registos que a Nodion mostra: TXT _nodion-challenge.your-domain e um CNAME (um ALIAS no apex) para o hostname da aplicação definido por omissão. O certificado é emitido quando o CNAME apontar para a Nodion; conte com alguns minutos sem certificado válido e reduza o TTL antecipadamente. Quando tudo estiver a funcionar, elimine o projeto Railway; segundo o Railway, esta eliminação é permanente.

bashrailway delete --project my-project --yes

O que funciona de forma diferente

• Não existem ambientes como production e staging dentro de um projeto; use aplicações ou projetos separados.
• Não existem variáveis partilhadas nem referências; os valores da base de dados vêm da associação da base de dados.
• As tarefas cron são executadas numa aplicação existente e não como um serviço próprio.
• A CLI obtém os logs, mas não os consegue acompanhar em tempo real; veja-os em direto no separador Logs.

Próximos passos

A Nodion comparada com o Railway, Preços, Aplicações e Bases de dados.