Vercel vs VPS: dove fare il deploy

Nel confronto Vercel vs VPS la differenza vera è chi gestisce cosa. Su Vercel carichi il codice e la piattaforma pensa a build, CDN, certificati e scalabilità, ma il codice server, cioè SSR e API, gira nel suo modello a funzioni, con durate massime, payload limitati e istanze senza stato; la CDN serve pagine statiche, asset e le risposte delle funzioni messe in cache. Su una VPS fai girare qualunque processo, per tutto il tempo che serve, accanto al database, ma aggiornamenti, firewall, TLS, backup e deploy diventano lavoro tuo. Un frontend Next.js o un sito statico sta comodo su Vercel; un’API con code, websocket di lunga durata e Postgres sta più comoda su un server tuo.

Io ho scelto la VPS per avere più controllo e costi prevedibili. Staging e live stanno su VPS, in locale provo le modifiche in un’immagine Docker, e i tre ambienti sono collegati da una pipeline GitHub Actions su repository privati: ogni push viene testato e passa su staging, e la promozione a live la avvio io a mano con un workflow_dispatch. I dati su Vercel che trovi qui vengono dalla sua documentazione ufficiale, consultata a ottobre 2026, con i link in fondo.

Indice

Due modelli, non due hosting
Cosa offre Vercel e dove si ferma
Cosa devi gestire tu su una VPS
I criteri che decidono
Vercel vs VPS a confronto
Casi d’uso concreti
Frontend su Vercel, API e database su VPS
Da dove partire

Due modelli, non due hosting

Vercel è una piattaforma gestita: colleghi il repository, ogni push produce un deploy e ogni pull request un URL di anteprima. Il codice server gira come Vercel Functions, istanze che nascono e si spengono con il traffico; per i worker continuativi ci sono i Daemons, in beta e con limiti precisi. Niente sistema operativo da amministrare.

Una VPS è una macchina virtuale Linux con accesso root. Ci metti Docker, Postgres, un reverse proxy, un worker, e tutto ciò che sta sopra la macchina è responsabilità tua.

Cosa offre Vercel e dove si ferma

Piani. Hobby è gratuito ma riservato all’uso personale e non commerciale. È commerciale qualunque deploy da cui qualcuno guadagni: pagamenti dai visitatori, vendita di servizi, un cliente che paga il sito, pubblicità come AdSense (le donazioni no).

Il Pro costa 20 dollari al mese, tasse escluse: comprende un posto per chi fa deploy e 20 dollari di credito d’uso, che scade a fine mese. Ogni altro posto di deploy costa 20 dollari al mese. Comprende anche il primo livello del Flat Rate CDN, un milione di richieste e 1 TB di trasferimento al mese, da attivare nelle impostazioni di fatturazione e valido solo per gli usi ammessi (niente distribuzione massiva di file); se lo superi stabilmente, dal ciclo successivo passi al livello sopra (il primo a pagamento costa 20 dollari al mese). Quando è attivo, un picco isolato non fa salire il livello CDN, ma può far crescere i consumi delle funzioni, che si pagano a parte.

Prezzi a consumo. Finito il credito, le funzioni si pagano per CPU attiva (da 0,128 dollari l’ora), memoria allocata (da 0,0106 dollari per GB-ora) e invocazioni (0,60 dollari per milione). L’attesa di una query non conta come CPU, la memoria allocata sì. Hobby ha quote fisse, tra cui 100 GB di trasferimento, un milione di invocazioni e 4 ore di CPU attiva al mese; se le superi, di solito aspetti 30 giorni.

Spend Management avvisa al 50, 75 e 100% di una soglia e, se attivi anche l’opzione Pause Production Deployments, mette in pausa tutti i deploy di produzione del team quando la raggiungi: i visitatori ricevono un 503 e i progetti vanno riattivati uno per uno. Il controllo avviene ogni pochi minuti, quindi la soglia può essere superata. Non è un tetto alla fattura: su Pro conta solo i consumi oltre il credito, esclusi posti, integrazioni del Marketplace e add-on, e la pausa non ferma tutto (le chiavi di AI Gateway, per esempio, continuano a consumare).

Limiti delle funzioni. Con Fluid compute, attivo di default sui progetti nuovi, una funzione dura al massimo 300 secondi su Hobby; su Pro il default è 300, configurabile fino a 800, e fino a 1800 in beta per alcuni runtime. Il corpo delle richieste non supera 4,5 MB (per file più grandi si carica direttamente sullo storage), e lo stesso limite vale per le risposte non in streaming; quelle in streaming possono superarlo, entro la durata massima. La memoria arriva a 2 GB su Hobby e 4 GB su Pro. Di default le funzioni girano in una sola regione, iad1 (Washington): se il database è in Europa, è la prima impostazione da cambiare.

Websocket e cron. I websocket sono in beta pubblica su tutti i piani, ma la connessione si chiude alla durata massima della funzione, resta legata a un’istanza e tiene la memoria fatturabile finché è aperta: servono riconnessione lato client e stato condiviso in un archivio esterno come Redis. I cron invocano funzioni; su Hobby girano al massimo una volta al giorno, con un’ora di tolleranza.

