Migrare da Railway

Migra i servizi Railway insieme al database e alle variabili.

Un progetto Railway è un insieme di servizi collegati tramite riferimenti tra variabili. Su Nodion, un servizio con un proprio codice diventa un'applicazione, i worker che usano lo stesso codice diventano processi aggiuntivi di quell'app, e i database diventano database gestiti che colleghi all'app. Nodion non legge railway.json né railway.toml; Railway stesso sta dismettendo Config as Code (scadenza definitiva 2026-12-01), quindi devi trasferire le impostazioni manualmente.

Corrispondenze tra Railway e Nodion

1. Crea il progetto e i database

Crea un progetto e, al suo interno, i database che usa il tuo progetto Railway, nella regione in cui devono girare le app. Per Postgres, scegli una versione non precedente a quella su Railway. Al posto di Redis, Nodion offre Valkey, anch'esso collegato come REDIS_URL. Un Valkey vuoto basta solo per cache o code che prima lasci svuotare; se ti servono le chiavi da Redis, spostale prima di eliminare il progetto Railway. Maggiori dettagli in Database.

2. Copia il database

I database Railway sono privati per impostazione predefinita. Per il dump puoi raggiungerli in due modi. Puoi attivare l'accesso pubblico in Settings, Networking; Railway crea allora un TCP proxy, imposta DATABASE_PUBLIC_URL (documentazione Railway) e fattura il traffico che passa dal proxy come egress. Oppure puoi lasciare il database privato e aprire un tunnel con la Railway CLI, dopo aver collegato il progetto con railway link. I backup dei volumi integrati di Railway si ripristinano solo nello stesso progetto, quindi per il trasferimento serve pg_dump.

Blocca le scritture dai tuoi servizi, poi crea il dump come indicato nella guida ai backup di Railway. Con l'accesso pubblico, usa il valore di DATABASE_PUBLIC_URL preso dalle variabili del servizio del database:

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

Con il tunnel, collega prima il progetto con railway link, poi apri il tunnel e, in un secondo terminale, fai il dump verso localhost con la porta che mostra la CLI:

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

In Nodion apri la scheda Overview del database e clicca Enable public access. Quando l'endpoint non mostra più Provisioning, copia l'URL di connessione (sempre TLS) e aggiungi il tuo IP in Allowed sources. Poi esegui il restore:

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

Usa un pg_restore almeno recente quanto il più recente dei due server. Controlla il numero di righe nella scheda Browse, poi disattiva di nuovo l'accesso pubblico, anche su Railway.

3. Crea l'applicazione e i suoi processi

Crea un'applicazione per ogni servizio con codice, dal suo repository Git. Se Railway faceva la build con Railpack o Nixpacks, usa la strategia Buildpacks (Buildpack); se trovava un Dockerfile, usa la strategia Dockerfile. A differenza di Railway, Nodion non sceglie la strategia al posto tuo: la imposti tu.

Railway inietta PORT nei tuoi servizi. Nodion imposta PORT solo per il processo web delle app con buildpack; sulle app Dockerfile l'app resta in ascolto sulla porta del processo web (altrimenti sulla porta indicata da EXPOSE nell'immagine, altrimenti su 8080).

Se un secondo servizio usava lo stesso repo e cambiava solo lo start command, per esempio un worker, aggiungi un processo alla stessa app da Processes, New process e inserisci il suo start command. Sposta un pre-deploy command in una riga release: del Procfile (buildpack) o nel release command dell'app (Settings, nel riquadro Preview environments, dove il campo compare una volta attivate le anteprime, oppure release_command tramite l'API). Viene eseguito una volta per ogni deploy prima di web; se fallisce, resta attiva la release precedente.

4. Trasferisci le variabili

Stampa le variabili di un servizio come righe KEY=value (Railway CLI):

bashrailway variable list --kv > railway.env

Incolla le righe in Environment, Add many. La Railway CLI non stampa le sealed variables (documentazione Railway); impostale a mano, come secret, con nodion env set KEY=value --secret. Controlla i valori con virgolette e imposta i valori su più righe tramite CLI o API.

Nodion non supporta riferimenti come ${{shared.KEY}} o ${{otherService.KEY}}. Controlla ogni variabile importata: deve contenere il valore effettivo, non il testo del riferimento. Dove un riferimento puntava a un altro servizio, imposta invece l'hostname interno di quel servizio su Nodion (<app>.app.internal), oppure collega il database.

Elimina di nuovo le variabili che puntano a un database Railway (DATABASE_URL, REDIS_URL): una variabile impostata da te sovrascrive il valore di un database collegato. Collega i database con Attach database. All'interno di Nodion la connessione passa senza TLS (sslmode=disable); se il tuo codice forza SSL, disattivalo per questo URL.

5. Trasferisci i cron job

Su Railway un cron job è un servizio a sé che si avvia e termina (documentazione Railway). Su Nodion lo aggiungi nella scheda Cron dell'app di cui gli serve il codice: pianificazione a cinque campi in UTC, il comando, un timeout fino a 30 minuti, fino a 8 job per app. Gira con la release attiva e le variabili d'ambiente dell'app.

6. Fai il deploy, trasferisci il dominio ed elimina il progetto Railway

Fai il deploy e controlla la scheda Logs. Poi aggiungi il dominio nella scheda Domains e imposta i due record che mostra Nodion: TXT _nodion-challenge.your-domain e un CNAME (un ALIAS sull'apex) verso l'hostname predefinito dell'app. Il certificato arriva appena il CNAME punta a Nodion; metti in conto qualche minuto senza un certificato valido e abbassa prima il TTL. Quando tutto funziona, elimina il progetto Railway; secondo Railway l'operazione è definitiva.

bashrailway delete --project my-project --yes

Cosa funziona diversamente

• Non ci sono ambienti come production e staging all'interno di un progetto; usa app o progetti separati.
• Non ci sono shared variables né riferimenti; i valori del database arrivano collegando il database.
• I cron job girano su un'app esistente, non come servizio a sé.
• La CLI recupera i log ma non può seguirli; per vederli in tempo reale usa la scheda Logs.

Prossimi passi

Nodion e Railway a confronto, Prezzi, Applicazioni e Database.