Render hosting o Railway? Prezzi e limiti nel 2026

Nel confronto tra Render hosting e Railway, la scelta dipende soprattutto da come si preferisce pagare: per le risorse effettivamente consumate o per una capacità di calcolo prestabilita. Nell'esempio della piccola app descritto qui sotto, Railway Hobby costa $15.11 al mese e Render Hobby $20, ma Render include il ripristino del database, escluso dalla stima di Railway. Railway è indicato per chi cerca flessibilità nell'uso delle risorse; Render per chi dà più peso a costi prevedibili delle istanze e al ripristino di Postgres già incluso.

Render hosting o Railway: quale scegliere?

Render è la scelta adatta a chi avvia un'attività e vuole un'app sempre attiva, un worker in background e un database Postgres a pagamento con il ripristino già incluso. Un worker è un processo separato che svolge attività come l'invio di email o la generazione di report senza far aspettare chi visita il sito. Su Render si sceglie la capacità di calcolo di ogni servizio: questo rende semplice prevedere la spesa di base.

Railway è adatto a chi vuole ospitare più servizi in modo flessibile ed è disposto a monitorarne i consumi. È una piattaforma di hosting per app che fattura la CPU e la memoria utilizzate dai servizi. La vista grafica del progetto permette di seguire facilmente i collegamenti tra app, worker e database. Un basso consumo di CPU può ridurre i costi anche quando i servizi restano sempre attivi.

Per un piccolo team, il confronto deve includere sia le macchine sia i piani del workspace. Il minimo di Railway Pro comprende il consumo delle risorse; il canone del workspace Render Pro si aggiunge invece ai costi di calcolo. Chi lavora da solo può valutare entrambi i workspace Hobby, ma spendere poco per un deployment non significa avere automaticamente un database pronto per la produzione.

Prezzi e funzionalità verificati il 18 ottobre 2026 sulle pagine dei prezzi e nella documentazione ufficiale dei due fornitori. Il giudizio tiene conto della struttura di fatturazione, delle opzioni di ripristino predefinite, del comportamento dei processi in background e dei controlli di scalabilità. Il conto presentato nell'esempio deriva dalle tariffe dichiarate e da ipotesi esplicite: non è un test di deployment né un benchmark delle prestazioni.

Queste differenze sono documentate nella guida a Postgres di Railway, nella guida al ripristino di Render e nelle regole di scalabilità delle due piattaforme illustrate più avanti.

Prezzi a confronto: la stessa piccola app sulle due piattaforme

Railway costa meno nello scenario con basso utilizzo della CPU; Render permette di conoscere in anticipo il subtotale delle risorse di calcolo. Nessuno dei due risultati rende una piattaforma sempre più conveniente dell'altra. Railway misura i consumi; Render fattura l'istanza scelta per il tempo in cui resta attiva, con addebito proporzionale per i periodi parziali.

L'offerta attuale di Railway comprende Free a $0, Hobby con un minimo mensile di $5, Pro con un minimo di $20 ed Enterprise con prezzi su richiesta. I minimi di Hobby e Pro sono utilizzabili per il consumo delle risorse. Pro include un numero illimitato di utenti nel workspace. Prezzi di Railway.

I piani workspace attuali di Render sono Hobby a $0, Pro a $25 al mese, Scale a $499 ed Enterprise con prezzi su richiesta, con le risorse di calcolo fatturate separatamente. Pro include utenti illimitati: non si paga per singolo sviluppatore. Hobby comprende 5 GB di traffico e Pro 25 GB; oltre queste soglie, il costo è di $0.15 per GB. Prezzi di Render.

Le ipotesi sul carico di lavoro

Immaginiamo una piccola app per le prenotazioni gestita da chi ha avviato l'attività. Comprende un servizio web/API, un worker sempre attivo che elabora i lavori usando il database Postgres esistente e un servizio Postgres a nodo singolo. Una coda che richiedesse una cache separata aggiungerebbe un'altra voce di spesa; questo esempio non la prevede.

Il mese considerato ha 30 giorni, cioè 2,592,000 secondi. Tutti i servizi restano attivi. La memoria media fatturata è di 0.5 GB per il servizio web, 0.5 GB per il worker e 0.25 GB per Postgres: 1.25 GB in totale. L'utilizzo medio effettivo della CPU è rispettivamente di 0.05, 0.05 e 0.02 vCPU: 0.12 vCPU in totale. Una vCPU è un'unità di capacità di elaborazione; una media di 0.12 indica il lavoro svolto dalla CPU nel corso del mese, non una macchina venduta con quella capacità nominale.