Docker e processi lunghi. Vercel ora esegue immagini OCI costruite da un Dockerfile.vercel (Container Runtime, in beta), con gli stessi limiti e prezzi delle funzioni: in produzione le istanze si spengono dopo 5 minuti senza traffico e non hanno stato. Per i worker sempre attivi ci sono i Daemons, anch’essi in beta: niente traffico in ingresso, niente storage persistente né autoscaling, solo produzione. Non è un posto dove portare un compose.yaml con il database dentro.

Database e framework. In proprio Vercel offre Blob per i file e Global Config per la configurazione; Postgres e Redis arrivano dal Marketplace (Neon, Supabase, Upstash e altri), con i prezzi del provider. Next.js, SvelteKit, Nuxt, Astro, Remix e Vite partono spesso senza configurazione; una matrice nella documentazione dice quali funzioni valgono per ciascuno.

Cosa devi gestire tu su una VPS

Aggiornamenti. Su Ubuntu Server unattended-upgrades è installato di default e applica da solo gli aggiornamenti di sicurezza, ma non riavvia: per il kernel il riavvio lo pianifichi tu o lo abiliti con Automatic-Reboot. Le immagini Docker vanno ricostruite e ridistribuite a parte.
Firewall. Aperte solo SSH, 80 e 443. Con Docker c’è una trappola: le porte pubblicate da un container vengono instradate prima delle regole di ufw, che di fatto le ignora, e senza un indirizzo esplicito Docker pubblica su tutte le interfacce. Per questo nel setup Docker Compose con Node e PostgreSQL l’app è pubblicata su 127.0.0.1:3000 e Postgres non espone porte. Serve Docker Engine 28.0.0 o successivo: nelle versioni precedenti una porta su localhost può essere raggiunta da altri host sullo stesso segmento di rete.
Reverse proxy e TLS. Nginx o Caddy sull’host ricevono HTTPS e inoltrano al loopback. Caddy ottiene e rinnova i certificati da solo, se i record DNS puntano al server e le porte 80 e 443 sono raggiungibili; con Nginx il rinnovo lo configuri tu.
Backup. Dump regolari del database (pg_dump) copiati fuori dalla macchina e un ripristino provato almeno una volta.
Deploy e rollback. Nella pipeline CI/CD con GitHub Actions per Node e React si costruisce un’immagine sola, la si identifica per digest e sul server si scrive solo deploy.env, lasciando intatto il .env delle credenziali. Il rollback ridistribuisce il digest precedente, ma riporta indietro solo il codice: le migrazioni del database vanno tenute compatibili con la versione precedente.
Monitoraggio. Disco pieno o container fermo: te ne accorgi solo se qualcosa te lo dice.

I criteri che decidono

Tipo di applicazione. Pagine statiche e asset li serve la CDN, SSR e API rapide stanno bene nel modello a funzioni; un server Node con stato in memoria o filesystem persistente va riscritto in parte.

Processi lunghi, websocket, cron. Esportazioni da mezz’ora, worker, connessioni aperte per ore, job ogni cinque minuti: su Vercel ognuno ha una risposta (durate estese, Workflows, Daemons, cron al minuto su Pro), con vincoli e prezzo da capire. Su una VPS è un servizio in più nel compose.yaml.

Database. Con Vercel è un servizio esterno, con la sua fattura. Su una VPS sta accanto all’app, sulla rete interna di Docker, ma backup e aggiornamenti sono affar tuo.

Costi prevedibili o a consumo. La VPS ha un canone fisso, ma un picco oltre le risorse può rallentare il servizio o renderlo indisponibile (timeout, processi chiusi per memoria esaurita); eventuali addebiti extra dipendono dal contratto del provider. Su Vercel paghi poco con traffico basso e la piattaforma assorbe i picchi, ma la fattura segue l’uso: una funzione lenta o una chiamata in loop si vedono in bolletta.

Competenze ops. Senza qualcuno che sappia configurare un firewall, la VPS è un rischio prima che un risparmio.

Lock-in. Il codice di un’app Next.js resta portabile, ma vercel.json, cron, Blob, Global Config e integrazioni del Marketplace sono pezzi della piattaforma: più ne usi, più costa andarsene. Su una VPS, con immagini e file Compose, cambi provider portandoti dietro tutto.

Vercel vs VPS a confronto

Aspetto	Vercel	VPS Linux
Modello	Funzioni e CDN gestite senza stato; worker continui con i Daemons (beta)	Macchina con root, processi sempre attivi
Uso commerciale	Solo da Pro (20 $/mese più consumi)	Secondo il contratto del provider
Costi	Credito incluso, poi a consumo; soglia sui consumi con pausa opzionale della produzione	Canone fisso
Durata di una richiesta	300 s su Hobby, fino a 800 s su Pro (1800 s in beta)	Nessun limite di piattaforma
Websocket	Beta, chiusi alla durata massima	Nessun limite di piattaforma (contano i timeout del reverse proxy)
Cron	Una volta al giorno su Hobby, al minuto su Pro	cron o timer di sistema
Database	Esterno, dal Marketplace	Sulla stessa macchina o esterno
Docker	Container Runtime e Daemons in beta, senza stato né volumi	Docker e Compose completi
Manutenzione	Infrastruttura a carico di Vercel; codice, dipendenze, immagini e dati a carico tuo	Aggiornamenti, firewall, TLS, backup a carico tuo
Anteprime per PR	Incluse	Da costruire nella pipeline
Lock-in	Cresce con le funzioni di piattaforma usate	Basso con immagini e file Compose

