Railway alternatives: dove migrare app e database nel 2026

Per chi cerca «Railway alternatives», il punto di partenza è l’annuncio del 21 ottobre 2026: Railway ha comunicato che un soggetto non autorizzato potrebbe aver avuto accesso alle variabili d’ambiente dei clienti, compresi alcuni contenuti decifrati. Railway ha scritto: «Tutti i deployment sono sospesi mentre svolgiamo le indagini», raccomandando di ruotare variabili d’ambiente e credenziali. La comunicazione di Railway

Tra le alternative a Railway, Render è la prima da valutare per un servizio web con Postgres, un worker e job cron; Northflank è il concorrente più vicino per i team che vogliono maggiore controllo sui deployment. Fly.io si presta a scelte infrastrutturali precise, Coolify a chi è pronto a gestire i server in proprio e Netlify alla separazione del frontend con funzioni serverless.

La priorità immediata è ruotare le credenziali presso i provider che le hanno emesse e controllare i log di accesso. Cambiare piattaforma è una decisione distinta. Esportare le stesse chiavi in una nuova dashboard non equivale a ruotarle, e preparare un secondo deployment non obbliga a spostare oggi il traffico dei clienti.

I prezzi e le funzionalità riportati qui sono stati verificati sulle pagine ufficiali dei fornitori il 22 ottobre 2026. La citazione della comunicazione descrive l’annuncio di Railway, non lo stato attuale dei suoi deployment. Il confronto valuta l’adeguatezza ai carichi di lavoro e l’impegno richiesto dalla migrazione; non classifica i fornitori in base a una presunta maggiore sicurezza.

Railway alternatives a confronto

La scelta deve tenere conto dell’intera applicazione. Un servizio è un processo che resta disponibile per rispondere alle richieste; un worker elabora attività in background; cron avvia le attività secondo una pianificazione. Postgres conserva i dati relazionali, mentre un volume mantiene i file al di fuori di un container applicativo sostituibile. Sono responsabilità diverse, anche quando una dashboard le riunisce nella stessa schermata.

I prezzi iniziali indicano la soglia d’ingresso, non il preventivo dell’intero stack. Risorse di calcolo a pagamento, sandbox gratuite, licenze software e tariffe a consumo sono distinte, per evitare di confondere un frontend gratuito con l’hosting gratuito di database e worker. Tutti gli importi sono in USD; componenti aggiuntivi e consumi ulteriori si pagano a parte.

Le colonne sui carichi di lavoro e sui segreti descrivono i modelli operativi documentati. La cifratura a riposo non impedisce al codice applicativo che ha accesso a una credenziale di usarla. Fly.io, per esempio, avverte esplicitamente che chi può effettuare deployment può distribuire codice capace di leggere i segreti a runtime. I segreti su Fly.io

Come sono state selezionate le piattaforme

La classifica riguarda un piccolo servizio già esistente, con dati da conservare e attività in background, non una landing page statica. I criteri decisivi sono la corrispondenza con i processi originali, la responsabilità della gestione di Postgres, la collocazione dei file persistenti, il comportamento delle attività pianificate e il modo in cui le credenziali arrivano al codice in esecuzione.

Il confronto si basa sulle funzionalità documentate e sui prezzi correnti dei fornitori; per questo articolo non sono stati eseguiti deployment né benchmark delle piattaforme. Non sono stati ricavati punteggi di disponibilità, prestazioni o sicurezza dai materiali promozionali dei fornitori.

Le piattaforme per gestire ambienti di sviluppo o infrastrutture Kubernetes possono essere utili, ma introducono un livello di astrazione che a questo lettore potrebbe non servire. La selezione si concentra sulle destinazioni in cui eseguire l’applicazione; Netlify è incluso come opzione volutamente più circoscritta al frontend. La scelta cambia se l’app richiede un filesystem condiviso, un comportamento specifico dello scheduler o che il ripristino del database sia responsabilità di un altro soggetto.

La classifica per questo stack applicativo

1. Render: la prima alternativa gestita da provare

Render è una piattaforma applicativa gestita: servizi web, worker in background, job cron e Postgres gestito corrispondono direttamente ai componenti di questo stack Railway. Per un fondatore che gestisce un’API per gli abbonamenti, un worker per le email e una riconciliazione notturna, ogni processo trova una collocazione precisa. Questo riduce le modifiche all’applicazione necessarie prima di iniziare una prova di migrazione. Il limite principale riguarda i dischi persistenti: un servizio con disco collegato non può scalare su più istanze, e collegare un disco impedisce i deployment senza interruzioni. Scegli Render quando mantenere l’architettura dell’applicazione conta più che personalizzare l’infrastruttura. Tipi di servizio · Limiti dei dischi