Ipotizziamo inoltre 1 GB di spazio occupato sul volume del database per tutto il mese e 1 GB di dati in uscita verso Internet. Le connessioni al database restano sulla rete privata, le build rientrano nelle quote incluse e non ci sono repliche, ambienti di staging, dischi aggiuntivi o nodi ad alta disponibilità. Sono esclusi imposte, registrazione del dominio e costi delle API usate dall'applicazione.

Su Render scegliamo un'istanza web 0.5c-512mb da $7, un worker 0.5c-512mb da $7 e un'istanza Postgres 0.1c-256mb da $6. La pagina dei prezzi indica 1 GB di spazio database incluso e la documentazione sulla creazione consente questa dimensione iniziale. Sono istanze volutamente molto piccole: non significa che siano sufficienti per qualsiasi app in produzione. Prezzi delle risorse di calcolo, configurazione dello spazio database.

Il confronto allinea i componenti dell'app e la domanda ipotizzata, non le prestazioni dell'hardware. Su Railway, memoria e CPU misurate sono le variabili della stima; su Render, le dimensioni delle istanze rappresentano limiti di capacità. Prima di considerarli sufficienti, occorre sottoporre la propria app a un test di carico.

Il calcolo della spesa mensile

Railway pubblica tariffe di $0.00000386 per GB-secondo di memoria, $0.00000772 per vCPU-secondo, $0.00000006 per GB-secondo di spazio su volume e $0.05 per GB di traffico in uscita dai servizi. Moltiplicando queste tariffe esatte per i consumi ipotizzati si ottengono i valori seguenti. Tariffe delle risorse di Railway.

Le tariffe delle risorse provengono da Railway, i prezzi delle istanze e dei workspace da Render, e le regole sui minimi e sui crediti di Railway dalla sua documentazione sui piani. I totali usano valori intermedi non arrotondati. Le tariffe mensili indicative e arrotondate di Railway producono differenze di pochi centesimi; qui il calcolo usa sempre i prezzi al secondo pubblicati, applicati a un mese di 30 giorni.

Quando cambia la piattaforma più conveniente?

In questo confronto tra piani Hobby, Render diventa più economico a circa 0.364 vCPU medie effettivamente utilizzate dai tre servizi nel loro insieme, purché ogni servizio rientri ancora nella capacità dell'istanza Render scelta. Mantenendo invariati memoria, spazio occupato sul volume, traffico e numero di istanze, il costo mensile delle risorse Railway è $12.71192 + $20.01024 × vCPU medie effettivamente utilizzate. Il punto di pareggio si ricava uguagliando questa espressione ai $20 di Render.

A 0.12 vCPU, Railway costa $15.11. A 0.30 costa $18.71; a 0.50, $22.72; a 0.70, $26.72. Render resta a $20 soltanto finché quelle istanze riescono a sostenere il carico. Sono calcoli di sensibilità, non prestazioni misurate né stime delle richieste al secondo.

La memoria può far salire la spesa anche senza un aumento dei visitatori. Un GB medio aggiuntivo per il mese considerato aumenta i costi delle risorse Railway di circa $10.01, prima di considerare l'effetto dei minimi di piano. Un worker in attesa di lavori può continuare a occupare memoria: «inattivo» non significa «gratuito».

Per la prevedibilità vince Render. Se dimensioni e numero delle istanze restano fissi, il subtotale delle risorse di calcolo è noto. Vanno preventivati separatamente il traffico, le build oltre le quote incluse e la crescita dello spazio occupato. Su Railway conviene impostare avvisi di consumo e controllare l'utilizzo reale. Un limite rigido alla spesa per le risorse di calcolo arresta i carichi di lavoro: serve a frenare la spesa, non a gestire traffico illimitato a prezzo fisso.

Piani gratuiti: utili per provare, limitati per questo stack

Render è la scelta migliore per una demo web gratuita; nessuna delle due offerte gratuite è una base solida per l'intero stack in produzione. Render offre 750 ore di istanze web gratuite per workspace ogni mese di calendario, ma un servizio web gratuito entra in sospensione dopo 15 minuti senza traffico in ingresso. Il database Postgres gratuito scade dopo 30 giorni, mentre worker in background e job cron non dispongono di istanze gratuite. Limiti dei servizi gratuiti di Render.