Casi d’uso concreti

Portfolio o blog personale senza pubblicità. Vercel Hobby: niente server, HTTPS e anteprime inclusi. Con annunci o servizi in vendita serve il Pro.
Sito di un cliente in Next.js con un CMS. Vercel Pro (il cliente paga, quindi niente Hobby): ISR e anteprime fanno risparmiare tempo.
Gestionale interno con Node, Postgres e job notturni. Una VPS con Docker Compose: dati in un posto solo, esportazioni senza limiti di durata, costo fisso.
Chat in tempo reale o worker su una coda. Su una VPS è un servizio in più; su Vercel servono riconnessioni, stato esterno e componenti in beta.

Frontend su Vercel, API e database su VPS

È lo schema tipico di un SaaS con frontend pubblico e backend corposo: su Vercel il frontend, su una VPS API, worker e Postgres. Aggiunge complessità:

CORS e cookie. Se il browser chiama api.example.com da example.com, l’API deve rispondere con le intestazioni CORS giuste e i cookie di sessione tra domini diversi richiedono attributi precisi. L’URL univoco di ogni deploy cambia, mentre quello di un branch resta stabile tra un push e l’altro: per pochi branch controllati puoi metterlo in una allowlist esplicita; per anteprime qualsiasi serve un controllo dinamico e restrittivo, mai CORS aperto a tutte le origini.
Latenza. Ogni rendering lato server che interroga l’API viaggia tra la regione delle funzioni e la VPS: con la regione di default negli Stati Uniti e il server in Europa attraversa l’oceano. Scegli la regione più vicina alla VPS.
Due pipeline. Vercel pubblica il frontend a ogni push, la tua pipeline il backend con i suoi tempi: una modifica su entrambi i lati arriva in due momenti, quindi l’API deve restare compatibile con il frontend precedente. Log e segreti stanno in due posti.

Per evitare CORS puoi servire l’API dallo stesso dominio con una rewrite verso un’origine esterna: il browser vede example.com/api/... e Vercel inoltra alla VPS. Per impedire che qualcuno chiami la VPS saltando il proxy, la documentazione suggerisce un’intestazione segreta: generi un valore casuale lungo (per esempio con openssl rand -hex 32), lo salvi come variabile d’ambiente ORIGIN_SECRET negli ambienti Vercel che usano la rewrite e nella configurazione dell’origine, e Vercel lo aggiunge a ogni richiesta inoltrata:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "routes": [
    {
      "src": "/api/(.*)",
      "dest": "https://api.example.com/$1",
      "transforms": [
        {
          "type": "request.headers",
          "op": "set",
          "target": { "key": "x-origin-secret" },
          "args": "$ORIGIN_SECRET",
          "env": ["ORIGIN_SECRET"]
        }
      ]
    }
  ]
}

All’origine rifiuti ogni richiesta in cui l’intestazione manca o ha un valore diverso da quello atteso: un controllo sulla sola presenza si aggira con un valore qualsiasi. Se il confronto avviene nel codice, usa una funzione a tempo costante come crypto.timingSafeEqual di Node. Solo le richieste che passano il controllo meritano fiducia su x-forwarded-for.

Poi la cache. Sui progetti creati dal 6 aprile 2026 Vercel mette in cache le risposte delle rewrite esterne secondo le intestazioni dell’origine, e Vercel-CDN-Cache-Control e CDN-Cache-Control hanno la precedenza su Cache-Control. Le risposte personalizzate devono uscire con Cache-Control: private, no-store e senza intestazioni CDN o regole in vercel.json che riattivino la cache, altrimenti rischi di servire i dati di un utente a un altro. Per le route dell’API puoi anche disattivare la cache delle rewrite impostando in vercel.json l’intestazione x-vercel-enable-rewrite-caching a 0.

Da dove partire

Elenca cosa gira oltre alle richieste HTTP brevi: job, code, connessioni aperte, file da conservare. Se la lista è vuota e il progetto è un frontend, Vercel ti toglie lavoro. Se è lunga e c’è un database da tenere vicino all’app, una VPS con Docker Compose e deploy per digest ti dà un sistema che capisci fino in fondo, se dedichi tempo a sicurezza e backup.

Le cifre sono quelle della documentazione di ottobre 2026 e alcune funzioni sono in beta: ricontrollale prima di scegliere. Come la catena dev, staging e live su VPS si incastra con gli strumenti di AI che uso ogni giorno lo racconto nell’articolo sull’AI nel workflow di sviluppo.