Vercel Sandbox raddoppia il disco per i job più pesanti

La novità davvero utile non è «64 GB» presa da sola. È il fatto che un job su repository che prima si fermava contro il limite di 32 GB di Vercel Sandbox ora può arrivare alla fine su una sola macchina, senza essere alleggerito, suddiviso o spostato altrove.

L'11 settembre 2026, Vercel ha raddoppiato lo spazio di lavoro predefinito di ogni Sandbox, portandolo da 32 GB a 64 GB.

Vercel Sandbox ora ha il doppio dello spazio di lavoro

Vercel Sandbox è una microVM Linux isolata: una piccola macchina virtuale con kernel, filesystem e rete propri. Le si può affidare un repository, lasciare che un agente modifichi il codice, installi i pacchetti, esegua i test e produca una build, per poi estrarre il risultato.

Tutte queste fasi usano lo stesso disco locale. Il checkout può essere ancora presente quando arriva l'albero delle dipendenze. Cache di build e output compilato possono convivere con i file temporanei. L'artefatto finale può essere piccolo, anche se durante la lavorazione il job richiede per poco tempo molto più spazio.

È proprio questo picco che cambia con la release. Vercel assegna ora alla sandbox 64 GB di spazio di lavoro anziché 32 GB: 32 GB in più, cioè il doppio della capacità precedente. La modifica riguarda le sandbox create da una Vercel Managed Image, da un'immagine personalizzata e tramite la proprietà deprecata runtime.

Si tratta di capacità interna alla sandbox, non di una nuova quota per database o object storage. Vercel la descrive come storage NVMe effimero. Se i file devono sopravvivere al job, la scelta sulla persistenza resta separata.

La decisione aziendale è capire se il job entra in una sola macchina

La domanda che conta nel tempo non è «qual è il limite del disco di Vercel?», ma «l'intero job può essere eseguito in una sola sandbox, senza tagli particolari né passaggi intermedi?».

Per stimarlo basta un semplice budget dello spazio di lavoro:

Picco dello spazio di lavoro = repository e checkout + dipendenze installate + artefatti di build + picco dei dati temporanei

Misurate il massimo utilizzo mentre il job è in esecuzione. Non deducetelo dalle dimensioni del file zip finale. Estrazione dei pacchetti, compilazione, fixture di test, binari dei browser, cache e riversamento di dati su disco possono sovrapporsi anche solo per pochi minuti, ma sono proprio quei minuti a decidere se l'esecuzione arriva in fondo.

Le tariffe e quote attuali di Vercel separano i livelli di storage in voci di budget distinte:

Questa distinzione cambia il calcolo dei costi. Raddoppiare il disco di lavoro non raddoppia la tariffa di calcolo. Nell'esempio attuale di Vercel per iad1, un'esecuzione di build e test di 30 minuti con 4 vCPU e 8 GB di memoria costa circa $0.34 a pieno utilizzo della CPU.

Un job più grande può comunque costare di più se dura più a lungo o richiede più CPU e memoria. I download di pacchetti, repository, artefatti e dataset sono gratuiti, mentre i dati inviati fuori dalla sandbox sono fatturati.

È con la persistenza che i file aggiuntivi possono generare un nuovo costo di storage. Se un'esecuzione usasse e conservasse tutti i 32 GB appena resi disponibili per un mese intero, il calcolo in base al listino sarebbe 32 × $0.08 = $2.56 per ogni mese di snapshot. È solo un esempio, non un addebito automatico. Un'esecuzione non persistente che esporta il risultato e poi elimina lo spazio di lavoro evita questa voce relativa agli snapshot.

Chi può sfruttare lo spazio aggiuntivo

Uno staff engineer alle prese con un monorepo voluminoso

Uno staff engineer potrebbe oggi dover escludere pacchetti, rimuovere fixture di test o suddividere una build perché repository, grafo delle dipendenze e output di build non riescono a convivere sotto il vecchio limite.

Se il picco misurato ora rientra nei 64 GB disponibili del filesystem, il team può riunire checkout, installazione, test e build in un unico job. Il vantaggio è operativo: meno passaggi intermedi, meno artefatti parziali e un solo punto da cui riprovare quando la build fallisce.

Questo non rende automaticamente Vercel il fornitore di sandbox giusto. Per chi sta ancora scegliendo il livello di esecuzione, il confronto tra sandbox di codice per agenti AI esamina più in generale i compromessi tra isolamento e fatturazione. Questa release sposta soltanto il limite del disco di Vercel.

Un platform engineer che gestisce riparazioni dei repository

Un coding agent tende ad accumulare dati mentre lavora. Clona il repository, installa gli strumenti, modifica i file, esegue la suite di test e prepara il risultato. Se esplora più soluzioni, può anche lasciare dietro di sé cache e output intermedi.

I 32 GB aggiuntivi danno all'intero ciclo più spazio per concludersi in una sola sandbox. Possono eliminare un nuovo tentativo causato dal disco pieno o uno strumento di pulizia personalizzato dal workflow dell'agente. Il vantaggio è concreto soprattutto quando il problema era davvero il disco. Un job bloccato da memoria, CPU, regole di rete o durata della sessione non ricava alcun beneficio da un filesystem più grande.

Un data engineer con trasformazioni che riversano dati su disco

Un data engineer può usare il filesystem locale come area temporanea mentre una trasformazione ordina, unisce o espande i dati scaricati. Il disco più grande può mantenere locale questo lavoro provvisorio, evitando di suddividerlo in anticipo o di ricorrere a un mount remoto.

