Costi Vercel: quando Basic conviene davvero per le build

Basic promette build Vercel più economiche, ma durata, arrotondamenti, errori e code decidono il costo reale. Ecco come confrontarla con Elastic.

Wednesday, September 9, 2026Omid Saffari
Tools
Costi Vercel: quando Basic conviene davvero per le build

Per ridurre davvero i costi Vercel non basta scegliere il minuto di build più economico. Il 3 settembre 2026, Vercel ha introdotto per i team Pro ed Enterprise la nuova opzione Basic: 2 vCPU, 8 GB di memoria e una tariffa di $0.007 per minuto di build. Il conto scende soltanto se, una volta inclusi durata, arrotondamenti, errori e attesa in coda, il costo di ogni build completata resta inferiore a quello di Elastic.

Che cosa ha cambiato Vercel

Una macchina di build è il computer temporaneo che Vercel usa per installare le dipendenze, compilare l'applicazione e preparare un deployment. Ora i progetti a pagamento hanno anche un'opzione più piccola e a capacità fissa: le macchine di build Basic sono disponibili sui piani Pro ed Enterprise, non più soltanto su Hobby.

Basic offre 2 vCPU, 8 GB di memoria e 32 GB di spazio su disco. Elastic può assegnare da 4 a 30 vCPU e da 8 a 60 GB di memoria in base al carico di lavoro del progetto. Per i nuovi progetti a pagamento, Elastic resta l'impostazione predefinita.

La documentazione Vercel mostra le risorse delle macchine di build Basic ed Elastic e l'impostazione a livello di progetto
Vercel

Si tratta quindi di una scelta, non di un nuovo default a pagamento. I nuovi progetti a pagamento partono ancora da Elastic; il proprietario può selezionare Basic nelle impostazioni del team o del progetto. I progetti Hobby mantengono la stessa macchina inclusa con 2 vCPU, che ora si chiama Basic.

Qui analizziamo soltanto la scelta della macchina di build. Canone del piano, credito d'uso, postazioni, traffico, funzioni, storage e componenti aggiuntivi restano nel quadro completo dei prezzi Vercel.

Costi Vercel: conta il costo per build completata

Basic ed Elastic partono dalla stessa tariffa CPU: $0.0035 per minuto CPU. Gli importi divergono perché Basic usa sempre 2 vCPU, mentre Elastic ne assegna da 4 a 30.

Vercel arrotonda per eccesso la durata di ogni build al minuto successivo. Ne derivano due formule operative:

  • Basic: minuti di build arrotondati per eccesso × $0.007.
  • Elastic: minuti di build arrotondati per eccesso × vCPU assegnate × $0.0035.

Con l'assegnazione Elastic minima di 4 vCPU, il costo iniziale è $0.014 per ogni minuto di build fatturato. Basic costa la metà per minuto fatturato. Il punto di pareggio arriva quindi quando Basic impiega esattamente il doppio dei minuti fatturati; se ne impiega meno del doppio, è l'opzione più economica.

La regola cambia quando Elastic assegna più di 4 vCPU. Cambia anche a ogni soglia di minuto, perché Vercel arrotonda la durata di ciascuna build, non il totale mensile. Per stimare la fattura servono durata reale e macchina assegnata: il listino, da solo, non basta.

Un modello architetturale dei costi confronta 1,000 build completate su Basic in tre minuti con Elastic in due minuti
Carico di lavoro illustrativo: 1,000 build completate, 3 minuti fatturati su Basic contro 2 con un'assegnazione Elastic da 4 vCPU.

In questo esempio, i $7 risparmiati sono reali, ma non necessariamente rilevanti. Se ogni anteprima blocca uno sviluppatore, un revisore o un agente di coding, un ciclo di feedback più lento può costare più del risparmio in fattura. Se invece le build procedono in background e la coda resta libera, Basic offre il costo unitario migliore.

