Vercel Sandbox Drive : un stockage persistant pour les agents de code

En bref

Créez un Drive une seule fois avec Drive.getOrCreate(), transmettez-le à Sandbox.create() sous un chemin de montage absolu comme /data, puis conservez tous les fichiers durables à cet emplacement. Arrêtez la première sandbox avant qu’une autre ne demande un accès en lecture-écriture. Pour lancer des sandboxes de test ou de revue en parallèle, montez plutôt drive.snapshot(). Ces lecteurs obtiennent une vue figée et ne verront pas les écritures ultérieures.

Un Drive ressemble davantage à une salle de projet détachable qu’à un disque dur plus grand installé dans une machine. La sandbox représente l’équipe et l’atelier temporaires. Le Drive est la réserve fermée qui reste en place après leur départ et peut être rattachée à l’atelier suivant.

Vercel destine notamment Drives aux espaces de travail d’agents, à la mémoire sur disque, aux arborescences de dépendances, aux jeux de données, aux modèles et aux artefacts de build. Parmi les premiers utilisateurs, l’un d’eux a également indiqué qu’un Drive par agent permettait d’éviter de réinstaller les dépendances après une reconnexion. C’est le bénéfice qu’il faut mesurer : moins de préparation, pas seulement davantage de stockage.

Configurer un espace persistant avec Vercel Sandbox Drive

Commencez avec un projet Vercel et une authentification locale. Vercel recommande un jeton OIDC pour le développement local. vercel env pull écrit ce jeton de développement dans .env.local, et celui-ci expire après 12 heures. Un système de CI externe peut utiliser à la place un ID d’équipe, un ID de projet et un jeton d’accès.

À la date de publication, la version npm stable est @vercel/sandbox 3.5.0. Certaines pages plus anciennes du SDK Vercel parlent encore de bêta privée et recommandent le canal bêta, mais la page de présentation de Drive actuelle et l’annonce du 23 septembre confirment une bêta publique sur les trois offres.

npm install @vercel/sandbox@3.5.0
npx vercel link
npx vercel env pull

Créez maintenant un Drive, montez-le, écrivez-y un fichier témoin et un petit cache, arrêtez la sandbox, puis lisez ces deux fichiers depuis une nouvelle sandbox :

import { Drive, Sandbox } from '@vercel/sandbox';

const workspace = await Drive.getOrCreate({
  name: 'agent-workspace',
  region: 'iad1',
});

const first = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

await first.runCommand('bash', [
  '-lc',
  "mkdir -p /data/.cache/demo && printf 'ready\\n' > /data/marker.txt && printf 'cached\\n' > /data/.cache/demo/package.txt",
]);
await first.stop();

const next = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

const check = await next.runCommand('bash', [
  '-lc',
  'cat /data/marker.txt /data/.cache/demo/package.txt',
]);
console.log(await check.stdout());
await next.stop();

persistent: false permet de concentrer cet exemple sur le Drive. Une sandbox persistante dispose de son propre mécanisme de reprise fondé sur des snapshots, tandis qu’un Drive reste un répertoire indépendant qui peut passer d’une sandbox à une autre. Les deux peuvent être combinés pour disposer à la fois d’un environnement de base réutilisable et d’un dossier de projet qui évolue séparément.

Les quatre vérifications indispensables

Le scénario nominal confirme la persistance. Les quatre vérifications suivantes montrent comment l’architecture se comporte lorsque plusieurs tâches accèdent au même espace de travail.

1. Vérifier que l’espace de travail survit à une nouvelle sandbox

Écrivez le fichier témoin et le cache sous /data, arrêtez la sandbox qui écrit, puis créez une autre sandbox avec le même Drive. Lisez les fichiers depuis /data. Les fichiers placés ailleurs dans la première sandbox ne prouvent pas la persistance du Drive.

Relevez quatre durées pour votre propre tâche : création de la première sandbox, installation initiale des dépendances, premier arrêt, puis création de la nouvelle sandbox avec réutilisation du cache. La valeur utile correspond au temps de préparation supprimé lors de la deuxième exécution. Un Drive qui conserve les fichiers sans accélérer la tâche réelle peut rester pratique, mais il ne modifie pas le budget de calcul.

2. Vérifier qu’un ancien lecteur conserve son ancienne vue

