Vercel Hobby oltre 10GB: la regola dei 30 giorni non basta più

La cronologia dei deployment di Vercel Hobby per 30 giorni non è più una garanzia su cui fare affidamento per i rollback. Dal 16 settembre 2026, se un team Hobby supera il limite di 10GB di Deployment Storage, una vecchia preview o un deployment di produzione da usare per il rollback può essere eliminato subito, a meno che non rientri in una delle eccezioni previste.

Il deployment attualmente in produzione resta al sicuro. Lo stesso vale per i deployment associati ad alias idonei e per la preview più recente di ogni branch Git attivo. La modifica riguarda tutto ciò che non appartiene a questi gruppi protetti: ecco perché un prototipo personale può continuare a funzionare mentre un vecchio link di revisione smette silenziosamente di aprirsi.

Con Vercel Hobby, i 30 giorni non sono più garantiti

La conservazione dei deployment stabilisce per quanto tempo Vercel mantiene i file generati per ciascun deployment. Sono proprio quei file a consentire di riaprire una vecchia preview, portare in produzione una build già verificata senza ricompilarla o ripristinare una versione precedente durante un incidente.

Per Hobby, l'intervallo di conservazione ordinario rimane di 30 giorni. La novità è la regola di pulizia applicata oltre il limite: quando il team supera 10GB di Deployment Storage, un deployment privo di protezione può diventare eliminabile prima che siano trascorsi i 30 giorni. Questa è la conseguenza concreta del cambiamento. La cronologia gratuita dei deployment dipende ora sia dallo spazio utilizzato sia dalle eccezioni elencate di seguito.

Ogni progetto Hobby conserva due protezioni basate sui deployment più recenti:

• Gli ultimi 3 deployment creati, indipendentemente dal tipo
• Gli ultimi 3 deployment di produzione con stato Ready

Vanno considerati come un unico insieme, non come sei posti riservati. Un deployment di produzione recente può appartenere a entrambi i gruppi. Se i tre deployment più nuovi coincidono con le tre release di produzione Ready più recenti, queste due regole proteggono soltanto quegli stessi tre deployment.

Le preview non dispongono più di una quota separata riservata alle più recenti. Una preview che non rientra nelle ultime tre sopravvive solo se è coperta da un'altra eccezione.

Quali deployment Vercel continua a proteggere

Il modo più semplice per interpretare la regola è distinguere le protezioni legate alla recenza da quelle che dipendono dall'uso effettivo del deployment.

Vercel specifica queste eccezioni nelle sue attuali regole di conservazione dei deployment. Salvare l'URL di un deployment, da solo, non rientra tra le protezioni elencate. Ciò che conta è la relazione del deployment con un alias, un branch, lo stato di produzione o la sua posizione tra i più recenti.

Questa distinzione cambia un flusso di lavoro molto comune. Si può inviare una preview, unire la pull request e dare per scontato che il link resti disponibile per il resto del mese. Quando il branch non è più attivo, però, termina anche l'eccezione che protegge la sua ultima preview. Se il team ha già superato 10GB e il deployment è fuori da entrambi gli insiemi degli ultimi tre, il link può perdere la propria destinazione prima del giorno 30.

Chi è davvero interessato dal cambiamento

Il caso più evidente è quello di uno sviluppatore indipendente con diversi prototipi personali. I vecchi progetti possono continuare a occupare spazio con gli output delle build mentre quelli attivi generano nuovi deployment. Una volta superato il limite del team, Vercel può cancellare la cronologia non protetta nell'intero team Hobby; il deployment utile per un rollback potrebbe quindi appartenere proprio a un progetto che non viene aperto da tempo.

Per un designer che condivide un concept non commerciale, il rischio è diverso. La preview corrente di un branch di revisione ancora aperto è protetta; il vecchio link usato per una decisione di design precedente potrebbe non esserlo. Se quella specifica build deve restare consultabile, prima di chiudere il branch occorre assegnarle un alias personalizzato idoneo oppure adottare un altro metodo di conservazione.

Chi usa i deployment come archivio per i rollback dovrebbe controllare l'insieme delle release di produzione recenti. Gli ultimi 3 deployment di produzione Ready restano protetti, ma una release stabile più vecchia non è al sicuro solo perché ha meno di 30 giorni.

Freelance, agenzie e aziende non dovrebbero basare la decisione di passare a un piano superiore sulla sola conservazione. Hobby è riservato all'uso personale e non commerciale. I progetti commerciali richiedono Pro anche quando restano sotto 10GB: il cambiamento nella cronologia dei deployment rafforza quindi una scelta di piano già prevista.

I team Hobby sotto 10GB non rientrano nel nuovo meccanismo di pulizia immediata. I loro deployment continuano a seguire la normale politica di 30 giorni e le relative eccezioni. Anche i team Pro ed Enterprise non sono coinvolti da questa specifica modifica a Hobby: le finestre di conservazione predefinite e il numero di deployment recenti protetti sono maggiori.

Come verificare la cronologia dei deployment da conservare

Conviene partire dal livello del team. Il limite di 10GB si applica al team Hobby, mentre le informazioni utili sono distribuite tra i vari progetti.