Nel calcolo vanno incluse anche le build fallite. La metrica operativa è il totale degli addebiti di build diviso per i deployment riusciti. Una macchina economica al minuto può risultare più costosa sul risultato finale se provoca nuovi tentativi.

Il tempo in coda è un costo per il workflow

La formula di fatturazione pubblicata da Vercel considera la durata della build e il numero di CPU. Il tempo in coda non compare come voce aggiuntiva, ma il team ne subisce comunque l'impatto.

Quando la concorrenza on demand è disattivata, Pro offre 3 slot per deployment simultanei. Le build che superano gli slot attivi restano in attesa. Con la concorrenza on demand, Vercel indica fino a 500 deployment simultanei e addebita i minuti di build utilizzati.

Una build Basic più lenta occupa uno slot più a lungo. Per chi gestisce da solo un piccolo sito con pochi deployment al giorno potrebbe essere irrilevante. Diventa invece un fattore concreto quando un agente di coding apre più anteprime, un'agenzia distribuisce molti progetti dei clienti o un team invia modifiche su più branch contemporaneamente.

Misura entrambi i tempi:

  • Durata della build: determina il costo della macchina dopo l'arrotondamento.
  • Attesa in coda più durata della build: determina il tempo necessario per ricevere un feedback.

La decisione sta tutta qui: ottimizzare il primo valore senza lasciare che il secondo penalizzi il workflow.

Per chi vale la pena provare Basic

Founder indipendente con una piccola applicazione

Chi gestisce da solo una startup SaaS può spostare su Basic, a livello di progetto, un sito marketing leggero o una dashboard, quindi confrontare la stessa build rappresentativa su Elastic. Il vantaggio è una voce di costo ricorrente più bassa senza modificare il resto del piano Vercel.

La scelta conviene soltanto se la build resta affidabile e l'eventuale rallentamento non ritarda i rilasci. Per un progetto con deployment occasionali, la differenza economica potrebbe non giustificare una regolazione manuale.

Agenzia con progetti cliente diversi

Un'agenzia non dovrebbe imporre la stessa macchina a tutti gli account. I piccoli siti vetrina e i progetti editoriali possono passare a Basic, uno alla volta e a livello di progetto. Storefront più grandi, monorepo e applicazioni con molte dipendenze dovrebbero restare su Elastic finché le rispettive misurazioni non indicano il contrario.

Il vantaggio è un margine più leggibile per ogni progetto. Un cliente con poche esigenze non deve più ereditare la stessa macchina usata dall'applicazione più pesante dell'agenzia.

Responsabile tecnico che usa agenti di coding

Lo sviluppo guidato da agenti modifica il volume dell'equazione. Più commit automatizzati possono generare più build di anteprima, facendo ripetere più spesso anche una piccola differenza di costo per build.

Il responsabile tecnico deve misurare una sequenza rappresentativa, non un singolo deployment in un momento tranquillo. Se Basic riduce il costo per build completata, ma le esecuzioni più lunghe saturano i 3 slot disponibili e creano una coda, la macchina più economica ha semplicemente spostato il costo dalla fattura al tempo di risposta.

Responsabile di piattaforma Enterprise

Basic è disponibile anche per Enterprise, ma una clausola contrattuale può impedire la modifica self-service. I clienti Enterprise con macchine Enhanced abilitate da contratto utilizzano quelle macchine per impostazione predefinita e devono contattare il proprio account manager per aggiornare le preferenze.

Come passare un progetto a Basic e misurare il risultato

