Vercel pricing: quanto costa Turbo per un solo deployment

Il 17 settembre 2026, Vercel ha reso più flessibile il Vercel pricing di Turbo: ora permette di sceglierlo e sostenerne il costo per un solo deployment, senza adottarlo per l’intero progetto. Si può investire di più su una build urgente e lasciare che il deployment successivo torni alla macchina normalmente prevista dal progetto.

Vercel pricing: non serve più cambiare l’impostazione del progetto

Una macchina di build è il computer temporaneo che Vercel assegna al codice per installare le dipendenze, compilare l’applicazione e preparare il deployment. Tra le opzioni fisse, Turbo è la più grande: 30 vCPU, 60 GB di memoria e 64 GB di spazio su disco.

Prima di questa novità, per scegliere una macchina di build fissa bisognava modificare un’impostazione del team o del progetto. Una scadenza ravvicinata diventava quindi scomoda da gestire: pagare Turbo anche per le normali build di anteprima, oppure cambiare l’impostazione per l’urgenza e ricordarsi poi di ripristinarla.

Il nuovo override assegna Turbo a un solo deployment, senza toccare l’impostazione del progetto. Se di norma il progetto usa Basic, Standard o Elastic, il deployment successivo torna a quella scelta, a meno che non venga applicato un altro override.

È questo il vantaggio concreto: la spesa aggiuntiva per la build segue l’urgenza, non ogni commit.

Turbo, Enhanced ed Elastic sono disponibili nei piani Pro ed Enterprise. I progetti Hobby usano sempre Basic, quindi non è una scorciatoia per velocizzare il piano Hobby. Inoltre, non offre alcun beneficio a un progetto che esegue già tutti i deployment su Turbo.

Tre modi per attivare Turbo su un solo deployment

Il metodo dipende da ciò che avvia il deployment. Tutte e tre le opzioni applicano lo stesso override, valido per un solo deployment.

1. 1

   Usare il marker nel commit GitHub

   Per un deployment attivato dall’integrazione GitHub di Vercel, inserire nel corpo del messaggio di commit il marker esatto, rispettando maiuscole e minuscole:

   git commit -m "Test this change with Turbo" \
     -m "#VERCEL_BUILD_MACHINE=TURBO"

   Il marker vale soltanto per il deployment generato da quel commit. Al momento non funziona con le integrazioni GitLab o Bitbucket di Vercel.

2. 2

   Usare Vercel CLI

   Da un progetto collegato, eseguire:

   vc deploy --turbo

   Questa modalità richiede Vercel CLI 59.20.0 o una versione successiva. Se il flag non viene riconosciuto, la prima verifica da fare riguarda la versione della CLI.

3. 3

   Impostare il campo nell’API di deployment

   Se un servizio interno di release crea il deployment tramite POST /v13/deployments, impostare buildMachine su turbo nella richiesta. Il campo è facoltativo e si applica solo a quel deployment: non modifica le impostazioni del progetto.

Serve l’autorizzazione per aggiornare la macchina di build del progetto. C’è anche un caso di errore silenzioso da conoscere: se Turbo non è disponibile o l’account non dispone dei permessi necessari, Vercel usa la macchina normalmente scelta dal progetto anziché far fallire il deployment.

Costi Vercel: una tantum è poco, per abitudine diventa caro

Vercel attualmente addebita l’utilizzo delle build a $0.0035 per minuto CPU. Ne derivano prezzi iniziali di $0.007 per ogni minuto di build fatturato con Basic, $0.014 con Standard quando viene fatturato, $0.028 con Enhanced e $0.105 con Turbo.

Prima di moltiplicare per il numero di CPU della macchina, il conteggio arrotonda ogni build al minuto superiore. Una build Turbo che dura 3 minuti e 40 secondi viene quindi fatturata come 4 minuti, per un costo di $0.42.

Per valutare Basic rispetto a Elastic a livello di progetto, leggere Ridurre i costi di build Vercel con le macchine Basic. La decisione introdotta ora è più circoscritta: capire se una singola scadenza giustifica il sovrapprezzo di Turbo.

Un esempio di carico di lavoro, non un benchmark

Immaginiamo che un team effettui 20 deployment ordinari e 1 urgente in una settimana. Le sue misurazioni indicano che lo stesso carico richiede 7 minuti e 20 secondi su Basic e 3 minuti e 40 secondi su Turbo. Questi tempi sono ipotetici e servono soltanto per il calcolo: Turbo non dimezza ogni build.

Rispetto all’esecuzione dello stesso deployment su Basic, l’override urgente aggiunge $0.364. In questo esempio, il sovrapprezzo consente di risparmiare 3 minuti e 40 secondi sulla release che conta.