Railway offre attualmente un piano Free continuativo. I nuovi account ricevono un credito di prova una tantum di $5, valido fino a 30 giorni, seguito da $1 di credito gratuito ogni mese. I servizi gratuiti hanno limiti più restrittivi per memoria e volumi e, su questo piano, l'accesso a cron è disponibile soltanto durante la prova. Il credito ricorrente è una piccola quota inclusa, non la promessa di ospitare gratuitamente qualsiasi app composta da tre servizi. Dettagli del piano gratuito di Railway.

Per una demo, la sospensione può essere accettabile. Per un cliente che prenota un appuntamento a pagamento, attendere il risveglio dell'app o trovare un database scaduto è un compromesso inadeguato. La configurazione dei servizi a pagamento va scelta consapevolmente: passare a un workspace Render superiore non aggiorna da solo il piano di calcolo di un servizio gratuito.

Postgres gestito: Render ha il vantaggio del ripristino incluso

Render è indicato per chi vuole il ripristino incluso anche nel piccolo database a pagamento; Railway per chi considera la configurabilità dell'infrastruttura database un vantaggio che giustifica le decisioni aggiuntive. PostgreSQL, comunemente abbreviato in Postgres, è il database relazionale che conserva dati come utenti, ordini e prenotazioni.

Render esegue backup continui delle istanze Postgres a pagamento per consentire il ripristino a un punto nel tempo, cioè il recupero dei dati a un momento precedente. La finestra di ripristino è di 3 giorni sui workspace Hobby e di 7 giorni su Pro e piani superiori. Il ripristino crea un database separato, da verificare prima di modificare la connessione dell'app. Ripristino ed esportazioni su Render.

Il template Postgres attuale di Railway è mantenuto da Railway. La piattaforma offre anche una procedura specifica di conversione all'alta disponibilità e il ripristino opzionale a un punto nel tempo. Definire l'intera offerta «Postgres non gestito» non rende questa distinzione. Tuttavia, modificare l'immagine del template, il comando di avvio o le variabili può riportare la responsabilità della gestione a carico dell'utente. Ambito della gestione Postgres su Railway.

La funzione di ripristino di Railway va attivata. Archivia i dati in un bucket di storage e addebita sia lo spazio dell'archivio sia il traffico in uscita dal database necessario a caricarlo. La documentazione di Postgres descrive una cronologia di ripristino di circa quattro settimane, una volta accumulato l'archivio. Può essere utile, ma configurazione e fatturazione sono diverse dalla finestra di ripristino inclusa in Render. Ripristino a un punto nel tempo su Railway.

Ripristino e failover automatico risolvono problemi diversi

I backup servono quando si perdono dati; l'alta disponibilità serve quando un nodo del database non è disponibile. Se una migrazione errata cancella le prenotazioni, il nodo di riserva può replicare la stessa cancellazione. Occorre poter recuperare uno stato precedente. Se invece il database primario smette di funzionare, il nodo di riserva può subentrare senza dover prima ricostruire il database da un archivio.

La configurazione ad alta disponibilità (HA) di Render richiede un piano di calcolo Postgres con almeno 1 CPU; al nodo di riserva si applicano le stesse tariffe di calcolo e storage del primario. Il database da $6 dell'esempio non soddisfa i requisiti. Requisiti HA di Render.

La conversione all'alta disponibilità (HA) di Railway aggiunge repliche del database, servizi di coordinamento e proxy di connessione. La procedura automatica supporta le immagini Postgres ufficiali di Railway; immagini personalizzate come PostGIS o TimescaleDB non sono compatibili con questo percorso. È un limite rilevante per un'app il cui database dipende da quelle immagini. Prerequisiti HA di Railway.

I piani più piccoli hanno limiti precisi: Railway Hobby consente al massimo 5 GB di spazio sui volumi, mentre l'istanza Postgres di Render usata nel modello dispone di 256 MB di RAM e ha un limite di 100 connessioni. La crescita dei dati o un'app che apre molte connessioni al database possono imporre un'altra configurazione prima che il costo della CPU diventi decisivo. Limiti di Railway, dimensioni dei database Render.

Per chi gestisce l'attività, la domanda concreta è chi si accorgerà di un problema, ripristinerà i dati e verificherà che le prenotazioni siano corrette. Occorre scegliere una configurazione di ripristino che si sappia gestire e provarla prima di archiviare dati insostituibili.

Worker in background e cron: Render offre controlli più espliciti

