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 as-needed, distribuito su edge globale, con scaling automatico integrato. Non esiste il concetto di "server che cade sotto carico": ogni richiesta gira in un isolate separato, il costo scala con l'uso reale, non con una capacità prenotata in anticipo.
- D1 è un database SQLite distribuito, pensato per vivere accanto ai Worker senza la latenza di un database esterno raggiunto via rete tradizionale. Per la maggior parte dei progetti indie — CMS, SaaS piccoli, blog come questo — è più che sufficiente, ed è gratuito fino a soglie generose.
- R2 sostituisce lo storage a oggetti classico (tipo S3) ma senza costi di egress, che su AWS possono diventare la voce di spesa più dolorosa quando un progetto cresce.
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.
Cosa perdi, per onestà
Non è tutto oro. Workers ha dei limiti di runtime (niente processi long-running, niente filesystem persistente locale) che per certi carichi di lavoro — job batch pesanti, elaborazione video, alcuni tipi di AI training — restano un vincolo reale. Il debug a volte è meno immediato che su un server dove puoi entrare in SSH e guardare i log in tempo reale. E il lock-in verso l'ecosistema Cloudflare è un fattore da considerare 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.
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 bolletta salata per un server tenuto acceso 24/7 all'80% inutilizzato. 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. Per un progetto indie nel 2026, i VPS tradizionali restano validi per casi specifici, ma come scelta di default hanno smesso di essere la strada più naturale.
