È uscito il Corso Java Completo
Torna al blog

Cos'è Vercel e come funziona

Cos'è Vercel e come funziona: deploy da Git, preview deployment, serverless e edge function, variabili d'ambiente, domini e i limiti del piano gratuito.

Edoardo Midali

Edoardo Midali

Developer · Content Creator

8 min di lettura

Colleghi il repository, premi un pulsante e due minuti dopo il sito è online con HTTPS e dominio provvisorio. Fin qui la parte facile, quella che raccontano tutti. Le domande vere arrivano dopo: cosa succede quando apri una pull request, dove gira davvero il tuo codice, e cosa capita se un post ti porta molto più traffico del previsto. In questo articolo trovi come funziona Vercel sotto il cofano, cosa la rende diversa dalle altre piattaforme e dove finisce esattamente il piano gratuito.

Cos'è

Vercel è una piattaforma di hosting e deploy per applicazioni web che prende il codice da un repository Git, lo costruisce e lo distribuisce su una rete globale, gestendo da sola build, HTTPS, CDN e funzioni lato server.

È l'azienda che sviluppa Next.js, e questo spiega quasi tutto il resto: le due cose sono progettate insieme, e ogni funzione nuova del framework su Vercel funziona il giorno stesso, altrove qualche mese dopo.

Non è un VPS e non ci somiglia. Non hai una macchina, non hai un sistema operativo, non installi nulla. Hai un repository e una configurazione.

Il flusso di lavoro: tutto parte da Git

Il modello è quello che oggi viene dato per scontato, ma vale la pena vedere cosa fa esattamente:

  1. Colleghi un repository GitHub, GitLab o Bitbucket.
  2. Vercel rileva il framework e imposta comando di build e cartella di output da sola.
  3. A ogni push parte una build.
  4. Il push sul ramo principale aggiorna il sito di produzione. Ogni altro ramo diventa un sito a sé.

Il punto 4 è quello che cambia il lavoro quotidiano, e ci arrivo subito.

Esiste anche una CLI, utile per provare le cose in locale prima di sporcare la cronologia dei commit:

npm i -g vercel
vercel          # deploy di anteprima dalla cartella corrente
vercel --prod   # deploy in produzione
vercel env pull # scarica le variabili d'ambiente in .env.local

Il flusso normale però resta Git: se stai facendo deploy a mano dalla CLI tutti i giorni, probabilmente stai usando Vercel al contrario. Sul funzionamento del flusso automatico in generale, vedi cos'è la CI/CD.

I preview deployment

Questa è la funzione per cui molti team restano su Vercel anche quando altrove costerebbe meno.

Ogni ramo e ogni pull request ottiene un URL pubblico, completo e indipendente, con la build di quel codice esatto. Non un'anteprima approssimativa: il sito vero, con le sue funzioni server, il suo database di test e il suo comportamento reale.

Cosa cambia in pratica:

  • Il cliente guarda la modifica prima che vada in produzione, senza installarsi nulla.
  • Chi fa la revisione del codice apre il link invece di scaricare il ramo e avviarlo in locale.
  • Il designer commenta direttamente sulla pagina.
  • Se qualcosa si rompe, si rompe su un URL che nessun utente sta visitando.

Il commento con il link compare automaticamente sulla pull request. Sembra un dettaglio, ma sposta le discussioni da "prova a immaginare come verrà" a "guarda". Se lavori da solo conta poco. In un team di tre o più persone, con un cliente che deve approvare, è la differenza tra due giorni di scambio di screenshot e dieci minuti.

Serverless ed edge: dove gira il codice

Il codice lato server su Vercel non gira su un server sempre acceso. Gira in funzioni serverless che si avviano su richiesta e si spengono dopo.

Ci sono due modelli, e capire la differenza evita scelte sbagliate:

Serverless functionEdge function
Dove esegueIn una regione precisa che scegli tuNel nodo più vicino al visitatore
AmbienteNode.js completoRuntime ridotto, in stile browser
LibrerieQuasi tutteSolo quelle senza API native di Node
Avvio a freddoC'è, ed è percepibilePraticamente assente
Adatta aAPI, database, logica pesanteRedirect, autenticazione, test A/B, personalizzazione

L'errore classico è mettere una edge function davanti a un database che sta in una sola regione. Il codice parte vicinissimo all'utente, poi attraversa mezzo mondo per interrogare il database e torna indietro: hai reso tutto più lento credendo di ottimizzare. Se la funzione parla con un database, mettila serverless nella stessa regione del database.

L'altro punto da sapere: le funzioni sono senza stato. Nessun file scritto sul disco sopravvive, nessuna variabile in memoria viene ritrovata alla chiamata successiva. Tutto ciò che deve persistere va in un database o in uno storage esterno.

Variabili d'ambiente e ambienti