Écrivez un premier fichier témoin, arrêtez la sandbox qui écrit, puis créez un lecteur avec mounts: { '/data': workspace.snapshot() }. Laissez ce lecteur actif. Montez le Drive en lecture-écriture dans une autre sandbox, remplacez le contenu du fichier témoin, puis arrêtez la sandbox qui écrit. Le lecteur déjà actif doit toujours renvoyer la valeur d’origine, car sa vue a été figée au montage. Créez un nouveau lecteur sur snapshot pour voir la nouvelle valeur.

Le bon modèle mental est celui d’une photographie, pas d’un miroir en direct. L’appel à snapshot() décrit le montage en lecture seule ; la vue à un instant donné est établie lorsque la sandbox de lecture le monte. Il faut aussi avoir écrit au moins une fois sur un Drive avant de pouvoir monter un snapshot. Un Drive vierge renvoie drive_not_initialized.

3. Vérifier que le deuxième accès en écriture est refusé

Gardez une sandbox en lecture-écriture active et tentez d’en créer une autre avec le même Drive, elle aussi en lecture-écriture. Vercel n’autorise qu’un seul montage en lecture-écriture à la fois. Ne transformez pas cet échec attendu en rafale de nouvelles tentatives. Placez un bail ou une file d’attente devant les tâches d’écriture, arrêtez proprement le propriétaire, puis utilisez Drive.list() ou currentSandboxName pour retrouver le rattachement si nécessaire.

La documentation Vercel consultée ne fournit pas de code d’erreur stable pour ce cas de deuxième écriture. Considérez l’échec de création de la sandbox comme le contrat et n’appuyez pas la logique de production sur un nom de code supposé.

4. Vérifier que la région principale correspond

Créez le Drive dans iad1, puis tentez de le monter dans une sandbox dont la région principale est sfo1. Vercel documente cette incompatibilité sous le code drive_region_mismatch. La région d’un Drive ne peut pas être modifiée après sa création. De plus, appeler getOrCreate() avec le même nom mais une région ou une taille maximale différente déclenche une erreur conflict.

Définissez la région sur les deux objets, même si iad1 est votre valeur par défaut. Une configuration explicite évite qu’un changement ultérieur de la région par défaut du projet transforme un redémarrage banal en erreur de région.

Après un test temporaire, arrêtez toutes les sandboxes en lecture et en écriture, vérifiez avec Drive.list() ou currentSandboxName que le Drive est détaché, puis appelez await workspace.delete(). La suppression efface définitivement les fichiers, et Vercel la refuse tant qu’une sandbox reste rattachée.

Quatre postes distincts sur la facture

Le stockage Drive ne remplace pas le calcul de la sandbox. Il ajoute trois compteurs de stockage au compteur de calcul existant. Dans iad1, les tarifs publiés à ce jour sont les suivants :

Les tarifs varient selon la région. Les téléchargements Internet tels que les paquets npm et les dépôts Git sont gratuits, mais le CPU et la mémoire provisionnée nécessaires à leur installation restent facturés. C’est cette distinction qui peut rentabiliser un cache de dépendances : il évite de répéter la préparation, pas de payer du trafic sortant pour les téléchargements.

Voici un exemple de planification utile pour Pro ou Enterprise, et non un benchmark. Stocker une arborescence de dépendances de 10 GB pendant un mois complet coûte $0.50. La lire intégralement au cours de 100 exécutions représente 1,000 GB de lectures logiques, soit $1.50. L’écriture initiale des 10 GB coûte $0.04. La part Drive atteint donc $2.04, avant le calcul, la mémoire, le transfert ou les écritures ultérieures.

Dans son propre exemple de tarification, Vercel estime à environ $0.03 une exécution de validation de code par IA de cinq minutes, avec 2-vCPU, 4 GB et 100% d’utilisation CPU dans iad1. Ne partez pas du principe qu’un Drive économise la totalité de cette somme. Mesurez la phase d’installation réellement supprimée, puis comparez le calcul et l’attente humaine évités à la facture de stockage, de lecture et d’écriture du Drive.

L’offre Hobby inclut 15 GB de stockage Drive, ainsi que 30 GB par mois pour chacune des lectures et des écritures. Par ailleurs, la taille maximale d’un Drive Hobby est de 1 GiB par défaut. Hobby ne facture pas de dépassement : la création de nouvelles sandboxes est suspendue lorsqu’un quota est dépassé. Sur les offres payantes, un Drive est limité par défaut à 1 TiB si maxSize n’est pas défini, et ce plafond peut être configuré jusqu’à 16 TiB.

Sept usages, classés par bénéficiaire principal

1. Un produit d’agent de code avec des projets récurrents