Ideale per: Un fondatore che cerca una piattaforma gestita familiare per l’intero stack.
Punto di forza: Tipi di servizio distinti per API, worker e attività pianificate.
Prezzi: Servizio a pagamento da $7/mese; database, worker, cron ed eventuali costi del workspace si pagano separatamente. Prezzi attuali
Prova gratuita: Sono disponibili risorse di calcolo gratuite con limiti; usale per valutare la piattaforma.

Conserva la configurazione nelle variabili del servizio o nei gruppi di ambiente. Un gruppo è una raccolta condivisa, utile quando API e worker devono usare lo stesso indirizzo del database. I file di segreti sono un’altra possibilità per le credenziali che l’applicazione si aspetta di leggere da disco; il servizio in esecuzione li riceve come file in chiaro. Assegna a ogni processo solo la configurazione necessaria, evitando di collegare ovunque l’intera raccolta dei segreti di produzione. Variabili d’ambiente e segreti

Il vincolo dei dischi conta anche per una piccola app. Se il worker genera un PDF e il servizio web deve leggerlo in seguito, collegare un disco al worker non lo rende visibile al servizio web. Sposta questo scambio su storage a oggetti, oppure ridefinisci quale processo gestisce il file prima del passaggio in produzione. Mantenere lo stesso nome del percorso non dimostra che entrambi i processi possano accedervi.

Come provare il primo servizio su Render

1. 1

   Ricrea la separazione tra i processi

   Crea il servizio web dal repository o dal container dell’applicazione, poi crea il worker con il proprio comando di avvio. Aggiungi l’attività pianificata come job cron. Mantieni il nuovo worker e la pianificazione inattivi rispetto alla produzione finché la prova sui dati non è pronta.

2. 2

   Crea un database di destinazione vuoto

   Attiva Render Postgres e ripristina un’esportazione di prova seguendo le istruzioni di Render per migrare da Railway. Configura le stringhe di connessione della destinazione, anziché copiare i nomi host privati di Railway.

3. 3

   Imposta nuove credenziali e prova il flusso completo

   Compila le variabili a partire dall’inventario verificato. Su un dominio temporaneo, prova un accesso, una scrittura nel database, un’attività in coda e il suo risultato, indirizzando gli effetti sui servizi esterni verso account di test.

La guida di Render alla migrazione da Railway fornisce i passaggi specifici della piattaforma. La checklist per il passaggio in produzione riportata più avanti affronta ciò che un deployment riuscito non può dimostrare: che dati e attività pianificate siano stati trasferiti correttamente.

2. Northflank: per chi vuole più controllo sui deployment

Northflank è una piattaforma per container con servizi applicativi, addon per database, job pianificati e storage persistente. Un piccolo team che gestisce un’API, un consumer di coda e importazioni ricorrenti può definirli insieme, mantenendo esplicite le regole di deployment e configurazione. Template e pipeline diventano utili quando lo stesso sistema richiede ambienti di staging e produzione. Il compromesso è dover imparare a usare più controlli durante la migrazione. Scegli Northflank quando il cambio di piattaforma deve anche migliorare la gestione di più servizi. Funzionalità della piattaforma

Ideale per: Un team che vuole definizioni di deployment riutilizzabili e maggiore controllo sugli ambienti.
Punto di forza: Servizi, job, database e volumi, con la possibilità di passare a deployment nel proprio cloud.
Prezzi: Sandbox gratuito; CPU a pagamento da $0.01667/vCPU-ora, con RAM, storage e rete fatturati separatamente. Prezzi attuali
Prova gratuita: Il Sandbox è un livello gratuito con una dotazione limitata di risorse.

I gruppi di segreti possono contenere argomenti di build, variabili di runtime e credenziali dei database collegati. Importa le variabili verificate, limita il gruppo ai servizi o agli ambienti che ne hanno bisogno e usa l’azione di riavvio dei servizi dipendenti per applicare i valori modificati. È utile quando worker e API condividono una credenziale del database che al frontend non serve. Gruppi di segreti

