Vercel vs Cloudflare vs VPS per un prodotto indie: il vincolo è il lock-in, non il prezzo di partenza

Questo confronto è per chi sta per mettere online un prodotto piccolo, spesso un'app Next.js, e deve decidere dove ospitarlo. Vive nell'hub Vibe coding e completa due pezzi già usciti: Workers, D1 e R2 al posto del VPS e SQLite vs Postgres.

In breve: Vercel, Cloudflare e un VPS costano più o meno uguale il primo mese, quindi il prezzo di partenza non decide niente. Decide quanto ti costa andartene tra un anno. Su un VPS te ne vai con un'immagine Docker. Su Vercel e Cloudflare il codice del framework si porta via, ma i servizi della piattaforma che hai collegato no. Scegli guardando quelli, non il listino.

La domanda sbagliata e quella giusta

Non "quale costa meno?". È: cosa dovrò riscrivere se tra dodici mesi voglio spostarmi?

Il prezzo d'ingresso è quasi sempre zero o una cifra simbolica. Il costo vero arriva dopo, in due forme. La prima è la bolletta quando il traffico cresce in un modo che non avevi previsto. La seconda è il lavoro per migrare quando la piattaforma non ti va più bene. La seconda è quella che si sottovaluta, perché all'inizio non si vede.

Cosa dicono davvero i listini

Tre punti di partenza, presi dalle pagine ufficiali il 9 ottobre 2026. Prezzi in dollari, IVA esclusa.

La riga che pesa di più per un prodotto indie è la prima. Le linee guida di fair use di Vercel dicono che Hobby è solo per uso personale e non commerciale. Se il sito accetta pagamenti, vende un servizio o mostra pubblicità, serve il Pro. Per un prodotto che vuole incassare, quindi, il "gratis" di Vercel non esiste: si parte da 20 dollari al mese.

Su Cloudflare il conto è diverso. Il listino di Workers parte da 5 dollari al mese per account, con 10 milioni di richieste e 30 milioni di millisecondi di CPU inclusi. Le richieste agli asset statici sono gratuite e illimitate, e non c'è costo per il traffico in uscita.

Sul VPS non metto cifre. La pagina dei piani Hetzner carica i prezzi solo nel browser e, quando l'ho controllata, segnava la linea più economica come non disponibile. Il dato utile è la forma del prezzo: una tariffa mensile con tetto, 2 vCPU e 4 GB di RAM nel taglio base, 20 TB di traffico inclusi nelle sedi europee.

Il costo che non vedi: uscire

Lock-in è il costo, in lavoro e in rischio, di spostare un prodotto da una piattaforma a un'altra. Qui le tre opzioni si separano davvero. Conviene guardare due strati diversi: il framework e i servizi della piattaforma.

Il framework si porta via quasi sempre

Next.js oggi si può deployare in quattro modi: server Node.js, container Docker, export statico o tramite adapter. Il server Node e Docker supportano tutte le funzionalità. Con output: 'standalone' ottieni una cartella che contiene solo i file necessari e gira con un server.js minimo.

Su Cloudflare si passa dall'adapter OpenNext, che trasforma l'output di build per farlo girare su Workers. Supporta App Router, ISR, middleware e gran parte del resto, ma non ancora il middleware Node introdotto in Next.js 15.2. C'è anche un limite di dimensione del Worker: 3 MiB compressi sul piano gratuito, 10 MiB su quello a pagamento. Un'app grossa può sbatterci contro. Come si configura e quando valutare le alternative l'ho raccolto in Next.js su Cloudflare Workers: OpenNext, vinext o Vercel.

Morale: se il tuo codice usa Next.js senza estensioni proprietarie, ce l'hai portabile su tutte e tre. Il problema non è lì.

I servizi della piattaforma no

Il lock-in vero sta in quello che colleghi accanto al codice. Storage di file, database, code, configurazioni globali, cron. Ogni piattaforma te li offre a un clic, ed è proprio per questo che si accumulano.

Su Vercel lo storage, come Vercel Blob, e la configurazione globale hanno API proprie. Se te ne vai devi riscrivere le chiamate e migrare i dati.