Render è la scelta più chiara per un team che vuole servizi distinti per web, worker e attività pianificate. I suoi worker in background restano attivi ed elaborano i lavori in coda senza ricevere traffico di rete in ingresso. Anche Railway può eseguire un worker come servizio sempre attivo, senza esporre un endpoint pubblico: per eseguire un processo in background non serve una categoria di prodotto dedicata. Worker di Render, modello dei servizi Railway.

Un worker è adatto alle attività che arrivano durante la giornata, come l'invio di una conferma di prenotazione. Cron, che avvia un comando secondo una pianificazione, serve invece per attività come la generazione di un report notturno. Un worker che controlla continuamente la presenza di nuovi lavori e un'attività pianificata di breve durata consumano risorse in modi diversi: il costo dell'uno non va usato per stimare quello dell'altra.

Railway integra la pianificazione cron nelle impostazioni dei servizi. Le esecuzioni devono essere distanziate di almeno 5 minuti, gli orari sono in UTC e il processo deve terminare una volta concluso il lavoro. Se lascia aperta una connessione al database e resta attivo, Railway salta l'esecuzione successiva. Regole cron di Railway.

Anche Render usa UTC. Rinvia un'esecuzione pianificata finché la precedente resta attiva, interrompe un'esecuzione dopo 12 ore e applica un minimo mensile di $1 per servizio cron, con risorse di calcolo fatturate al secondo. L'avvio manuale di un'esecuzione annulla prima quella in corso. Comportamento dei cron di Render.

La differenza tra saltare e rinviare un'esecuzione conta, per esempio, in una riconciliazione notturna. Occorre fare in modo che le attività possano essere ritentate senza effetti indesiderati, registrarne il completamento e impostare avvisi se manca il risultato atteso. La piattaforma di hosting può avviare il comando; l'app deve comunque sapere se l'attività aziendale è stata completata.

Non bisogna presumere che l'impostazione opzionale Serverless di Railway metta in sospensione un worker che elabora una coda. Le connessioni al database e altro traffico in uscita possono impedire la sospensione; inoltre, il risveglio di un servizio sospeso comporta un cold start. Un processo che continua a controllare la coda può restare attivo. Comportamento di Railway Serverless.

Regioni e scalabilità: la scelta dipende dai vincoli

Railway è in vantaggio per distribuire le repliche di un servizio tra più regioni; Render per regolare automaticamente il numero di repliche in base a obiettivi di CPU o memoria. Scalare verticalmente significa assegnare più risorse a un'istanza. Scalare orizzontalmente significa eseguire più istanze. Sono risposte a colli di bottiglia diversi.

Railway aumenta automaticamente l'uso delle risorse fino ai limiti configurati, mentre il numero di repliche orizzontali va impostato manualmente. Le repliche distribuite in più regioni instradano il traffico pubblico verso la regione più vicina. Su Render occorre scegliere un piano di calcolo superiore per assegnare più risorse a ogni istanza; i workspace Pro e superiori possono modificare automaticamente il numero di istanze in base a obiettivi di CPU o memoria. Scalabilità di Railway, scalabilità di Render.

Railway elenca California, Virginia, Amsterdam e Singapore. Render elenca Oregon, Ohio, Virginia, Francoforte e Singapore. La scelta va fatta in base alla posizione degli utenti e a dove devono risiedere i dati, senza affermare, in assenza di prove, che un fornitore sia sempre più veloce. Regioni di Railway, regioni di Render.

Per una piccola app, conviene iniziare collocando API, worker e database nella stessa regione. Distribuire l'API non distribuisce automaticamente le scritture del database, e più località geografiche non rendono automaticamente più veloce una richiesta che dipende molto dal database.

Esistono vincoli concreti. Le reti private di Render sono regionali e un servizio o database esistente non può semplicemente cambiare regione: bisogna crearne uno sostitutivo e migrare. Railway consente di cambiare regione, ma spostare un servizio con un volume collegato richiede la migrazione del volume e un periodo di indisponibilità. Su Render, collegare un disco persistente impedisce di scalare quel servizio su più istanze. Sono aspetti da valutare prima di salvare sul disco locale dell'app i file caricati dai clienti.

Cambiare piattaforma: migrare dati e procedure operative

Il passaggio ha senso quando lo giustificano un limite verificato o un costo ricorrente, non perché l'altra dashboard sembra più semplice. La vista grafica di Railway si presta a chi vuole collegare visivamente i servizi. I tipi di servizio e i Blueprints di Render sono adatti a un team che cerca configurazioni dell'infrastruttura ripetibili. Entrambe le piattaforme consentono deployment da repository o immagini container, facilitando la portabilità dell'app; database e assetto operativo richiedono comunque una migrazione pianificata. Guida alla migrazione di Render, guida alla migrazione di Railway.