Nelle migrazioni automatizzate c’è un dettaglio dalle conseguenze rilevanti: aggiornare un gruppo di segreti tramite API o CLI sostituisce la raccolta di variabili o file inviata, anche con una richiesta PATCH. Uno script che invia soltanto la chiave modificata può eliminare tutte le altre. Leggi il gruppo, integra la modifica desiderata e invia la raccolta completa seguendo il flusso documentato.

Sul fronte dei prezzi, il punto critico è sommare tutte le voci. La tariffa della CPU non coincide con la fattura mensile dell’applicazione: contano anche memoria, storage persistente e traffico in uscita. Usa l’inventario dei carichi di lavoro per stimare il costo di ogni componente sempre attivo, poi valuta se i controlli operativi giustificano il lavoro di configurazione aggiuntivo.

3. Fly.io: per scegliere consapevolmente runtime e regioni

Fly.io esegue le applicazioni in Machines, macchine virtuali leggere da configurare in base al carico di lavoro. È adatto a un fondatore con competenze tecniche che vuole scegliere dove eseguire l’API e il suo worker, ed è disposto a occuparsi di più dettagli del deployment. I gruppi di processi o le app separate permettono di eseguire indipendentemente processo web e worker; le app separate possono comunicare sulla rete privata di Fly.io. Il limite è che pianificazione e collocazione dei dati persistenti vanno progettate esplicitamente. Scegli Fly.io per un controllo che intendi sfruttare, non solo per il prezzo minimo delle risorse di calcolo. Configurazione dei processi

Ideale per: Chi gestisce l’infrastruttura e ha dimestichezza con Machines, regioni e configurazione esplicita dei processi.
Punto di forza: Collocazione indipendente delle applicazioni e runtime configurabile.
Prezzi: La Machine più piccola, sempre attiva, costa $2.19 per 30 giorni ad Ashburn o Secaucus, con 256 MB RAM; Postgres gestito, storage e traffico si pagano a parte. Prezzi attuali
Prova gratuita: È disponibile una prova limitata; le nuove organizzazioni non hanno un livello gratuito permanente.

Tra le opzioni di pianificazione documentate da Fly.io ci sono Cron Manager, un’app che avvia Machines temporanee per le attività pianificate, e Supercronic, che esegue cron all’interno di un container. Sono opzioni utili, ma devono essere distribuite e gestite come parte del sistema. Evita di scalare per errore uno scheduler creando copie che inviano tutte lo stesso sollecito di pagamento. Pianificazione delle attività

Fly conserva i segreti delle app in un archivio cifrato e li inietta all’avvio delle Machines. I segreti sono condivisi tra i gruppi di processi della stessa app; le app separate richiedono ciascuna la propria configurazione. Questo può essere un motivo per separare processi con esigenze diverse in fatto di credenziali, oltre che un’attività di configurazione da includere nell’inventario.

Se cambi regione, stabilisci dove si trova il database prima di scegliere dove eseguire il processo web. Un’API più vicina all’utente può comunque essere lenta se ogni richiesta attraversa più volte il confine tra regioni per raggiungere il database. Distingui inoltre Fly.io Managed Postgres dalla gestione di un database in proprio su una Machine con volume. Nel secondo caso ottieni un server; non trasferisci la responsabilità operativa del database a un servizio gestito.

4. DigitalOcean App Platform: per app stateless nell’ecosistema DigitalOcean

DigitalOcean App Platform è un servizio di hosting applicativo gestito con servizi web, worker e job, affiancabile a DigitalOcean Managed Databases. È adatto a un fondatore la cui applicazione conserva già i file caricati al di fuori dei container e che vuole app e database presso lo stesso provider. I job pianificati nativi sono ora documentati, quindi uno scheduler esterno non è necessariamente indispensabile. Il limite decisivo è lo storage: App Platform non supporta i volumi. Sceglilo quando l’app può trattare il filesystem locale come temporaneo. Limiti di App Platform

Ideale per: API e worker stateless, soprattutto per chi è già cliente DigitalOcean.
Punto di forza: Componenti applicativi gestiti con job pianificati nativi.
Prezzi: Container a pagamento da $5/mese; database, altri container e consumi aggiuntivi sono separati. Prezzi attuali
Prova gratuita: Esiste un’offerta gratuita per siti statici; non copre questo stack backend completo.

Le variabili d’ambiente a livello di app e di componente possono essere limitate alla fase di build o al runtime. Usa l’opzione Encrypt per i valori sensibili: DigitalOcean documenta che li nasconde nei log di build, deployment e applicazione. Tieni la password del database fuori dalla build del frontend, a meno che questa non richieda davvero l’accesso al database. Variabili d’ambiente