Su Cloudflare il quadro è misto. R2 espone un'API compatibile con S3, quindi se ci parli con un client S3 uscire è un cambio di endpoint. D1 si esporta in un file SQL con un comando. Ma i binding nel codice del Worker, KV, Durable Objects e Queues, sono API Cloudflare: lì la migrazione è una riscrittura di quei pezzi. Il confronto completo su egress e compatibilità delle API è in R2 vs S3 per un progetto indie, e prima di affidarti a D1 vale la pena leggere come funzionano Time Travel ed export.

Sul VPS il lock-in è minimo, perché quasi tutto è software standard: Postgres, Redis, Nginx, un container. In cambio il lavoro lo fai tu: patch, backup, monitoraggio, il disco che si riempie di notte.

# Le due uscite più economiche, se hai scelto bene all'inizio
# Next.js: build che gira ovunque ci sia Node o Docker
# next.config.js -> output: 'standalone'
npm run build && node .next/standalone/server.js

# D1: dump SQL dell'intero database, pronto per SQLite o un import altrove
npx wrangler d1 export <database_name> --remote --output=./database.sql

Quando conviene ciascuna

Vercel conviene se il prodotto è un'app Next.js che sfrutta a fondo il framework, se le preview per ogni branch ti fanno risparmiare tempo vero e se i 20 dollari al mese non sono un problema. Tieni i dati fuori: un Postgres gestito esterno e uno storage S3 compatibile. Così Vercel resta un posto dove gira il codice, non dove vivono i tuoi dati. Attiva lo spend management con la pausa dei deploy: da solo l'importo fa solo partire notifiche, e il controllo avviene ogni pochi minuti, non in tempo reale.

Cloudflare conviene se il carico è fatto di richieste brevi, molti asset statici e poca CPU per richiesta, e se ti va bene un runtime che non è Node completo. È la scelta con il conto più prevedibile verso il basso. Per tenere il lock-in basso, usa R2 tramite API S3 e tieni l'accesso a D1 dietro un livello sottile, come avevo suggerito nel pezzo su SQLite e Postgres. Per il deploy, Cloudflare sta spostando la CLI verso cf al posto di Wrangler. Se hai già un sito su Pages, qui trovi cosa cambia migrando da Pages a Workers.

Il VPS conviene se hai processi lunghi, worker in background, WebSocket persistenti o un database che vuoi sullo stesso disco. Conviene anche se sai già gestire una macchina Linux e il tempo che ci metti non ti pesa. Tempo umano è costo: se una patch di sicurezza ti porta via una serata al mese, va messa nel conto.

Tre errori comuni

Il primo è partire su Hobby con un prodotto che incassa. Funziona tecnicamente, ma è fuori dalle regole del piano, e il giorno in cui te ne accorgi hai già clienti.

Il secondo è scegliere la piattaforma perché lo scaffold dell'AI l'ha proposta. Ne ho scritto nella trappola dello stack di default: l'agente sceglie quello che ha visto più spesso, non quello che serve a te.

Il terzo è collegare ogni servizio della piattaforma perché è a un clic. Ognuno è comodo da solo. Insieme diventano il motivo per cui non puoi più andartene.

Cosa conviene fare adesso

• Scrivi su un file la lista dei servizi della piattaforma che usi o userai: storage, database, cron, code, configurazione.
• Per ognuno segna l'alternativa standard: S3, Postgres o SQLite, un cron di sistema. Se non ne esiste una, quello è il tuo lock-in.
• Se il prodotto incassa, escludi Vercel Hobby fin da subito e fai il conto partendo dal Pro.
• Metti un tetto di spesa il primo giorno, su qualsiasi piattaforma. Su Vercel con pausa dei deploy, su Workers con i limiti di CPU per invocazione. Il tetto protegge il conto, non le API: su Workers aggiungi anche il rate limiting con binding, WAF o Durable Objects.
• Prova l'uscita una volta: una build standalone in Docker, o un export di D1. Se riesci in un pomeriggio, sei libero di scegliere la piattaforma più comoda.

Prima di andare online, passa dalla checklist per mettere in produzione un sito vibe-coded. Se il prodotto chiama anche un modello, il gateway davanti alle chiamate LLM è il secondo tetto di spesa da mettere.