Rétention des déploiements Vercel : les 30 jours ne sont plus garantis

La rétention des déploiements Vercel Hobby ne garantit plus la disponibilité des versions pendant 30 jours. Depuis le 16 septembre 2026, dès qu’une équipe Hobby dépasse sa limite de 10GB de Deployment Storage, un ancien déploiement de prévisualisation ou une version de production utilisable pour un rollback peut être supprimé immédiatement s’il ne bénéficie d’aucune exception de conservation.

Le déploiement actuellement en production reste protégé. C’est aussi le cas des déploiements associés à certains alias et de la dernière prévisualisation d’une branche Git active. Le changement concerne tout ce qui ne relève pas de ces catégories : un prototype personnel peut donc continuer à fonctionner tandis qu’un ancien lien de validation cesse discrètement de répondre.

Rétention des déploiements Vercel : 30 jours ne sont plus un minimum

La politique de rétention détermine combien de temps Vercel conserve les fichiers générés pour chaque déploiement. Ce sont ces fichiers stockés qui permettent de rouvrir une ancienne prévisualisation, de promouvoir une version déjà testée sans la reconstruire ou de restaurer la production en cas d’incident.

Sur Hobby, la durée de rétention habituelle reste fixée à 30 jours. La nouveauté concerne le nettoyage en cas de dépassement : une fois l’équipe au-dessus de 10GB de Deployment Storage, tout déploiement non protégé peut être supprimé avant l’expiration de ces 30 jours. Voilà la conséquence concrète de cette évolution. L’historique gratuit dépend désormais à la fois du stockage consommé et des exceptions détaillées ci-dessous.

Chaque projet Hobby bénéficie de deux protections liées aux déploiements récents :

• Les 3 derniers déploiements créés, tous types confondus
• Les 3 derniers déploiements de production au statut Ready

Il faut les considérer comme un seul ensemble, pas comme six emplacements réservés. Un déploiement de production récent peut appartenir aux deux groupes. Si les trois déploiements les plus récents correspondent aussi aux trois dernières mises en production Ready, seules ces trois mêmes versions sont protégées par ces deux règles.

Les déploiements de prévisualisation n’ont plus de protection distincte au titre de leur récence. Une prévisualisation qui ne figure pas parmi les trois dernières n’est conservée que si une autre exception s’applique.

Ce que Vercel continue de protéger

Pour comprendre la règle, le plus simple consiste à distinguer les protections liées à la date du déploiement de celles qui dépendent de son usage.

Vercel détaille ces exceptions dans ses règles actuelles de rétention des déploiements. Enregistrer l’URL d’un déploiement ne fait pas partie des protections recensées. Ce qui compte, c’est son association à un alias, une branche, l’état de production ou une place parmi les versions récentes.

Cette nuance change un workflow courant. Vous pouvez envoyer une prévisualisation, fusionner la pull request, puis penser que le lien restera disponible jusqu’à la fin du mois. Or, dès que la branche n’est plus active, l’exception protégeant sa dernière prévisualisation prend fin. Si l’équipe dépasse déjà 10GB et que le déploiement ne figure dans aucun des deux groupes de trois, le lien peut perdre sa cible avant le 30e jour.

Qui est réellement concerné ?

Le cas le plus évident est celui d’une personne qui maintient plusieurs prototypes personnels. D’anciens projets peuvent conserver des fichiers de build pendant que les projets actifs multiplient les déploiements. Une fois la limite de l’équipe franchie, Vercel peut nettoyer l’historique non protégé de toute cette équipe Hobby. La version de rollback importante peut donc appartenir à un projet qui n’a pas été modifié récemment.

Pour un designer qui partage un concept non commercial, le risque est différent. La prévisualisation actuelle d’une branche de validation ouverte reste protégée, contrairement à l’ancien lien qui documente une décision de design antérieure. Si cette version précise doit rester consultable, il faut lui attribuer un alias personnalisé éligible ou prévoir une autre méthode de conservation avant la fermeture de la branche.

Une personne qui utilise les déploiements comme réserve de rollbacks doit examiner l’historique récent de production. Les 3 derniers déploiements de production Ready restent protégés. En revanche, une version stable plus ancienne n’est pas à l’abri simplement parce qu’elle date de moins de 30 jours.

Un freelance, une agence ou une entreprise ne devrait pas décider d’une montée en gamme sur le seul critère de la rétention. Hobby est réservé aux usages personnels et non commerciaux. Un projet commercial relève de Pro, même s’il reste sous les 10GB : cette évolution de l’historique des déploiements ne fait que renforcer une distinction qui existait déjà entre les offres.

Les équipes Hobby qui restent sous 10GB ne sont pas concernées par ce nouveau nettoyage immédiat. Leurs déploiements suivent toujours la politique habituelle de 30 jours et ses exceptions. Cette modification propre à Hobby ne concerne pas non plus les équipes Pro et Enterprise, dont les durées de rétention par défaut et le nombre de déploiements récents protégés sont plus élevés.

Auditer l’historique qui compte encore

Commencez au niveau de l’équipe. La limite de 10GB s’applique à l’équipe Hobby, tandis que les informations utiles sont réparties entre les projets.