Lo scheduler supporta job ricorrenti con un intervallo minimo di 15 minuti. È sufficiente per un report notturno, ma un’attività che deve avviarsi più spesso richiede una soluzione diversa o un’altra piattaforma. Controlla pianificazione, fuso orario e durata massima osservata del job prima di considerare equivalente il comportamento dopo la migrazione. Configurazione dei job pianificati

Per i file, una migrazione comune consiste nel sostituire la directory locale degli upload con storage a oggetti e salvare gli identificatori degli oggetti in Postgres. È una modifica all’applicazione: provala prima di spostare il traffico. Copiare la directory nell’immagine del container non renderà persistenti i futuri file caricati dagli utenti. Valuta inoltre il Managed Database di produzione separatamente dal database di sviluppo mostrato nella pagina prezzi dell’app.

5. Heroku: per i team che conoscono già i dyno

Heroku è una piattaforma applicativa gestita costruita attorno ai dyno, container che eseguono processi web, worker e attività occasionali. È una destinazione pratica se il team ne conosce già il modello di processi e vuole Heroku Postgres gestito. Una normale applicazione web con un consumer di coda separato trova una corrispondenza naturale. I limiti sono il filesystem effimero e il comportamento di Heroku Scheduler. Scegli Heroku per la familiarità del modello operativo, con un piano esplicito per i file e le attività pianificate critiche. Documentazione dei dyno

Ideale per: Un team già a suo agio con le convenzioni di Heroku per deployment e processi.
Punto di forza: Dyno web e worker affiancati a Postgres gestito.
Prezzi: Dyno Basic sempre attivo da $7/mese; database e risorse di calcolo per worker e attività pianificate si pagano a parte. Prezzi attuali
Prova gratuita: Non basare il budget su un livello backend gratuito; l’opzione sempre attiva citata è a pagamento.

Heroku conserva la configurazione nelle config vars persistenti dell’app e le espone come variabili d’ambiente. Modificare una config var crea una release e riavvia l’applicazione. Pianifica la rotazione come un evento applicativo: verifica la nuova credenziale, osserva il riavvio e poi rimuovi la credenziale precedente presso chi l’ha emessa. Config vars

La documentazione di Heroku Scheduler indica che l’esecuzione dei job è prevista, ma non garantita. Per le attività pianificate critiche raccomanda un processo clock personalizzato. Saltare una pulizia della cache è diverso da saltare una riconciliazione della fatturazione: quest’ultima richiede un registro verificabile dei job, tentativi di riesecuzione e una scelta consapevole dello scheduler. Comportamento di Scheduler

I dyno Basic, inoltre, non supportano la scalabilità orizzontale: per aggiungere istanze parallele serve un altro livello di dyno. Può essere del tutto sufficiente per una prova, ma il piano che avvia l’app non è automaticamente quello adatto al traffico dei clienti. I file scritti dentro un dyno scompaiono quando si arresta o si riavvia: sposta quindi tutti gli upload da conservare prima di usarlo come destinazione.

6. Koyeb: per servizi che non dipendono da volumi in produzione

Koyeb è una piattaforma applicativa che supporta servizi web, worker e Postgres serverless gestito. Vale la pena valutarla quando API ed elaborazione in background sono già indipendenti dai file locali persistenti. Il modello di servizio accetta sorgenti applicativi o container già costruiti, offrendo al team un punto di partenza semplice per una prova di deployment. Per un’app Railway che usa molto i volumi, l’ostacolo è esplicito nella documentazione di Koyeb: i volumi sono in anteprima pubblica e indicati come adatti soltanto ai test. Considera Koyeb per la parte stateless dello stack, non come sostituto equivalente dei volumi di produzione. Modello dei servizi · Stato dei volumi

Ideale per: Un servizio web e un worker i cui dati persistenti si trovano già fuori dai volumi applicativi.
Punto di forza: Tipi di servizio separati per web e worker, con Postgres serverless disponibile.
Prezzi: Prezzo d’ingresso Pro pubblicato: $29/mese più risorse di calcolo, con $10 di risorse di calcolo inclusi; non è un preventivo dell’intero stack. Prezzi attuali
Prova gratuita: Le singole risorse gratuite non implicano che l’intero stack sia gratuito.

I Koyeb Secrets sono valori a livello di organizzazione, cifrati lato server e assegnati esplicitamente ai servizi. Un servizio può usare un Secret tramite una variabile d’ambiente. Il riuso può semplificare la configurazione del database, ma la disponibilità a livello di organizzazione rende ancora più importante scegliere con attenzione quale servizio riceve ciascun valore. Documentazione dei Secrets