1. 1

   Fare l'inventario dei servizi attivi

   Elencare il comando di avvio del servizio web, quello del worker, la pianificazione cron, le variabili d'ambiente, i segreti, le estensioni del database, lo storage e i domini. Individuare le attività che non devono essere eseguite due volte durante il passaggio.

2. 2

   Provare la migrazione del database

   Creare il database di destinazione e testare esportazione e ripristino. Verificare la compatibilità dello schema, le estensioni richieste, il numero di record e le query importanti per l'app. Tenere le credenziali fuori dal controllo di versione.

3. 3

   Pianificare la gestione delle ultime scritture

   Stabilire come fermare o sincronizzare le scritture durante il trasferimento finale. Sospendere attività pianificate e worker quando necessario, per evitare che entrambe le piattaforme inviino la stessa conferma o elaborino lo stesso addebito.

4. 4

   Effettuare il passaggio e verificarlo

   Aggiornare stringhe di connessione e domini, provare un flusso reale dell'applicazione e verificare le attività in background e le impostazioni di ripristino. Prima di dismettere i vecchi servizi, mantenere un piano di ritorno alla configurazione precedente che tenga conto delle nuove scritture sulla destinazione.

Il piccolo risparmio sui piani Hobby di questo esempio non basta a giustificare la migrazione di un'app che funziona bene: prima vanno stimati il lavoro necessario e i costi temporanei dei servizi attivi su entrambe le piattaforme. Se i dati dei clienti richiedono il failover automatico, occorre confrontare prima le configurazioni database più complete. Il conto di base di tre servizi non può risolvere quella scelta.

Vercel è più adatto quando il progetto ruota attorno a un frontend Next.js con anteprime integrate per le pull request. La sua documentazione sul deployment di Next.js descrive questo flusso di lavoro; il nostro confronto Vercel vs Netlify e la guida ai prezzi di Vercel approfondiscono queste alternative.

Fly.io è più adatto a chi cerca un controllo diretto sul ciclo di vita delle macchine virtuali, sulle risorse e sulla collocazione geografica. La sua documentazione di Machines illustra questi controlli.

Render vs Railway: il criterio per decidere

Conviene partire da Render se il ripristino di Postgres incluso e un budget di calcolo basato sulle istanze sono le ragioni principali per cui si vuole evitare la gestione dei server. Conviene partire da Railway se contano di più la flessibilità nel combinare i servizi e la fatturazione a consumo. Railway è un'alternativa credibile a Render per un'app composta da più servizi, ma sceglierlo significa assumersi la responsabilità delle ipotesi sui consumi e della configurazione del ripristino.

La prossima settimana, il passo concreto è confrontare le esigenze reali di web, worker e database con l'esempio. Sostituire le ipotesi su memoria, CPU e traffico in uscita con misurazioni di un carico rappresentativo, aggiungere le opzioni di ripristino necessarie e confrontare i totali dell'intero workspace. Se l'app funziona già bene su una delle due piattaforme, la migrazione va trattata come un progetto aziendale con un costo, non come un miglioramento automatico.

Domande frequenti

Railway vs Render: cosa includono i piani gratuiti?

I servizi web gratuiti di Render entrano in sospensione dopo 15 minuti di inattività e il suo Postgres gratuito scade dopo 30 giorni. Railway offre una prova iniziale da $5, seguita da $1 di credito gratuito al mese. Nessuna delle due piattaforme mette a disposizione risorse gratuite illimitate per l'intero stack sempre attivo di web, worker e database.

Quanto costano Railway e Render?

Nel modello esplicito della piccola app, la spesa è di $15.11 su Railway Hobby contro $20 su Render Hobby, oppure $20 contro $45 con i rispettivi workspace Pro. Sono scenari calcolati, non prezzi validi per qualsiasi app. Gli archivi di ripristino di Railway sono esclusi; il ripristino del database a pagamento di Render è incluso.

Per un backend è meglio Railway o Render?

Entrambe le piattaforme possono ospitare un'API, processi in background e Postgres. Render è indicato per il ripristino incluso dei database a pagamento e la scalabilità orizzontale automatica su Pro in base a obiettivi di utilizzo; Railway per la fatturazione a consumo, la vista grafica dei servizi collegati e le repliche in più regioni. Prima di scegliere la conversione HA automatica di Railway, va verificata la compatibilità dell'immagine del database.