Attribuez un Drive à chaque espace de travail d’agent. Placez-y le dépôt, les fichiers générés, les notes de tâche et le cache des paquets, puis rattachez-le à une nouvelle sandbox au tour suivant. L’équipe produit évite de reconstruire le même espace après chaque fin de cycle d’une sandbox, tandis que l’utilisateur retrouve son contexte sans maintenir le calcul actif.

C’est l’usage le plus convaincant, car la fréquence des redémarrages amplifie le coût des préparations répétées. La règle d’un seul accès en écriture correspond aussi naturellement à un agent actif par espace, tandis que les aperçus et les tests peuvent s’exécuter sur des lecteurs figés.

2. Une équipe de build qui répète la même installation de dépendances

Alimentez un Drive depuis une tâche d’écriture contrôlée, puis laissez les tâches suivantes monter des snapshots en lecture seule de l’arborescence des dépendances. L’équipe remplace du temps d’attente et du CPU d’installation récurrents par une copie stockée et des frais de lecture. Le gain est maximal lorsque les dépendances sont volumineuses, changent moins souvent que les tâches ne s’exécutent et que leur cache peut être séparé de l’arborescence du code source.

3. Un pipeline de revue multi-agents

Un coordinateur écrit le dépôt candidat, puis lance en parallèle l’audit de sécurité, les tests, le linting et la vérification de la documentation sur des lecteurs de snapshot. Chaque relecteur part du même état et ne peut pas modifier la source partagée. La contrainte est intentionnelle : pour accéder à une modification ultérieure du coordinateur, il faut recréer le relecteur avec un nouveau snapshot.

4. Une équipe data qui réutilise un jeu de données préparé

Une seule tâche d’écriture télécharge, normalise et indexe le jeu de données ; les sandboxes d’analyse éphémères montent ensuite des snapshots. La préparation coûteuse n’a lieu qu’une fois et les lecteurs simultanés reçoivent une entrée cohérente. Le modèle convient bien aux évaluations reproductibles, mais pas à un jeu de données vivant que chaque lecteur doit pouvoir modifier en place.

5. Un agent de recherche qui accumule des fichiers au fil des sessions

Conservez sur le Drive les citations, les textes extraits, les tableaux intermédiaires et un index de recherche local. Une nouvelle sandbox peut reprendre le travail depuis ce dossier sans collecter et indexer les mêmes sources. Le bénéfice tient à la reproductibilité des documents de travail ; le risque consiste à traiter ces fichiers comme une vérité durable sans système distinct de sauvegarde ou de provenance.

6. Un cache de modèles ou de chaîne d’outils pour les tâches ponctuelles

Préchargez sur un Drive les poids de modèles, les compilateurs ou d’autres entrées volumineuses, puis ne démarrez le calcul qu’à l’arrivée d’une tâche. La première lecture en cas d’absence dans le cache peut être plus lente, car Vercel récupère les données depuis le stockage durable ; les lectures suivantes servies par le cache s’effectuent à la vitesse NVMe. Ce modèle est rentable lorsque le calcul inactif coûterait plus cher que le stockage des octets utilisés.

7. Une plateforme de formation avec des projets étudiants reprenables

Attribuez un Drive à chaque projet, montez-le dans une nouvelle sandbox pour la session, puis détachez-le à la fin. Les étudiants conservent leurs fichiers tandis que la plateforme libère les ressources de calcul. La limite à un seul auteur aide à empêcher deux sessions actives de modifier simultanément le même projet, mais le produit doit toujours gérer lui-même l’identité, les sauvegardes et les règles de conservation.

Deux produits qui méritent d’être construits

Le volume de recherche signale une demande, pas un chiffre d’affaires prévisible. La bonne question est de savoir si cette capacité résout une tâche pénible pour un public déjà en quête de solution.

Le meilleur pari : un gestionnaire de baux pour espaces de travail d’agents

Construisez un petit plan de contrôle qui associe chaque agent ou projet utilisateur à un Drive, accorde un bail d’écriture temporaire unique, crée des sandboxes de lecture figées pour les tests et les aperçus, puis expose la région, le rattachement et l’état de suppression. Les équipes qui développent des agents de code paieraient pour cette couche de coordination, car la primitive de stockage seule ne décide pas qui détient l’accès en écriture.

Aux États-Unis, les données de mots-clés indiquent environ 8,100 recherches mensuelles pour « ai powered coding agent », avec une intention commerciale. Le marché voisin accepte déjà une facture de plateforme : E2B affiche son offre Pro à $150 par mois, hors consommation, tandis que les sessions persistantes sur plusieurs jours relèvent de son offre Enterprise personnalisée. Il ne s’agit pas d’une comparaison tarifaire directe, mais d’un repère crédible pour le budget des équipes qui achètent une infrastructure d’agents.

