Deploy per solo founder: Cloudflare, Vercel o Railway

"I limiti ufficiali di Cloudflare Pages indicano build, concorrenza, file, dimensione degli asset, domini e l’uso delle quote Workers da parte di Pages Functions."
La dashboard di deploy mostra quattro servizi: blog, tool-api, dashboard e worker-daily-report. I primi due girano su Cloudflare, il terzo su Vercel e l’ultimo è ancora diviso tra Railway e Workers. Ognuno incontra un limite diverso: build, CPU di Workers, fattura Vercel o scelta tra container e function.
Un’attività gestita da una persona combina spesso sito di contenuti, tool, dashboard SaaS e task pianificati. Il confronto utile non cerca un vincitore, ma il runtime adatto a ogni servizio e le relative soglie di costo e manutenzione.
1. Quattro servizi, quattro limiti diversi
blog è un sito Astro statico su Cloudflare Pages. Modifiche a contenuti, stile o configurazione avviano build e avvicinano il progetto ai 500 mensili del piano Free. I 20.000 file non sono ancora un problema, ma commenti e ricerca tramite Pages Functions consumano quote Workers.
tool-api è una API leggera su Workers per login e persistenza. Con più traffico, 100.000 richieste al giorno possono non bastare e le richieste intensive possono superare 10 ms di CPU. Workers Paid parte da 5 dollari al mese, con richieste e CPU separate dall’hosting statico.
dashboard è una app Next.js full-stack su Vercel. Le preview sono comode, ma la pagina usage separa Functions, Images, Builds, Analytics e altri prodotti. Ogni seat a pagamento aggiuntivo costa 20 dollari al mese. Hobby include 4 ore di Active CPU, 360 GB-hours di memoria provisioned e 1 milione di invocazioni.
worker-daily-report genera e invia un report quotidiano. Workers esegue codice pianificato, ma un job lungo o pesante può non rientrare nei limiti CPU e memoria. Railway esegue un processo Node, ma richiede il controllo di RAM, CPU, egress e volumi. Hobby costa 5 dollari e include 5 dollari di utilizzo.
La regola comune è separare in base alla forma del workload. Contenuti statici, funzioni leggere, applicazioni complete e job lunghi non devono stare sullo stesso provider.
2. I limiti principali delle quattro piattaforme
2.1 Cloudflare Pages: asset statici gratuiti, funzioni nelle quote Workers
Cloudflare Pages serve soprattutto per hosting e distribuzione globale di asset statici. Gli attuali limiti Free comprendono:
- 500 build al mese; push Git e build manuali consumano la quota.
- 20.000 file per sito; monitora progetti con molte immagini o pagine generate.
- 25 MiB per asset; video e file di dati grandi vanno in object storage.
- 100 custom domain per progetto nel piano Free.
- Timeout del build di 20 minuti.
Richieste e CPU di Pages Functions contano in Workers, non nella quota statica Pages:
- Gli asset statici vengono distribuiti entro i limiti Pages.
- Commenti, ricerca e proxy API usano quote e prezzi Workers.
- Astro e Hugo si adattano bene; per Next.js verifica adapter e runtime attuali.
Pages è un buon inizio per siti di contenuti e tool statici. Molte richieste dinamiche o calcoli complessi vanno stimati come workload Workers separato.
2.2 Cloudflare Workers: funzioni leggere con limiti di richieste e CPU
Workers è il runtime Cloudflare per API leggere, logica edge e backend di tool. I limiti attuali includono:
- 100.000 richieste al giorno nel piano Free.
- 10 ms di CPU per richiesta HTTP nel Free; l’attesa di I/O di rete non consuma CPU.
- Subscription Workers Paid da 5 dollari al mese.
- 10 milioni di richieste mensili incluse nello Standard.
- 30 milioni di millisecondi CPU mensili inclusi.
- 128 MB di memoria per isolate in Free e Paid.
Utilizzi adatti:
- API leggere per autenticazione, query e logica semplice.
- Pages Functions per commenti e ricerca.
- Proxy API con cache, routing e autorizzazione.
Utilizzi non adatti:
- Report lunghi e processing batch.
- Calcoli pesanti, grandi dati in memoria o inferenza ML.
- Connection pool tradizionali non compatibili con isolate.
Workers è adatto al backend di un piccolo tool. Pianifica la crescita in richieste e CPU; processi persistenti e job pesanti richiedono un altro runtime.
2.3 Vercel: ottimo per Next.js, ma la fattura non è solo un seat
Vercel integra Next.js e preview deployments. Hobby include risorse Function, mentre gli altri utilizzi sono separati:
- 4 ore di Active CPU.
- 360 GB-hours di Provisioned Memory.
- 1 milione di invocazioni Function.
- 0,0035 dollari per minuto CPU di build con on-demand concurrency o Elastic build machines.
- 20 dollari al mese per ogni seat a pagamento aggiuntivo.
- 100 deployments al giorno in Free e 6.000 in Pro.
- 5.000 uploads al giorno in Free e 40.000 in Pro.
La fattura può contenere più categorie:
- Functions: CPU, memoria e invocazioni.
- Images: trasformazioni, cache reads e cache writes.
- Builds: CPU con configurazioni fatturabili.
- Analytics: Web Analytics e Speed Insights.
- Observability: monitoraggio a eventi e add-on.
Segnali di attenzione:
- Molte preview aumentano build e deployments; machine o concurrency fatturabili aggiungono costo.
- Image Optimization ha proprie quote incluse e tariffe on-demand.
- Analytics e Observability vanno controllati separatamente.
Vercel è un buon punto di partenza per un prodotto Next.js full-stack, ma il piano non equivale alla fattura totale. Controlla ogni categoria e seat.
2.4 Railway: runtime container con fatturazione a risorse
Railway è un PaaS per servizi, worker e database. Subscription e risorse sono fatturate separatamente:
- Hobby costa 5 dollari e Pro 20 dollari al mese.
- Hobby include 5 dollari di utilizzo.
- Pro include 20 dollari di utilizzo.
- RAM costa 10 dollari per GB-mese.
- CPU costa 20 dollari per vCPU-mese.
- Network egress costa 0,05 dollari per GB.
- Volume storage costa 0,15 dollari per GB-mese.
- Free consente di default 0,5 GB RAM, 1 vCPU e volume da 0,5 GB per servizio.
Restano decisioni operative:
- Monitorare RAM, CPU, egress e volumi reali.
- Configurare alert di risorse e log.
- Conoscere la finestra di image retention per rollback e rebuild.
- Definire health check, restart e backup.
Soglie di costo:
- L’utilizzo oltre il credito di 5 o 20 dollari viene fatturato come differenza.
- Un servizio attivo continua a consumare RAM, CPU e storage.
- Egress e volumi persistenti crescono indipendentemente.
Railway è adatto a servizi Node, task in background e database. Riduce il lavoro infrastrutturale, non la responsabilità del servizio.
3. Tabella decisionale per tipo di workload
3.1 Siti di contenuti e documentazione
Un sito di contenuti usa soprattutto asset statici con poche funzioni dinamiche.
| Workload | Punto di partenza | Soglia principale |
|---|---|---|
| Sito Astro o Hugo statico | Cloudflare Pages | 500 build/mese, 20.000 file |
| Next.js SSG | Cloudflare Pages o Vercel | adapter, tempo e configurazione del build |
| Commenti o ricerca | Pages Functions | richieste e CPU contano in Workers |
Per Astro o Hugo, Pages offre distribuzione globale e limiti sufficienti all’inizio. Consulta la guida a Cloudflare Pages e i limiti Cloudflare Free.
Per Next.js SSG verifica il supporto attuale invece di ripetere una vecchia affermazione. Vercel offre il workflow nativo; Cloudflare resta interessante per output soprattutto statico.
Commenti e ricerca possono usare Pages Functions, ma richieste e CPU appartengono a Workers. Separa distribuzione statica ed esecuzione dinamica.
3.2 Tool statici e dinamici
Un generatore o converter può funzionare nel browser; login e dati persistenti lo rendono un prodotto dinamico.
| Workload | Punto di partenza | Soglia principale |
|---|---|---|
| Tool solo browser | Cloudflare Pages | build e file |
| API dinamica leggera | Cloudflare Workers | 100.000 richieste/giorno, 10 ms CPU nel Free |
| Tool Next.js full-stack | Vercel | Functions, Images, Builds, Observability |
Un tool nel browser si adatta a Pages. Una piccola API si adatta a Workers se le richieste restano leggere e compatibili con isolate.
Un tool Next.js full-stack sfrutta Vercel, ma preview, immagini, runtime Function e monitoring richiedono budget separati.
3.3 Dashboard SaaS
Una dashboard SaaS richiede logica applicativa, autorizzazione, accesso ai dati e spesso collaborazione.
| Workload | Punto di partenza | Soglia principale |
|---|---|---|
| Next.js full-stack | Vercel | Functions, Images, Builds, Analytics |
| Altro framework | Workers o Vercel | supporto attuale di framework e runtime |
| Collaborazione | Vercel o Railway | seat, permessi, piano |
Vercel è il punto di partenza diretto per Next.js. Controlla Functions, Images, preview Builds, Analytics, Observability e seat senza considerare Pro tutto incluso. Il confronto prezzi Cloudflare offre altro contesto.
Per altri framework confronta adapter e feature runtime attuali. Workers favorisce logica edge; Vercel i framework serverless supportati.
Il database è una decisione separata. Supabase, Postgres gestito, D1 e Railway Volumes hanno limiti propri di costo e affidabilità.
3.4 Job lunghi e servizi container
Report, file, consumer di code e API persistenti richiedono un runtime diverso da una function breve.
| Workload | Punto di partenza | Soglia principale |
|---|---|---|
| Servizio Node o worker | Railway | RAM, CPU, egress, volume |
| Database | Railway o servizio gestito | costo del volume, backup |
| Task in background | Railway | alert di utilizzo, restart |
Railway esegue processi Node persistenti in un runtime completo. In cambio gestisci limiti, log, health check, restart e backup.
Un Railway Volume mantiene i dati, ma il prezzo non sostituisce una strategia database. Servono backup e test di ripristino.
Per task pianificati definisci alert e profilo massimo di risorse. Un worker permanente o intensivo può superare il credito Hobby.
4. Modelli di costo e soglie di attenzione
4.1 Modello Cloudflare
Cloudflare separa distribuzione statica Pages ed esecuzione dinamica Workers.
Asset statici Pages:
- Sono distribuiti senza costo di trasferimento a consumo entro i limiti Pages.
- Vicino a 500 build mensili riduci i deployment non necessari.
- Vicino a 20.000 file sposta asset grandi in object storage.
- Pages Functions usa quote Workers, non una quota dinamica illimitata separata.
Esecuzione Workers:
- Free include 100.000 richieste/giorno e 10 ms CPU per richiesta HTTP.
- Workers Paid parte da una subscription mensile di 5 dollari.
- Standard include 10 milioni di richieste al mese.
- Standard include 30 milioni di millisecondi CPU al mese.
Soglie:
- I limiti rigidi Pages possono bloccare nuovi build.
- Più richieste o CPU richiedono il passaggio da Workers Free a Paid.
- Pages statico gratuito non significa Pages Functions illimitato.
Un inizio comune combina Pages e Workers Free. Definisci il passaggio a Paid prima che traffico o CPU lo impongano.
4.2 Modello Vercel
Vercel separa più risorse infrastrutturali e di developer experience.
Risorse Function di Hobby:
- 4 ore di Active CPU.
- 360 GB-hours di Provisioned Memory.
- 1 milione di invocazioni.
- 0,0035 dollari per minuto CPU con on-demand concurrency o Elastic build machines.
Categorie d’uso:
- Functions: Active CPU, memoria provisioned e invocazioni.
- Images: trasformazioni, cache reads e cache writes.
- Builds: preview e production con configurazioni fatturabili.
- Analytics: Web Analytics e Speed Insights.
- Observability: eventi e monitoring.
Seat:
- Ogni seat a pagamento aggiuntivo costa 20 dollari al mese.
- Il seat non assorbe eccedenze infrastrutturali o add-on.
Soglie:
- Preview frequenti aumentano build e deployments.
- Le immagini hanno quote e prezzi propri.
- Analytics e Observability si controllano separatamente.
- CPU, memoria e invocazioni vanno confrontati con il piano attuale.
Leggi la pagina usage per categoria. Risparmiare tempo con Next.js può coesistere con una fattura a più voci.
4.3 Modello Railway
Railway combina subscription e risorse misurate.
Piani e uso incluso:
- Hobby costa 5 dollari e include 5 dollari di utilizzo.
- Pro costa 20 dollari e include 20 dollari di utilizzo.
- Free offre fino a 0,5 GB RAM, 1 vCPU, volume da 0,5 GB e un piccolo credito mensile.
Tariffe:
- RAM: 10 dollari per GB-mese.
- CPU: 20 dollari per vCPU-mese.
- Network egress: 0,05 dollari per GB.
- Volume storage: 0,15 dollari per GB-mese.
- Le immagini eliminate restano disponibili solo nella retention del piano.
Soglie:
- L’uso oltre il credito viene fatturato come differenza.
- Un servizio non fermato continua a consumare RAM, CPU e storage.
- Egress e volumi possono crescere separatamente dalla subscription.
Railway riduce la configurazione VPS, non il monitoraggio. Configura alert e conosci la finestra di rollback prima della produzione.
5. Manutenzione: frequenza, log, rollback e collaborazione
Le quote di build e deployment contano nei progetti modificati spesso. La collaborazione aggiunge seat e permessi.
Frequenza di deployment e build
- Cloudflare Pages Free consente 500 build mensili e uno simultaneo; i preview build via Git consumano la quota.
- Vercel consente 100 deployments/giorno nel Free e 6.000 nel Pro; molte preview aumentano anche i build.
- Railway non pubblica qui un contatore equivalente, ma le immagini eliminate restano disponibili solo nella finestra di rollback del piano.
Monitora build Pages e deployments Vercel prima che fermino le iterazioni. Verifica inoltre se machine o concurrency Vercel sono fatturabili.
Log, rollback e accesso del team
- Cloudflare Pages offre build log, cronologia e rollback; verifica le condizioni attuali di account e permessi.
- Vercel offre preview, cronologia, log, Analytics e seat pagati; ogni seat aggiuntivo costa 20 dollari al mese.
- Railway offre log e metriche; health check, restart, backup e collaborazione vanno configurati esplicitamente.
Scegli il workflow che elimina più lavoro ripetitivo sul servizio principale. In Next.js contano le preview; in un sito di contenuti, build statici prevedibili.
6. Prossimo passo: database, storage e CI/CD
La piattaforma di deploy è solo un livello. Database, storage, CI/CD, monitoring e alert richiedono decisioni proprie. Il prossimo articolo confronta Supabase, Postgres, Railway Volumes e object storage.
L’obiettivo non è ridurre il numero di provider, ma collocare ogni workload in un runtime con limiti, fattura e responsabilità chiari prima della crescita.
Scegliere il primo percorso di deploy per un’attività individuale
Filtra Cloudflare Pages, Workers, Vercel e Railway in base a runtime, limiti, fatturazione e responsabilità operativa.
- 1
Step 1: Elencare tutti i servizi
Annota sito di contenuti, frontend del tool, API, dashboard Next.js, Cron, worker e database senza raggrupparli per fornitore. - 2
Step 2: Classificare i runtime
Segna ogni servizio come static, function, app, worker o database e indica se richiede processo persistente, runtime completo o file locali. - 3
Step 3: Associare una piattaforma iniziale
Parti da Pages per il statico, Workers per edge leggero, Vercel per Next.js e Railway per container o job lunghi. - 4
Step 4: Verificare i limiti
Controlla nella documentazione ufficiale aggiornata build, file, CPU, memoria, frequenza di deploy, tetti delle risorse e compatibilità. - 5
Step 5: Separare le voci di costo
Stima Functions, Builds, Images, log, seat, RAM, CPU, egress e volumi separatamente; il prezzo del piano non è il costo totale. - 6
Step 6: Definire quando separare
Scrivi le condizioni per aggiungere una seconda piattaforma: limite CPU, processo persistente, troppi build o budget superato.
FAQ
Cloudflare Pages è adatto al deploy di un SaaS?
Per Next.js è meglio Vercel o Cloudflare?
Railway è adatto al backend e ai worker di un solo founder?
Cloudflare Pages non è più consigliato?
Sito, tool e dashboard devono stare sulla stessa piattaforma?
Perché la fattura Vercel può salire all’improvviso?
Railway Hobby da 5 dollari è gratuito?
11 min di lettura · Pubblicato il: 9 ott 2026
Guida allo stack tecnico per solo founder
Se arrivi dalla ricerca, il modo più veloce per orientarti è passare all’articolo precedente o successivo della stessa serie.
Precedente
Stack backend per un fondatore solitario: Cloudflare Workers, Supabase, Node.js e database
Assegna API, webhook, autenticazione, dati, file e attività lunghe a Workers, Supabase o Node.js in base a limiti e segnali di evoluzione.
Parte 6 di 8
Successivo
Scegliere il database da soli: D1, Postgres, R2, S3 o SQLite
Classifica dati di business, eventi, file, cache, dati locali e backup, poi scegli D1, Postgres, R2, S3 o SQLite in base a costi e segnali di migrazione.
Parte 8 di 8



Commenti
Accedi con GitHub per lasciare un commento