Stockage Vercel Sandbox : 64 GB pour les jobs d’agents IA

Le vrai sujet n’est pas « 64 GB » pris isolément. Avec le stockage Vercel Sandbox porté à ce niveau, un job de dépôt qui butait jusque-là sur la limite de 32 GB peut désormais aller au bout dans une seule machine, sans élagage, découpage ni migration vers un autre environnement.

Le 11 septembre 2026, Vercel a doublé le stockage de travail par défaut de chaque Sandbox, qui passe de 32 GB à 64 GB.

Stockage Vercel Sandbox : deux fois plus d’espace par machine

Vercel Sandbox est une microVM Linux isolée, autrement dit une petite machine virtuelle avec son propre noyau, son propre système de fichiers et son propre réseau. On peut lui confier un dépôt, laisser un agent modifier le code, installer des paquets, lancer les tests, produire un build, puis récupérer le résultat.

Toutes ces étapes sollicitent le même disque local. Le checkout peut encore l’occuper lorsque l’arbre des dépendances s’installe. Les caches de build et les fichiers compilés peuvent cohabiter avec les fichiers temporaires. L’artefact final peut être léger alors que sa fabrication réclame brièvement beaucoup plus d’espace.

C’est ce pic que la mise à jour vient relever. Vercel alloue désormais 64 GB de stockage de travail à la Sandbox au lieu de 32 GB : 32 GB supplémentaires, soit deux fois la capacité précédente. Le changement concerne les sandboxes créées depuis une Vercel Managed Image, une image personnalisée ou la propriété runtime, désormais obsolète.

Il s’agit de capacité à l’intérieur de la Sandbox, pas d’un nouveau quota de base de données ou de stockage objet. Vercel parle de stockage NVMe éphémère. Si les fichiers doivent survivre au job, la décision de persistance reste un sujet distinct.

La vraie décision : le job tient-il dans une seule Sandbox ?

La question utile dans la durée n’est pas « quelle est la limite disque de Vercel ? », mais « ce job peut-il s’exécuter en entier dans une seule Sandbox, sans nettoyage particulier ni passage de relais ? »

Pour le savoir, partez d’un budget d’espace de travail simple :

Pic d’espace de travail = dépôt et checkout + dépendances installées + artefacts de build + pic de données temporaires

Mesurez le point haut pendant l’exécution. La taille du fichier zip final ne suffit pas pour l’estimer. Extraction des paquets, compilation, jeux de données de test, binaires de navigateur, caches et débordement de données peuvent ne se chevaucher que quelques minutes ; ce sont pourtant ces quelques minutes qui déterminent si le run aboutira.

Les tarifs et quotas actuels de Vercel séparent les différentes couches de stockage dans le budget :

Cette distinction change le calcul économique. Doubler le disque de travail ne double pas le tarif du calcul. Dans l’exemple actuel de Vercel pour iad1, un run de build et de test de 30 minutes, avec 4 vCPUs et 8 GB de mémoire, revient à environ $0.34 lorsque le CPU est utilisé à plein régime.

Un job plus volumineux peut tout de même coûter davantage s’il dure plus longtemps ou exige plus de CPU et de mémoire. Les téléchargements de paquets, dépôts, artefacts ou jeux de données sont gratuits ; les données envoyées hors de la Sandbox sont, elles, facturées.

C’est la persistance qui peut transformer les fichiers supplémentaires en nouvelle ligne de coût. Si un run utilisait et conservait la totalité des 32 GB désormais disponibles en plus pendant un mois complet, le calcul au tarif publié serait 32 × $0.08 = $2.56 par mois de snapshot. Il s’agit d’une illustration, pas d’un prélèvement automatique. Un run non persistant qui exporte son résultat puis supprime l’espace de travail évite ce coût de snapshot.

À qui profite cet espace supplémentaire ?

Un staff engineer face à un grand monorepo

Aujourd’hui, un staff engineer peut être contraint d’élaguer des paquets, de supprimer des jeux de données de test ou de scinder un build, simplement parce que le dépôt, le graphe de dépendances et les sorties de compilation ne tiennent pas ensemble sous l’ancien plafond.

Si le pic mesuré tient maintenant dans le système de fichiers de 64 GB disponible, l’équipe peut réunir checkout, installation, tests et build dans un seul job. Le bénéfice est opérationnel : moins de passages de relais, moins d’artefacts partiels et un seul point de reprise en cas d’échec du build.

Cela ne fait pas automatiquement de Vercel le meilleur fournisseur de Sandbox. Si la couche d’exécution reste à choisir, le comparatif des sandboxes de code pour agents IA détaille les arbitrages d’isolation et de facturation. Cette mise à jour ne déplace que la limite disque de Vercel.

Un ingénieur de plateforme qui automatise la réparation de dépôts

Un agent de code accumule souvent des données au fil de son travail. Il clone le dépôt, installe les outils, modifie les fichiers, exécute la suite de tests, puis prépare le résultat. S’il explore plusieurs pistes, il peut aussi laisser derrière lui des caches et des sorties intermédiaires.

Les 32 GB supplémentaires donnent davantage de marge à toute cette boucle pour s’achever dans une seule Sandbox. Ils peuvent éviter une relance après saturation du disque ou supprimer un outil de nettoyage spécifique du workflow de l’agent. Le gain n’existe toutefois que si le disque était réellement en cause. Un job bloqué par la mémoire, le CPU, la politique réseau ou la durée de session ne tirera aucun avantage d’un système de fichiers plus grand.