La documentazione di riferimento di Koyeb definisce servizi web e worker. Per cron, prevedi uno scheduler dentro un worker oppure un trigger esterno, e verifica la soluzione durante la prova. Non dare per scontato che la pianificazione di Railway si trasferisca automaticamente, né che questo confronto abbia accertato l’esistenza di un servizio cron nativo equivalente.

Calcola il budget del piano Pro insieme alle risorse consumate da servizi e database. Le risorse di calcolo incluse rendono il prezzo del piano una voce diversa rispetto al container applicativo più piccolo di un altro fornitore. Procurati una stima del carico di lavoro prima di decidere quale destinazione costi meno.

7. Coolify su VPS: quando puoi assumerti la gestione operativa

Coolify è un software di deployment self-hosted che esegue applicazioni e database su server sotto il tuo controllo. Su un VPS, cioè un server virtuale a noleggio, può ricreare un servizio web in container, un worker, Postgres e attività pianificate, senza richiedere una piattaforma applicativa gestita per ogni componente. È quindi utile a un fondatore con competenze tecniche disposto a gestire l’ambiente operativo. Il limite è la responsabilità: eseguire Postgres attraverso una dashboard comoda non lo trasforma in un database gestito dal provider. Scegli Coolify solo quando qualcuno è responsabile di manutenzione del server, backup e ripristino. Documentazione di Coolify

Ideale per: Chi vuole il controllo dei server e accetta il lavoro di manutenzione.
Punto di forza: Flussi di deployment per applicazioni e database sulla propria infrastruttura.
Prezzi: Software self-hosted gratuito, più VPS; un server DigitalOcean di esempio con 4 GiB e 2 vCPU costa $24/mese, esclusi backup e altri servizi. Prezzi di Coolify · Prezzi VPS
Prova gratuita: Il software self-hosted è gratuito; il server non è incluso.

Quel server è un esempio, non una raccomandazione di dimensionamento. Se metti tutto sulla stessa macchina, build, database e richieste dei clienti competono per le medesime risorse. Una build che usa molta memoria può diventare un problema per l’applicazione. Misura il carico di lavoro, lascia un margine operativo e decidi quali componenti collocare altrove.

Coolify gestisce le variabili applicative con impostazioni per build e runtime. La documentazione dei backup indica che credenziali salvate e chiavi private sono cifrate nel database tramite l’APP_KEY dell’istanza. Conserva quella chiave separatamente, oltre a un backup dell’istanza effettivamente ripristinabile: ripristinare il database senza avere la chiave non è un piano di recupero da improvvisare durante un’interruzione. Backup dell’istanza e chiave di cifratura

Le attività pianificate eseguono comandi dentro i container di applicazioni o servizi e dipendono dalla disponibilità dell’applicazione e del server. Lo storage persistente usa i volumi e i mount del server. Sono elementi utili, ma se applicazione, database e unica copia di backup risiedono sullo stesso VPS, tutto dipende da quel server. Conserva il materiale necessario al ripristino in una sede indipendente e prova a ricostruire l’ambiente. Attività pianificate · Storage persistente

8. Netlify: per frontend e componenti serverless

Netlify è una piattaforma di deployment del frontend con funzioni serverless, pertinente quando questa parte può essere separata dal backend a esecuzione continua. Per esempio, puoi spostare il sito di marketing e il frontend lasciando API e worker di coda su Render o Northflank. Netlify ora offre anche Postgres gestito tramite Netlify Database: sarebbe quindi sbagliato affermare che non dispone di Postgres gestito. Resta la differenza nell’esecuzione: le funzioni a durata limitata non diventano un servizio sempre attivo o un consumer di coda continuativo. Scegli Netlify per la parte compatibile con il suo modello a funzioni. Documentazione di Netlify Database

Ideale per: Un frontend separato con funzioni attivate dalle richieste o attività in background a durata limitata.
Punto di forza: Deployment del frontend, funzioni e un’opzione integrata di Postgres gestito.
Prezzi: Ingresso gratuito; Personal da $9/mese, con consumi a crediti. Prezzi attuali
Prova gratuita: È disponibile un piano gratuito; i suoi limiti valgono anche per i carichi di lavoro distribuiti.