1. 1

   Vérifier les deux indicateurs de stockage

   Sélectionnez la bonne équipe dans Vercel, ouvrez Usage, puis choisissez Deployment Storage. Examinez à la fois Deployment Storage, qui couvre les fichiers de build et les ressources statiques, et Functions Storage, qui correspond aux bundles de fonctions. Sous chaque indicateur, ouvrez Projects afin de repérer les projets qui occupent le plus d’espace.

2. 2

   Lister les déploiements à ne pas perdre

   Pour chaque projet volumineux, ouvrez Deployments. Notez le déploiement actuellement en production, la version de production vers laquelle vous reviendriez réellement, toute URL de prévisualisation encore utilisée dans un circuit de validation ou d’approbation, ainsi que toute ancienne version nécessaire à un audit ou à un test de régression. Cette liste exprime le besoin ; le flux des déploiements ne constitue qu’un inventaire.

3. 3

   Associer chaque version à conserver à une protection

   Vérifiez si chaque version figure parmi les 3 dernières créées, parmi les 3 derniers déploiements de production Ready, si elle porte un alias éligible ou si elle correspond à la dernière prévisualisation d’une branche active. Ne comptez pas séparément les deux groupes de trois lorsqu’un même déploiement appartient aux deux.

4. 4

   Préserver l’exception ou les sources

   Laissez une branche de validation active tant que sa dernière prévisualisation reste nécessaire. Attribuez un alias personnalisé à un déploiement hors production qu’il faut impérativement conserver, si le workflow s’y prête. Pour le reste, assurez-vous que le commit source, la configuration et les données externes indispensables à la reconstruction sont disponibles ailleurs que dans l’historique des déploiements.

5. 5

   Retirer ce qui n’a plus d’utilité

   Une fois l’accord des responsables obtenu, supprimez les alias personnalisés obsolètes et fermez les pull requests qui ne servent plus, en suivant le processus habituel du dépôt. Consultez ensuite la vue Resources du plus gros déploiement pour identifier des ressources statiques ou des bundles de fonctions trop volumineux. La page Usage permet de repérer un projet, mais pas le fichier, le déploiement ou le bundle précis à l’origine du total.

Le guide d’optimisation du stockage de Vercel recommande de comparer la même équipe, les deux indicateurs de stockage, les mêmes projets et la même période de 30 jours après une modification. Le nettoyage lié à la rétention et la réduction du poids des builds répondent à deux problèmes différents. Le premier diminue progressivement l’historique stocké ; la seconde allège les nouveaux déploiements.

Nettoyer ou passer à Pro : deux calculs différents

Pour un projet personnel et non commercial, le nettoyage est l’option sans abonnement. Il consiste à abandonner l’historique qui n’a plus d’utilité, à réduire autant que possible la taille des fichiers générés et à rester sous la limite Hobby. La contrepartie est opérationnelle : moins d’anciennes prévisualisations à consulter et moins de versions de production disponibles pour un rollback.

Pro n’est pas une simple option à $0.10. Sur cette offre, Deployment Storage et Functions Storage sont chacun affichés à $0.10 par GB-mois ; conserver 10GB d’un seul de ces indicateurs pendant un mois revient donc à $1 au tarif catalogue. Mais l’offre commence par des frais de plateforme mensuels de $20, qui incluent un siège autorisé à déployer et $20 de crédit mensuel d’utilisation de l’infrastructure. Chaque siège Owner ou Member supplémentaire autorisé à déployer ajoute $20 par mois. Les sièges Viewer sont gratuits.

La règle de décision devient simple. Il ne faut pas comparer « supprimer de l’historique » à « payer $1 de stockage », mais le nettoyage à l’abonnement mensuel complet de $20. Ajoutez ensuite chaque personne supplémentaire qui déploie et vérifiez si le crédit inclus absorbe réellement le stockage et les autres usages d’infrastructure de l’équipe. Le détail complet des tarifs Vercel explique le reste de la facture.

Pour un prototype personnel, $20 par mois peuvent coûter plus cher que l’historique conservé ne le justifie. Pour un projet commercial, les conditions d’éligibilité à l’offre règlent la question avant la politique de rétention. Pour une entreprise avec une seule personne chargée des déploiements et qui a déjà besoin de Pro, les durées de rétention supérieures et la protection accrue des déploiements récents font partie de la valeur déjà achetée.

Ce qu’il faut faire lundi

Si votre équipe Hobby dépasse les 10GB ou s’en approche, commencez par la page Usage et identifiez les projets qui occupent le plus de Deployment Storage et de Functions Storage. Repérez ensuite les liens de prévisualisation et les versions de rollback qui répondent encore à un besoin métier ou de validation précis. Protégez-les explicitement et laissez disparaître l’historique devenu inutile.

Si l’équipe reste largement sous les 10GB, aucun nettoyage urgent ne s’impose. Gardez simplement à l’esprit la politique habituelle de 30 jours, notamment avant de fermer une branche dont dépend une prévisualisation encore utilisée.

Si le projet est commercial, le nettoyage de Hobby ne constitue pas une stratégie durable. Prévoyez le coût total de Pro, réservez les droits de déploiement aux personnes qui en ont besoin, utilisez les sièges Viewer gratuits pour les autres et comparez cette facture au coût de reconstruction d’un workflow de validation ou de rollback disparu.

Pour recevoir chaque semaine une analyse aussi claire, abonnez-vous à la newsletter.