Un data engineer dont le traitement déborde sur disque

Un data engineer peut employer le système de fichiers local comme espace temporaire lorsqu’un traitement trie, joint ou développe des données téléchargées. Le disque plus grand peut maintenir ces opérations en local, au lieu d’imposer une découpe anticipée ou un montage distant.

La sortie doit malgré tout avoir une destination. Copiez le résultat durable vers l’extérieur, écrivez-le dans le stockage objet adapté ou montez un Drive si des runs ultérieurs doivent retrouver le même répertoire. Un disque temporaire de 64 GB est utile précisément parce qu’il peut être jeté. Le traiter comme un stockage permanent revient à mélanger deux usages et deux factures.

Une équipe qui utilise encore runtime

La publication du 11 septembre inclut explicitement les sandboxes configurées avec la propriété runtime, désormais obsolète. Le code existant devrait donc bénéficier du disque plus grand sans migration d’image.

La plateforme s’oriente néanmoins vers les images. À partir de la version 3 du Sandbox SDK, une Sandbox qui ne précise ni runtime ni image utilise vercel/sandbox/universal:latest. Les images gérées sont actualisées chaque nuit ; épingler un digest permet de figer l’environnement lorsque la reproductibilité des builds est déterminante.

Mesurez un job représentatif avant de modifier le workflow

La mise à jour relève un plafond ; elle ne dit pas de combien d’espace votre image et votre job disposent réellement. Mesurez un run réel avant de retirer les étapes de nettoyage ou de réunir des builds jusque-là séparés.

1. 1

   Choisissez le job qui permettra de trancher

   Prenez un job qui a récemment saturé le disque, ou que vous découpez aujourd’hui uniquement pour rester sous l’ancienne limite. Reprenez le même dépôt, le même lockfile, la même commande de build et les mêmes données d’entrée que sur le parcours de production. Un dépôt jouet ne répondra pas à la question économique.

2. 2

   Démarrez une nouvelle Sandbox basée sur une image

   La CLI actuelle et le parcours par image facilitent la reproduction du résultat. La séquence ci-dessous suit le workflow documenté du Sandbox CLI de Vercel et désactive la persistance, afin que la mesure ne crée pas automatiquement de 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

   Relevez l’occupation à chaque étape

   Contrôlez le disque après le checkout, après l’installation des dépendances, pendant la phase la plus lourde du build si possible, puis une fois l’artefact terminé. Remplacez .next et dist par les chemins de sortie réellement utilisés par votre projet.

   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 / indique l’espace encore disponible dans la Sandbox. Les lignes du montrent quelle partie de l’espace de travail le consomme. Un contrôle limité à la fin du build peut passer à côté du pic.

4. 4

   Retentez une fois sans l’ancien contournement

   Si le point haut mesuré reste dans l’espace libre indiqué, relancez le même job sans élagage des dépendances ni passage de relais entre builds. Consignez la réussite, le temps écoulé, l’Active CPU, la mémoire provisionnée, les transferts et la création éventuelle d’un snapshot ou d’un stockage Drive. Arrêtez ensuite la Sandbox.

   sandbox stop workspace-check

La limite à garder en tête

Plus de disque n’apporte ni mémoire, ni CPU, ni temps supplémentaires. Une session Sandbox dure toujours 5 minutes par défaut. Les sessions Hobby peuvent atteindre 45 minutes, contre 24 heures pour les offres Pro et Enterprise.

La mise à jour ne garantit pas non plus que n’importe quelle charge inférieure à 64 GB s’exécutera sans difficulté. L’image de départ occupe une partie du système de fichiers, et les tags d’image non figés peuvent évoluer au rythme des mises à jour nocturnes de Vercel. Vérifiez l’espace réellement libre après le démarrage. Épinglez le digest de l’image si un même build doit toujours partir du même environnement.

Si un job a besoin de données durables et partagées, utilisez un Drive ou un autre stockage persistant. S’il réclame plus d’espace de travail que la Sandbox n’en annonce, conservez la découpe, déplacez le gros volume temporaire vers un stockage monté ou exécutez-le ailleurs. La nouvelle limite déplace le seuil ; elle ne change pas la nature de ces options.

Ce qu’il faut faire lundi

Agissez cette semaine si un vrai job de dépôt, d’agent ou de données a échoué sur l’ancienne limite disque, ou s’il comporte du code de nettoyage uniquement pour l’éviter. Attendez si le pic n’a pas été mesuré : retirer une découpe qui fonctionne sur la base d’une intuition ne fait que repousser la prochaine panne. Rien ne change pour vous si le job restait déjà largement sous l’ancienne capacité, ou si son véritable goulet d’étranglement est le CPU, la mémoire, l’accès réseau, la durée de session ou le stockage durable.

Lundi, prenez un job représentatif, exécutez les mesures ci-dessus dans une nouvelle Sandbox de 64 GB basée sur une image, puis retentez-le une fois sans l’ancien contournement de stockage. Ne conservez le parcours simplifié en un seul job que si l’exécution mesurée aboutit et que la facture totale de calcul et de persistance reste cohérente.

Pour recevoir d’autres analyses en français, sans jargon inutile, sur les changements qui modifient vraiment l’équation opérationnelle, inscrivez-vous à la newsletter.