Per l'output serve comunque una strategia di uscita. Il risultato durevole va copiato fuori, scritto nell'object store appropriato oppure salvato su un Drive se le esecuzioni successive devono accedere alla stessa directory. Un disco temporaneo da 64 GB è utile proprio perché può essere eliminato. Trattarlo come storage permanente significa confondere due funzioni e due voci di costo diverse.

Un team che usa ancora runtime

La release dell'11 settembre include esplicitamente le sandbox configurate con la proprietà deprecata runtime. Il codice esistente dovrebbe ricevere il disco più grande senza dover migrare l'immagine.

La direzione attuale della piattaforma resta comunque quella delle immagini. A partire dalla versione 3 del Sandbox SDK, una sandbox priva sia di runtime sia di image usa vercel/sandbox/universal:latest. Le immagini gestite vengono aggiornate ogni notte; fissare un digest offre invece un ambiente immutabile quando la riproducibilità delle build è importante.

Misurate un job rappresentativo prima di cambiare il workflow

La release rimuove un limite, ma non indica quanto spazio sia davvero disponibile per la vostra immagine e il vostro job. Prima di eliminare le procedure di pulizia o ricomporre build oggi suddivise, misurate un'esecuzione reale.

1. 1

   Scegliete il job su cui basare la decisione

   Selezionate un job che di recente ha esaurito il disco oppure che oggi viene suddiviso soltanto per restare sotto il vecchio limite. Usate lo stesso repository, lockfile, comando di build e set di dati del percorso di produzione. Un repository dimostrativo non può rispondere alla domanda aziendale.

2. 2

   Avviate una nuova sandbox basata su un'immagine

   Il percorso attuale basato su CLI e immagini rende il risultato più facile da riprodurre. Questa sequenza segue il flusso documentato della Sandbox CLI di Vercel e disattiva la persistenza, così la misurazione non crea automaticamente uno snapshot.

   npm i -g sandbox
   sandbox login
   sandbox create --name workspace-check --image vercel/sandbox/node:24 --timeout 30m --non-persistent
   
   tar -czf app.tgz -C ./my-app .
   sandbox copy ./app.tgz workspace-check:/tmp/app.tgz
   sandbox exec workspace-check -- sh -c "mkdir -p /app && tar -xzf /tmp/app.tgz -C /app"

3. 3

   Registrate ogni fase di utilizzo dello storage

   Eseguite il controllo del disco dopo il checkout, dopo l'installazione delle dipendenze, durante la parte più pesante della build se possibile e quando l'artefatto è completo. Sostituite .next e dist con i percorsi di output realmente usati dal progetto.

   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm install
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm run build
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'

   df -h / mostra quanto spazio resta nella sandbox. Le righe con du indicano quale parte dello spazio di lavoro lo sta consumando. Controllare soltanto al termine della build può nascondere il picco.

4. 4

   Riprovate una volta senza il vecchio espediente

   Se il massimo utilizzo misurato resta entro lo spazio libero riportato, riprovate lo stesso job senza eliminare dipendenze né passare da una build suddivisa. Registrate esito, tempo trascorso, Active CPU, memoria allocata, trasferimento e l'eventuale creazione di storage per snapshot o Drive. Poi arrestate la sandbox.

   sandbox stop workspace-check

I limiti da non perdere di vista

Più spazio su disco non significa più memoria, CPU o tempo. Una sessione Sandbox ha ancora una durata predefinita di 5 minuti. Le sessioni Hobby possono durare fino a 45 minuti, mentre quelle Pro ed Enterprise possono arrivare a 24 ore.

La release non garantisce neppure che ogni carico inferiore a 64 GB riesca a funzionare senza problemi. L'immagine iniziale occupa una parte del filesystem e i tag delle immagini mobili possono cambiare con gli aggiornamenti notturni pubblicati da Vercel. Controllate lo spazio libero effettivo dopo l'avvio. Se la stessa build deve partire ogni volta dallo stesso ambiente, fissate il digest dell'immagine.

Se un job richiede dati durevoli e condivisi, usate un Drive o un altro archivio persistente. Se richiede più spazio di lavoro di quello indicato dalla sandbox, mantenete la suddivisione, spostate il grande insieme di dati temporanei su uno storage montato oppure eseguitelo altrove. Il nuovo limite cambia la soglia, non la natura delle alternative.

Cosa fare lunedì

Intervenite questa settimana se un vero job di repository, agente o dati si è fermato al vecchio limite del disco, oppure se contiene procedure di pulizia create soltanto per evitarlo. Se non avete misurato il picco, aspettate: eliminare alla cieca una suddivisione funzionante non fa che rimandare il prossimo errore. La modifica non vi riguarda se il job resta già ampiamente sotto la capacità precedente o se il collo di bottiglia reale è CPU, memoria, accesso alla rete, durata della sessione o storage durevole.

Lunedì scegliete un job rappresentativo, eseguite la misurazione descritta sopra in una Sandbox nuova da 64 GB basata su un'immagine e riprovatelo una volta senza il vecchio espediente per lo storage. Conservate il percorso più semplice con un solo job soltanto se l'esecuzione misurata arriva in fondo e il costo complessivo di calcolo e persistenza resta sostenibile.

Per ricevere altre analisi in linguaggio chiaro sui cambiamenti che incidono davvero sui costi operativi, iscrivetevi alla newsletter.