Le Netlify Background Functions hanno un limite di esecuzione di 15 minuti. Possono svolgere lavoro asincrono, ma questo limite impedisce di usarle come un consumer di coda in esecuzione indefinita. Le Scheduled Functions possono avviare attività tramite espressioni cron; restano comunque funzioni con vincoli di esecuzione. Un’attività che interroga una coda continuamente richiede un runtime diverso, oppure una riprogettazione esplicita in invocazioni di durata limitata. Background Functions · Scheduled Functions

Conserva i valori sensibili tramite l’interfaccia, la CLI o l’API di Netlify, anziché nella configurazione del repository. La documentazione distingue le variabili conservate sulla piattaforma da quelle in netlify.toml e supporta valori diversi per contesto di deploy, così le anteprime possono usare credenziali differenti. I controlli sugli ambiti e le funzionalità per i segreti dipendono dal piano. Ricorda inoltre che un valore incorporato nel JavaScript inviato al browser è visibile nel browser, indipendentemente da dove la build lo abbia letto. Variabili d’ambiente

Netlify Database può creare, migrare e ramificare database Postgres nel flusso supportato, ma questo non dimostra che estensioni esistenti, requisiti di importazione o architettura dei worker siano compatibili senza modifiche. Netlify Blobs è storage a oggetti, non un filesystem collegato all’applicazione. All’inizio mantieni unito il backend originale se separarlo trasformerebbe una prova di uscita dalla piattaforma in una riscrittura. Documentazione di Blobs

Scopri Netlify se intendi spostare proprio la parte costituita da frontend e funzioni.

Quale alternativa a Railway scegliere per la tua app?

Parti da Render se la priorità è provare la migrazione modificando il meno possibile la separazione tra i processi. Affiancagli Northflank se ambienti riutilizzabili, pipeline o un futuro passaggio al proprio cloud sono requisiti concreti. Per approfondire il confronto con Railway, leggi Railway vs Render.

Scegli Fly.io quando sai spiegare perché ti servono il suo runtime o il controllo sulle regioni. Scegli DigitalOcean App Platform quando l’applicazione considera già temporanei i file locali e la pianificazione è compatibile. Scegli Heroku quando la familiarità con il suo modello operativo riduce il lavoro di migrazione, sostituendo esplicitamente le assunzioni critiche sul comportamento di Scheduler.

Koyeb va considerato tra le opzioni stateless, rispettando l’attuale avvertenza sui volumi. Coolify tra le opzioni da gestire in proprio, con un responsabile identificato. Netlify tra quelle per frontend e serverless, anche se ora offre anche un prodotto di database gestito.

La regola che può cambiare la scelta è semplice: se mantenere un comportamento indispensabile richiede di riprogettare l’applicazione, quell’host non è la riserva che richiede meno lavoro. Può comunque essere la destinazione definitiva giusta, ma includi riscrittura e prove nel costo della migrazione.

Checklist di migrazione: da Railway al passaggio in produzione, dopo le prove

Una seconda piattaforma è pronta quando può recuperare i dati e portare a termine le attività importanti dell’applicazione. Un deployment riuscito è solo il primo controllo. Usa la stessa checklist sia per un trasferimento completo sia per preparare una destinazione da attivare in seguito.

1. 1

   Censisci il sistema in esecuzione

   Per ogni servizio registra revisione del sorgente o immagine, comandi di build e avvio, versione del runtime, controllo di integrità, risorse necessarie, regione e dipendenze. Elenca database, estensioni e ruoli Postgres; directory persistenti; servizi di coda o cache; liste di IP in uscita autorizzati; domini; ogni attività pianificata con il relativo fuso orario. Assegna un responsabile a ciascuna voce.

   Annota che cosa elabora il worker e dove viene conservato lo stato dei job. Un’applicazione descritta come web, Postgres, worker e cron può dipendere anche da un servizio di coda, da un bucket di file o da un provider email. La destinazione deve poter accedere a queste dipendenze anche quando non vengono trasferite.