Mantenendo le 20 build ordinarie su Basic, il totale settimanale è inferiore di $7.28 rispetto all’esecuzione di tutte e 21 su Turbo. In una frase, è questo il nuovo controllo sul budget. La decisione reale deve però basarsi sulle durate del proprio progetto, perché stato della cache, utilizzo della CPU, pressione sulla memoria e arrotondamento possono cambiare il risultato.

Per chi questo workflow è davvero utile

Un founder indipendente che deve pubblicare una correzione in produzione

Chi gestisce un SaaS collegato a GitHub può aggiungere il marker al singolo commit dell’hotfix. Il beneficio non è rendere il progetto sempre più veloce, ma ridurre l’attesa per la release legata a un’interruzione del servizio, a un impegno verso un cliente o a una finestra di lancio. Al push successivo si torna alla spesa normale.

Il responsabile release di un’agenzia alle prese con una scadenza

Un’agenzia può usare vc deploy --turbo per la release del cliente che ha già persone in attesa della revisione. Le normali anteprime restano sulla configurazione abituale del progetto, evitando che la voce di costo delle build aumenti silenziosamente a ogni modifica richiesta dal cliente.

Un platform engineer con un processo di approvazione

Un team di piattaforma può aggiungere buildMachine: "turbo" soltanto al percorso approvato per le release urgenti nel proprio servizio di deployment. In questo modo, le risorse di calcolo aggiuntive diventano una decisione esplicita sulla release, che può essere registrata, sottoposta a revisione e contabilizzata, invece di restare l’impostazione predefinita del progetto.

I limiti, senza giri di parole

Trenta vCPU non significano che una build sarà 15 volte più veloce rispetto alle 2 vCPU di Basic. Alcune build non riescono a sfruttare tutti quei core. Vercel afferma che molti progetti non utilizzano pienamente una macchina Turbo: è anche il motivo per cui Elastic può scegliere una macchina più piccola per le attività ordinarie.

Turbo cambia la macchina, non la gestione della coda. Se il ritardo dipende soprattutto dall’attesa di uno slot di build, una macchina più potente potrebbe risolvere il problema sbagliato. Prima di pagare per più CPU, confrontare il tempo trascorso in coda con quello impiegato dalla build.

Anche lo stato della cache può rendere il confronto inattendibile. Una build predefinita con cache calda e una build Turbo con cache fredda non isolano l’effetto della macchina. Usare revisioni e condizioni della cache simili, confrontando sia i minuti fatturati sia il tempo effettivamente trascorso.

Eseguire una prova controllata

1. 1

   Registrare il deployment normale

   Aprire Build Diagnostics e annotare la macchina normalmente scelta dal progetto, la durata della build, il tempo in coda, i minuti fatturati e l’esito. Scegliere un deployment simile al carico urgente che si vuole valutare.

2. 2

   Applicare l’override a un deployment

   Usare il marker GitHub, il flag della CLI o il campo API su un deployment paragonabile. Non modificare l’impostazione della macchina di build del team o del progetto.

3. 3

   Calcolare il costo del tempo risparmiato

   Moltiplicare i minuti di build Turbo, arrotondati per eccesso, per $0.105. Confrontare l’addebito con l’utilizzo fatturato del deployment normale, quindi dividere la spesa aggiuntiva per i minuti effettivamente risparmiati.

4. 4

   Controllare il deployment successivo

   Avviare un altro deployment normale senza marker, flag o campo API. Verificare che utilizzi la macchina abituale del progetto. Questo controllo permette di individuare un’eventuale modifica accidentale dell’impostazione del progetto e dimostra che l’override è rimasto temporaneo.

Cosa fare adesso

• Agire questa settimana se si gestisce un progetto Pro o Enterprise con release occasionali vincolate da una scadenza e si vuole mantenere la normale configurazione della macchina.
• Misurare prima se il progetto usa Elastic. Potrebbe già assegnare CPU e memoria sufficienti, quindi forzare Turbo rischia di aumentare il conto senza ridurre granché i tempi.
• Preferire un’impostazione di progetto se la maggior parte dei deployment richiede Turbo. Ripetere un’eccezione a ogni commit equivale a mascherare una regola dietro un flag.
• Ignorare questa novità se si usa Hobby, Turbo è già l’opzione predefinita oppure il ritardo dipende soprattutto dalla coda.

La mossa del lunedì

Lunedì, scegliere un deployment rappresentativo. Registrare i dati della build normale, eseguire un override Turbo, calcolare il sovrapprezzo rispetto al tempo effettivamente risparmiato, quindi avviare un deployment normale e verificare che il progetto sia tornato alla configurazione abituale.

Iscriviti alla newsletter per ricevere spiegazioni chiare sui cambiamenti delle piattaforme che incidono sul budget o sul workflow.