1. 1

   Controlla entrambi i contatori dello storage

   Seleziona il team corretto in Vercel, apri Usage, quindi scegli Deployment Storage. Controlla sia Deployment Storage, che comprende output delle build e asset statici, sia Functions Storage, che include i bundle delle funzioni. In ciascuna metrica, apri Projects per individuare i progetti che occupano più spazio.

2. 2

   Annota i deployment che non puoi perdere

   Per ogni progetto di grandi dimensioni, apri Deployments. Registra il deployment attualmente in produzione, la build di produzione che useresti davvero per un rollback, ogni URL di preview ancora inserito in un processo di revisione o approvazione e le vecchie build necessarie per audit o verifiche di regressione. È questo elenco a definire i requisiti; il feed dei deployment è soltanto l'inventario.

3. 3

   Associa ogni deployment da conservare a una protezione

   Verifica se ciascun deployment è tra gli ultimi 3 creati, tra gli ultimi 3 deployment di produzione Ready, se dispone di un alias idoneo oppure se è la preview più recente di un branch attivo. Quando lo stesso deployment compare in entrambi, non contare separatamente i due gruppi degli ultimi tre.

4. 4

   Conserva l'eccezione oppure conserva il sorgente

   Mantieni attivo il branch di revisione finché serve la sua ultima preview. Se è compatibile con il flusso di lavoro, assegna un alias personalizzato ai deployment non di produzione che devono rimanere disponibili. Per tutti gli altri, assicurati che il commit sorgente, la configurazione e i dati esterni necessari a ricostruirli siano disponibili al di fuori della cronologia dei deployment.

5. 5

   Elimina lo spazio che non ha più uno scopo

   Dopo aver concordato con i responsabili che cosa può essere rimosso, elimina gli alias personalizzati obsoleti e chiudi le pull request inattive secondo il normale processo del repository. Esamina poi la vista Resources del deployment più grande per trovare output statici o bundle di funzioni eccessivi. La pagina Usage può indicare il progetto, ma non il singolo file, deployment o bundle responsabile del totale.

La guida di Vercel all'ottimizzazione dello storage consiglia, dopo ogni modifica, di confrontare lo stesso team, entrambe le metriche di storage, gli stessi progetti e il medesimo intervallo di 30 giorni. La pulizia dovuta alla conservazione e la riduzione dell'output di build risolvono problemi diversi: la prima diminuisce nel tempo la cronologia archiviata, la seconda rende più piccoli i nuovi deployment.

Pulizia e Pro cambiano voci diverse del costo

Per un progetto personale e non commerciale, la pulizia è l'opzione senza costi di abbonamento. Si rinuncia alla cronologia che non serve più, si riduce dove possibile la dimensione dell'output e si rimane entro il limite Hobby. Il prezzo da pagare è operativo: meno vecchie preview da consultare e meno build di produzione disponibili per un rollback.

Pro non è un upgrade da $0.10. Su Pro, Deployment Storage e Functions Storage hanno ciascuno un prezzo di listino pari a $0.10 per GB-month; mantenere 10GB di una delle due metriche per un mese intero costa quindi $1 a listino. Il piano parte però da una tariffa mensile di piattaforma di $20, che comprende un utente con autorizzazione al deployment e $20 di credito mensile per l'utilizzo dell'infrastruttura. Ogni ulteriore utente Owner o Member autorizzato al deployment aggiunge altri $20 al mese. Gli account Viewer sono gratuiti.

La regola decisionale diventa così semplice. Il confronto corretto non è tra «eliminare la cronologia» e «pagare $1 per lo storage», ma tra la pulizia e l'intero piano mensile da $20. Vanno poi aggiunti tutti gli utenti che effettuano deployment e va verificato se il credito incluso copre lo storage effettivo del team e gli altri consumi dell'infrastruttura. L'analisi completa dei prezzi di Vercel spiega le altre voci della fattura.

Per un prototipo personale, $20 al mese potrebbero valere più della cronologia che si vuole salvare. Nei progetti commerciali, l'idoneità al piano risolve la questione prima ancora della conservazione. Per un'attività con un solo sviluppatore che ha già bisogno di Pro, le finestre di conservazione più ampie e le maggiori protezioni per i deployment recenti fanno parte del valore già acquistato.

Cosa fare lunedì

Se il team Hobby è sopra o vicino a 10GB, parti dalla pagina Usage e individua i progetti che occupano più Deployment Storage e Functions Storage. Segna poi i link di preview e i deployment di rollback che hanno ancora uno scopo operativo o di revisione. Proteggili in modo esplicito e lascia che la cronologia ormai inutile venga eliminata.

Se il team è ampiamente sotto 10GB, non serve alcuna pulizia urgente. Tieni presente la normale politica di 30 giorni, soprattutto quando chiudi un branch a cui appartiene una preview ancora necessaria a qualcuno.

Se il progetto è commerciale, non considerare la pulizia di Hobby una strategia a lungo termine. Metti a budget l'intero costo di Pro, assegna l'accesso al deployment solo a chi ne ha bisogno, usa gli account Viewer gratuiti per tutti gli altri e confronta la spesa con il costo di ricostruire un flusso di revisione o rollback ormai perso.

Per ricevere ogni settimana un'analisi chiara come questa, iscriviti alla newsletter.