2. 2

   Esporta la configurazione, poi ruota le credenziali presso chi le ha emesse

   Esporta le variabili in un inventario temporaneo ad accesso limitato. Separa le impostazioni non riservate da credenziali del database, chiavi API, credenziali dei registry, segreti di firma e indirizzi generati dai provider. Registra quali processi usano ciascun valore e se serve durante la build o soltanto a runtime. Non inserire l’esportazione nel controllo di versione, nei ticket o nelle chat.

   Crea credenziali sostitutive presso i provider che le emettono, con permessi e ambiti necessari. Installale nella destinazione prevista e nei carichi di lavoro di origine che devono continuare a funzionare. Verifica gli accessi, revoca tempestivamente i valori sostituiti e controlla i log dei provider. Segui le indicazioni di revoca specifiche dell’incidente se richiedono un intervento più rapido: mettere in sicurezza le credenziali non deve attendere la migrazione della piattaforma.

   Una password del database, una chiave di firma dei webhook e una chiave di cifratura dei dati richiedono procedure di rotazione diverse. Sostituire una chiave di cifratura senza conservare un modo per decifrare i dati esistenti può compromettere il funzionamento dell’app. Tieni traccia della procedura per ogni credenziale, includendo chi la usa fuori da Railway. Copiare una chiave significa esportarla; rendere inutilizzabile quella vecchia significa ruotarla.

3. 3

   Prova dump e ripristino di Postgres

   Crea un database di destinazione vuoto. Prima di trasferire i dati, verifica estensioni supportate, regole di ordinamento, codifica, ruoli e privilegi. Usa un client pg_dump compatibile e ripristina un archivio in formato personalizzato con pg_restore, oppure segui la procedura di importazione supportata dalla destinazione. La guida di Render per Railway offre un flusso concreto per la destinazione.

   Un dump logico è un’istantanea del database, non un flusso di replica continuo. Ripristina una copia di prova, esamina gli errori di ripristino, confronta i conteggi delle tabelle e alcuni record rappresentativi dell’attività, controlla i valori delle sequenze ed esegui consapevolmente le migrazioni dell’applicazione. Prova letture e scritture con le credenziali della destinazione. Ruoli, concessioni di privilegi e altre configurazioni a livello di cluster richiedono una verifica separata.

   Per il trasferimento definitivo, arresta o blocca i processi che scrivono sull’origine ed esegui l’esportazione finale, a meno che tu non disponga di una procedura di replica supportata la cui sincronizzazione finale sia stata provata. Se l’attività non può accettare la finestra di ripristino misurata, progetta la replica prima di fissare la data del passaggio. Non presumere che un dump iniziale riuscito contenga anche gli ordini arrivati dopo.

4. 4

   Trasferisci i volumi e chiarisci chi gestisce i file

   Identifica il contenuto di ogni percorso persistente: upload, documenti generati, stato dell’applicazione o database. Per i file ordinari, copiali nello storage di destinazione, conserva proprietari e permessi necessari e verifica conteggi, dimensioni o checksum. Esegui una sincronizzazione finale dopo l’arresto dei processi che scrivono.

   Per un database, usa la procedura di backup o migrazione supportata, anziché copiare i file di un database in uso come se fossero normali upload. Per i file applicativi condivisi, verifica che ogni processo che li legge possa raggiungere la nuova posizione. Se la destinazione non ha volumi, passare allo storage a oggetti richiede una migrazione di codice e storage, non la semplice modifica di un percorso di mount.

5. 5

   Ricrea la rete privata e le impostazioni dei domini

   Sostituisci i nomi host privati di Railway con gli endpoint interni della destinazione. Verifica che servizio web, worker e attività pianificate possano risolvere i nomi e raggiungere Postgres ed eventuali code. Allinea le impostazioni TLS del database e aggiorna, dove necessario, le liste di IP autorizzati dei provider esterni. Non esporre pubblicamente un database privato solo per mantenere un vecchio schema di connessione.

   Per le prove usa un dominio temporaneo sulla destinazione. Prepara domini personalizzati e certificati, poi controlla callback OAuth, destinazioni dei webhook, origini consentite, domini dei cookie e gli eventuali URL di base dell’applicazione. Riduci in anticipo il tempo di cache DNS se utile al passaggio, tenendo conto dei resolver che conservano i record precedenti.

6. 6

   Esegui le prove limitando gli effetti esterni

   Prova un percorso utente che comprenda accesso, scrittura, attività in coda, attività pianificata e un file o una notifica risultante. Usa account di test per pagamenti ed email oppure disabilita gli effetti esterni. Registra la durata del ripristino e i controlli osservabili che dimostrano che la destinazione è pronta.

   Mantieni inattivi il cron della destinazione e il consumer della coda di produzione finché il lavoro è affidato all’origine. Un ambiente di riserva che invia le stesse fatture o elabora gli stessi job sta già partecipando alla produzione. Rendi sicuri i tentativi di riesecuzione e conserva un registro persistente delle attività completate, così da rilevare le esecuzioni duplicate.