Vercel separa tre ambienti — produzione, anteprima e sviluppo — e per ognuno puoi impostare valori diversi delle variabili d'ambiente. È la cosa che rende sicuri i preview deployment: le anteprime puntano al database di test, la produzione a quello vero.

Due regole che fanno perdere tempo a tutti almeno una volta:

  • Le variabili si leggono al momento della build, non a ogni richiesta. Cambi un valore nel pannello e non succede niente finché non rifai il deploy.
  • Il prefisso NEXT_PUBLIC_ rende la variabile pubblica. Finisce nel JavaScript che arriva al browser, leggibile da chiunque. Una chiave API con quel prefisso è una chiave API regalata.
DATABASE_URL=...              # solo lato server, al sicuro
NEXT_PUBLIC_ANALYTICS_ID=...  # visibile a chiunque apra il sito

Domini

Ogni progetto ha subito un sottodominio .vercel.app. Per un dominio tuo aggiungi il nome nelle impostazioni e Vercel ti dice quali record DNS creare presso il registrar. Il certificato viene emesso e rinnovato da solo, senza che tu faccia nulla.

Il passaggio completo, valido per qualsiasi piattaforma, è in collegare un dominio al sito. L'unico intoppo ricorrente è aspettarsi propagazione istantanea: a volte è questione di minuti, a volte di ore.

Il piano gratuito e dove finisce davvero

Qui serve onestà, perché è il punto dove le guide entusiaste tacciono.

Il piano gratuito è tecnicamente completo. Non è una versione mutilata: hai preview deployment, funzioni, HTTPS, CDN globale, domini personalizzati. Per un portfolio, un blog, un progetto personale o un prototipo è più che sufficiente e non ti serve altro.

I tre limiti veri:

1. L'uso commerciale non è ammesso. Il piano hobby è per progetti personali e non commerciali. Il sito vetrina della tua attività, l'e-commerce, il prodotto che vendi: formalmente vanno su un piano a pagamento. Non è una clausola dimenticata, viene fatta rispettare. Il rischio non è una multa, è ritrovarsi il progetto sospeso nel momento peggiore.

2. La banda e le esecuzioni sono a consumo. Superate le soglie incluse, sul piano gratuito il progetto viene limitato; su un piano a pagamento continua e paghi il traffico in più. È il modello che genera i racconti di conti a sorpresa: un articolo che va bene su un aggregatore, un'immagine pesante non ottimizzata, un bot che gira in loop, e il consumo si moltiplica in poche ore senza che tu stia guardando.

3. Il costo cresce con il traffico, non con la complessità. È l'opposto di un VPS, dove paghi una cifra fissa e sotto carico al massimo rallenta. Su Vercel sotto carico il sito regge benissimo — e la fattura sale.

Cosa fare concretamente:

  • Imposta subito un limite di spesa e le notifiche di consumo. Sono lì, quasi nessuno le attiva.
  • Non servire immagini non ottimizzate: la banda si consuma soprattutto lì.
  • Sfrutta il caching: una risposta servita dalla cache non fa partire una funzione.
  • Guarda ogni tanto il pannello di utilizzo, non solo quando arriva l'email.

Quando conviene e quando no

Conviene se: usi Next.js, lavori in team con revisioni e approvazioni, vuoi zero manutenzione del server, hai traffico prevedibile o un prodotto che genera ricavi.

Non conviene se: hai un sito statico con molto traffico e poca logica — lì paghi banda che altrove non pagheresti, e Cloudflare Pages fa lo stesso lavoro con un modello di prezzo diverso. Nemmeno se ti servono processi sempre attivi, lavori lunghi, code, WebSocket persistenti o un database sulla stessa macchina: quello è territorio da VPS. E se il progetto è commerciale ma il budget è zero, meglio saperlo prima che dopo.

Per orientarti tra le alternative c'è il confronto diretto in Vercel o Netlify, e il quadro generale in come fare il deploy di un sito.

In sintesi

Vercel prende il tuo repository e lo trasforma in un sito globale senza che tu tocchi un server.

Le tre cose che la distinguono davvero sono l'affinità totale con Next.js, i preview deployment su ogni ramo — la funzione che cambia il modo di lavorare in team — e un'esperienza d'uso in cui le cose funzionano senza configurazione.

Le tre cose da sapere prima di affezionarsi sono che il piano gratuito esclude l'uso commerciale, che la banda si paga a consumo e sotto traffico improvviso il conto può sorprendere, e che le funzioni sono senza stato: niente file, niente memoria tra una richiesta e l'altra.

La regola pratica: progetto personale o applicazione Next.js in team, Vercel è la scelta più comoda che esista. Sito statico ad alto traffico, guarda il modello di prezzo di Cloudflare Pages prima di decidere. E qualunque cosa tu scelga, attiva i limiti di spesa il primo giorno.

Per capire cosa aspettarti in termini di costi complessivi di un progetto web, vedi quanto costa un sito web e hosting gratis o a pagamento.