Inizia con una modifica a livello di progetto. L'esperimento resta separato dalle altre applicazioni e, dalla stessa impostazione, puoi tornare indietro senza complicazioni.

  1. Registra il riferimento su Elastic

    Apri Build Diagnostics in Vercel Observability e scegli un deployment rappresentativo. Annota durata della build, macchina assegnata, utilizzo fatturato, attesa in coda ed esito del deployment. Per il test su Basic mantieni comparabili le condizioni della cache e la revisione del codice.

  2. Seleziona Basic per il progetto

    Apri il progetto in Vercel, quindi vai in Settings, Build and Deployment e Build Machine. Seleziona Basic e salva. Vercel consente la stessa scelta anche a livello di team, ma per il primo test è più prudente intervenire sul singolo progetto. Per accedere alle impostazioni della macchina di build serve il ruolo di proprietario.

  3. Usa il comando CLI documentato

    Con Vercel CLI 59.6.0 o una versione successiva puoi modificare il progetto con questo comando:

    Bash
    vc project update --build-machine basic

    L'errore più facile è eseguire una CLI meno recente e concludere che il piano non consenta di scegliere la macchina. Controlla la versione prima di attribuire al piano un comando non riuscito.

  4. Ripeti lo stesso carico di lavoro

    Esegui la build della stessa revisione rappresentativa con condizioni della cache comparabili. Registra gli stessi dati: durata, macchina, utilizzo fatturato, attesa in coda ed esito. Nei flussi guidati da agenti, includi una sequenza normale di build per permettere alla coda di emergere.

  5. Decidi in base ai risultati

    Calcola il costo mensile totale delle build e dividilo per i deployment riusciti. Mantieni Basic se il costo unitario diminuisce e il tempo complessivo resta entro l'obiettivo del team. Torna a Elastic dalle impostazioni di Build Machine se velocità, memoria o affidabilità peggiorano abbastanza da annullare il risparmio.

I limiti da non ignorare

Basic è una macchina più piccola, non una versione più efficiente di Elastic. Il limite di memoria è fisso a 8 GB. Quando il carico lo richiede, Elastic può arrivare fino a 60 GB e 30 vCPU.

Anche l'arrotondamento può assorbire un piccolo risparmio. Bastano pochi secondi oltre la soglia del minuto per aggiungere un altro minuto intero alla fattura. Confronta l'utilizzo fatturato mostrato da Vercel, non un calcolo al cronometro arrotondato a tuo favore.

Elastic continua inoltre ad adattarsi all'evoluzione del progetto, mentre Basic resta fissa. Una macchina adatta alla piccola applicazione di oggi può diventare quella sbagliata quando aumentano dipendenze, route o asset generati.

Chi dovrebbe agire, aspettare o ignorare la novità

  • Agisci questa settimana se gestisci un progetto Pro o Enterprise con build stabili, poco esigenti e abbastanza frequenti da rendere significativa una differenza ricorrente per singola build.
  • Aspetta se il progetto è limitato dalla CPU, usa molta memoria, si avvicina al limite di 45 minuti o risente già delle code delle anteprime. Prima raccogli un riferimento affidabile su Elastic.
  • Ignora la variazione di prezzo se usi Hobby. La macchina inclusa con 2 vCPU è stata rinominata Basic, ma né la macchina né il trattamento previsto dal piano sono cambiati.
  • Controlla prima il contratto se Enterprise include macchine Enhanced. La modifica potrebbe dipendere dall'account manager.

La prova da fare lunedì

Lunedì scegli un piccolo progetto rappresentativo. Esegui la stessa build su Elastic e Basic, quindi annota durata, utilizzo fatturato, CPU assegnate, attesa in coda ed esito. Conserva l'opzione che riduce il costo per build completata senza superare l'obiettivo del team per i tempi di risposta.

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

Ultimo aggiornamento

9 set 2026

CategoriaExplained

Preferisca questo sito su Google

Aggiungi omidsaffari.com come fonte preferita nella Ricerca Google

Segni omidsaffari.com come fonte preferita e Google lo mette in evidenza per lei in Top Stories, AI Overviews e AI Mode.

Newsletter

Una lettera, ogni domenica. Sistemi che funzionano, non hot take.

Build log, sistemi in produzione e note dal campo da un portafoglio di venture AI.

Settimanale. Niente spam. Si cancella quando vuole.