7. 7

   Passa alla nuova piattaforma per fasi, con un solo ambiente autorizzato a scrivere

   Sospendi le pianificazioni e arresta o lascia terminare il lavoro in background secondo il comportamento della coda. Blocca le scritture sull’origine, completa il trasferimento finale del database e la sincronizzazione dei file, quindi verifica la destinazione. Indirizza il traffico alla nuova applicazione e poi attiva esplicitamente il suo worker e le sue pianificazioni.

   Controlla errori applicativi, connessioni al database, tempo di permanenza dei job in coda, completamento delle attività ed effetti esterni. Conserva l’ambiente di origine come opzione di recupero controllata, con i processi di scrittura disabilitati, anziché lasciare entrambi gli ambienti attivi su database che divergono.

   Prima del passaggio, decidi che cosa accadrà se la destinazione accetta nuove scritture e poi si guasta. Riportare il DNS al vecchio database farebbe perdere all’applicazione attiva quelle nuove modifiche. Il recupero potrebbe richiedere la correzione o il ripristino della destinazione, oppure il trasferimento dei nuovi dati all’origine. Definisci questo criterio decisionale prima che arrivi il traffico dei clienti.

La procedura per il database segue la documentazione di PostgreSQL sui dump e la guida di Render alla migrazione da Railway. La sequenza proposta è una raccomandazione operativa: misurala sulla tua applicazione, senza considerarla una garanzia di assenza di interruzioni.

Per un ambiente di riserva, mantieni aggiornato l’inventario, stabilisci quanto debbano essere recenti i dati ripristinati e ripeti le prove quando cambiano applicazione o schema. Un deployment obsoleto senza una procedura di ripristino verificata è una copia del repository, non un sostituto pronto all’uso.

Le scelte da evitare per questa migrazione

Evita Netlify come destinazione senza modifiche per un worker di coda sempre attivo. Usa il suo modello a funzioni dove è adatto, oppure mantieni il worker su una piattaforma per servizi. L’offerta di Postgres gestito non cambia i limiti di esecuzione delle funzioni.

Evita i volumi Koyeb per questa migrazione di produzione finché la documentazione li descrive come adatti solo ai test. Un database esterno o uno storage a oggetti può rendere Koyeb idoneo, ma comporta un’architettura di storage diversa.

Evita DigitalOcean App Platform o Heroku come destinazioni senza modifiche per un’applicazione che dipende da file locali persistenti. Nessuno dei due modelli di runtime conserva quei file come un volume montato in stile Railway. Risolvi prima la dipendenza dallo storage.

Evita Coolify se nessuno è responsabile del server. Il software può semplificare i deployment, ma non elimina una responsabilità operativa rimasta senza titolare.

Infine, evita di scegliere una piattaforma solo perché la sua risorsa più piccola costa poco. Un’API funzionante ma priva di database, consumer di coda e pianificazioni non è il sistema che devi ripristinare.

Domande frequenti sulle alternative a Railway

Quali sono le migliori alternative a Railway?

Per questo stack con servizio web, Postgres, worker e cron, valuta prima Render e affiancagli Northflank. Fly.io è più indicato se vuoi un controllo esplicito sul runtime; Coolify se vuoi gestire i server; Netlify per la parte frontend e per le funzioni a durata limitata. I requisiti di storage dei file o di pianificazione possono cambiare l’ordine.

Esistono alternative gratuite a Railway?

Northflank offre un Sandbox gratuito limitato, mentre Render e Netlify hanno offerte gratuite con perimetri applicativi diversi. Coolify self-hosted è gratuito, ma richiede comunque un server. Nessuna di queste etichette dimostra che l’intero carico di produzione, i backup e le esigenze operative siano coperti senza costi.

Quale alternativa open source a Railway scegliere?

Coolify è l’opzione self-hosted di questo confronto. Usalo se vuoi eseguire container e database sul tuo VPS e puoi assumerti la responsabilità di aggiornamenti, capacità e ripristino. Sostituisce più facilmente l’interfaccia di deployment che le persone incaricate di gestire l’infrastruttura.

Railway vs Render: quando conviene provare Render?

Render è il primo candidato da provare in questo caso perché i suoi componenti web, worker, cron e Postgres gestito corrispondono allo stack indicato. Le restrizioni sui dischi persistenti vanno comunque verificate. Ruota le credenziali secondo le indicazioni di Railway sull’incidente, indipendentemente dalla decisione finale di migrare.