La plus petite version commercialisable doit réunir l’association d’un Drive à chaque espace de travail, une file d’attente d’écriture avec expiration, la création de lecteurs sur snapshot, une vue de l’usage et un nettoyage sûr. La difficulté tient à l’avantage défendable. Vercel ou un framework d’agents peut absorber un simple wrapper ; le produit doit donc apporter des règles opérationnelles, un historique d’audit, la reprise et la portabilité entre fournisseurs, plutôt qu’un bouton getOrCreate() mieux présenté.

Une couche de démarrage à chaud pour les environnements de développement cloud

Regroupez un modèle de dépôt, un chemin de dépendances adossé à un Drive, un outil de préchauffage du cache, une politique de région explicite et des mesures du temps de préparation avant et après pour les équipes plateforme. Vendez le résultat comme un moyen de réduire les démarrages à froid dans un environnement Vercel existant, pas comme un environnement de développement complet.

Aux États-Unis, les données de mots-clés font état d’environ 1,900 recherches mensuelles pour « cloud integrated development environment », avec un CPC de $9.03. Cette valeur en référencement payant laisse penser que les fournisseurs se disputent ce public. Le MVP peut rester ciblé : Node et pnpm d’abord, une seule région, une seule politique de cache et un tableau de bord qui sépare stockage, lectures, écritures, CPU actif et mémoire.

La limite tient au périmètre. Un Drive fournit un seul répertoire persistant. Il ne fournit ni IDE, ni gestion des secrets, ni collaboration, ni gestion des images, ni sauvegarde, ni réplication interrégionale. Un produit qui promettrait un poste de travail cloud complet à partir de cette seule primitive décevrait ses acheteurs.

Les limites qui doivent guider l’architecture

• Un seul accès en écriture signifie un seul propriétaire. Sérialisez les modifications. Les lecteurs sur snapshot servent au travail en éventail, pas à l’édition collaborative.
• Les lecteurs restent figés. Un lecteur actif ne voit jamais une écriture ultérieure. Recréez-le avec un nouveau snapshot.
• Le premier snapshot exige une écriture. Initialisez le Drive avant de démarrer les sandboxes de lecture.
• La région principale doit correspondre. Un Drive reste dans une seule région et ne peut pas être déplacé. Définissez explicitement la région.
• Une sandbox accepte quatre montages. Chaque chemin doit être absolu, et les chemins de montage ne peuvent pas se chevaucher.
• Un Drive ne représente pas toute la machine. Utilisez le snapshot d’une sandbox pour un environnement complet ; réservez le Drive au répertoire qui doit évoluer indépendamment.
• Les lectures à froid peuvent être plus lentes. Les lectures trouvées dans le cache et les écritures s’effectuent à la vitesse NVMe, contrairement aux absences de cache qui nécessitent le stockage durable.
• La suppression est définitive. Vercel indique que drive.delete() est irréversible. Un Drive ne doit pas être votre seule sauvegarde.

La documentation en ligne présente aussi une contradiction. L’annonce du 23 septembre indique que les sandboxes qui montent des Drives ne peuvent pas utiliser de régions de basculement. La page consacrée aux régions, datée du 22 septembre, affirme qu’un basculement peut charger un Drive entre plusieurs régions au prix d’une latence de lecture supérieure. Tant que Vercel n’a pas harmonisé ces indications, considérez le basculement des Drives comme non pris en charge dans votre architecture et testez-le de nouveau avant d’en dépendre.

Si votre tâche a seulement besoin de davantage d’espace temporaire pendant une exécution, un Drive n’est pas la première solution à retenir. Consultez le guide complémentaire sur l’extension du disque temporaire de Vercel Sandbox et n’ajoutez pas de persistance à l’architecture.

L’action à mener lundi

Choisissez la semaine prochaine un workflow d’agent qui redémarre souvent. Placez uniquement ses fichiers de projet et son cache de dépendances sur un Drive, ne laissez qu’une sandbox écrire et exécutez les quatre vérifications ci-dessus. Mesurez le temps de préparation avant et après, puis consignez séparément le stockage Drive, les lectures, les écritures, le CPU actif et la mémoire. Ne généralisez cette architecture que si le redémarrage plus court justifie la facture de stockage et la règle de coordination supplémentaires.

Pour concevoir et instrumenter un espace de travail d’agents durable en production, je développe des systèmes d’IA prêts pour la production.