Per anni la domanda "come deployo questo progetto?" aveva una sola risposta ragionevole: un VPS. DigitalOcean, Hetzner, una VM su qualche provider, un po' di Nginx, un processo Node tenuto in vita da PM2, magari Docker per sentirsi più moderni. Funzionava, ma per un progetto indie o un side project era anche un secondo lavoro: patch di sicurezza, monitoraggio, backup, scaling manuale quando il traffico saliva.
Da quando ho spostato buona parte dei miei progetti su Cloudflare Workers, D1 e R2, quella domanda ha smesso di avere senso per la maggior parte dei casi in cui mi imbatto.
Il problema reale dei VPS per un indie dev
Un VPS non è complicato di per sé. È il mantenimento nel tempo che pesa. Se lavori da solo, o in un team piccolissimo, ogni ora spesa a tenere in piedi l'infrastruttura è un'ora sottratta al prodotto. E c'è un problema più sottile: un VPS ha una capacità fissa. Se il progetto esplode di traffico — magari finisce su Hacker News o TikTok — o scali manualmente in tempo reale, o il sito va giù nel momento peggiore possibile.
Per un progetto indie, dove spesso non sai in anticipo se avrai dieci utenti o diecimila, questo è esattamente il tipo di rischio che non ti puoi permettere di gestire a mano.
Cosa cambia con Workers, D1 e R2
Lo stack Cloudflare risolve il problema alla radice, non ottimizzandolo ma eliminandolo:
- Workers eseguono il codice su richiesta, sulla rete globale di Cloudflare, con scaling automatico. Non c'è una macchina da dimensionare: ogni richiesta gira in un isolate separato e il costo segue l'uso reale, non una capacità prenotata. Sul piano Free hai 100.000 richieste al giorno e 10 ms di CPU per invocazione; il piano Paid parte da 5 dollari al mese con 10 milioni di richieste incluse e nessun costo di egress (prezzi e limiti ufficiali, controllati il 17 ottobre 2026).
- D1 è un database SQLite gestito, serverless, collegato al Worker con un binding: niente connection string, niente server di database da tenere acceso. Per la maggior parte dei progetti indie (CMS, SaaS piccoli, blog come questo) basta, e il piano Free è largo: 5 milioni di righe lette e 100.000 scritte al giorno, 5 GB di storage in totale e 500 MB per database (prezzi D1, limiti D1). Sul Paid un singolo database arriva a 10 GB. Se ti stai chiedendo se SQLite regge, c'è il confronto SQLite vs Postgres; se ci metti sopra un ORM, Drizzle vs Prisma con D1.
- R2 fa da storage a oggetti compatibile con S3, ma l'egress verso Internet è gratuito per ogni classe di storage: su altri provider è spesso la voce che cresce di più quando un progetto prende traffico. Il free tier include 10 GB-mese di storage, 1 milione di operazioni di classe A e 10 milioni di classe B al mese (prezzi R2).
La parte che cambia davvero il modo di lavorare è che questi tre pezzi comunicano nativamente tra loro, nello stesso ecosistema, senza dover orchestrare credenziali, VPC, firewall o reti private tra servizi diversi.
Per il deploy, Cloudflare sta spostando la CLI da Wrangler a cf: ne ho scritto in cosa cambia per deploy e agenti. Se sopra questo stack ci metti agenti che devono cercare sul web, c'è anche la nuova Web Search API.
Se il sito oggi sta su Pages, il passaggio a Workers con gli Static Assets l'ho raccontato in migrare un sito Astro da Pages a Workers. E se l'app chiama modelli LLM, metti davanti AI Gateway per avere log, cache e un tetto di spesa.
Cosa perdi, per onestà
Non è tutto oro. Workers ha limiti di runtime precisi: 10 ms di CPU per richiesta sul Free, 30 secondi di default sul Paid (alzabili fino a 5 minuti), 128 MB di memoria per isolate e nessun filesystem persistente (limiti Workers). Per job batch pesanti, elaborazione video o processi che devono restare accesi sono un vincolo reale. Il debug a volte è meno immediato che su un server dove entri in SSH e guardi i log. E il lock-in verso l'ecosistema Cloudflare va messo in conto se un giorno vuoi portarti via tutto.
Per il tipo di progetti che costruisco — API, SaaS, CMS, blog, strumenti interni — questi limiti quasi mai si toccano davvero.
Due cose però non spariscono. I backup restano una tua responsabilità, anche se D1 ti dà Time Travel (7 giorni sul Free, 30 sul Paid) e l'export: cosa coprono e cosa resta da fare è in backup di D1. E il conto vero non è il prezzo di partenza ma quanto costa andarsene tra un anno. Nel confronto Vercel vs Cloudflare vs VPS il VPS resta la scelta giusta se hai processi lunghi, worker in background, WebSocket persistenti o vuoi il database sullo stesso disco.
Il punto per chi costruisce da solo
Il vantaggio più grande di questo stack, per un indie dev, non è tecnico in senso stretto: è che riduce drasticamente il tempo dedicato a cose che non sono il prodotto. Niente patch di sistema operativo, niente capacity planning, niente server tenuto acceso 24/7 anche quando nessuno lo usa. Il piano gratuito di Workers, D1 e R2 copre comodamente la fase in cui un progetto sta ancora cercando la sua validazione — e quando cresce, cresce insieme al progetto, non prima.
È lo stesso motivo per cui ho scelto EmDash per questo blog: strumenti pensati per chi costruisce senza un team infrastrutturale alle spalle, dove il default è già quello giusto. Quindi non dico che il VPS sia finito: dico che per un progetto indie non è più il punto di partenza automatico. Parto da Workers, D1 e R2 e passo a un VPS quando il progetto ha bisogno di qualcosa che questo stack non dà.
