Vercel remplace les runtimes Sandbox par des images versionnées et open source
Vercel fait évoluer Sandbox avec des « Managed Images », des images de base versionnées dont le code source est publié. Le changement est immédiat pour les nouveaux projets en Sandbox SDK 3, avec un nouvel environnement par défaut sous Ubuntu 26.04 et la dépréciation de l’ancienne propriété `runtime`.
Fil « Vercel Sandbox migré vers Managed Images »

Vercel a annoncé le 10 août 2026 que Sandbox s’appuie désormais sur Vercel Managed Images (VMI), c’est-à-dire des images de base versionnées (des environnements système prêts à l’emploi) et open source. Ces images remplacent les anciens Sandbox runtimes (les profils d’exécution fournis par la plateforme), désormais dépréciés. À partir de la version 3 du SDK Sandbox, les nouveaux sandboxes utilisent par défaut vercel/sandbox/universal:latest. (vercel.com)
Ce qui change concrètement
Le point le plus visible est le changement de système d’exploitation par défaut : Vercel passe de Amazon Linux à Ubuntu, que l’éditeur décrit comme plus léger et plus courant dans l’industrie. L’image par défaut, vercel/sandbox/universal:latest, repose sur Ubuntu 26.04 et embarque déjà Node.js 24, Python 3.14, uv (un gestionnaire de paquets et d’environnements Python), ainsi qu’un ensemble d’utilitaires comme git, tmux (multiplexeur de terminal), ripgrep (recherche rapide dans le code), jq (manipulation de JSON) et fzf (sélecteur interactif en ligne de commande). Vercel publie aussi des images ciblées, notamment node:22, node:24, node:26, python:3.14, ubuntu:latest et arch:latest. (vercel.com)
Pourquoi c’est utile pour une équipe de dev
Vercel met en avant un modèle “secure by default” (sécurisé par défaut) : chaque image managée reçoit une release nocturne. Les tags flottants comme latest ou les tags de version majeure récupèrent automatiquement les mises à jour du système et des dépendances, y compris les correctifs de sécurité et les nouvelles versions de Node.js et Python. En parallèle, Vercel précise que les dépendances sont épinglées à des versions précises à l’intérieur d’une release, pour garder un environnement cohérent. Si une équipe veut un environnement strictement immuable (qui ne change plus), elle peut pointer vers un digest SHA (identifiant cryptographique exact d’une image), ce qui désactive les mises à jour automatiques. (vercel.com)
Impact de migration et compatibilité
La migration est pensée pour être progressive : la propriété runtime est dépréciée mais non supprimée, donc le code existant continue de fonctionner. En revanche, les anciens runtimes Amazon Linux ne font pas partie du catalogue des Managed Images ; les équipes qui ont besoin de AL2023 (Amazon Linux 2023) doivent donc rester sur runtime. Autre détail pratique : les Managed Images s’exécutent avec l’utilisateur par défaut ubuntu ou arch, avec sudo sans mot de passe (élévation de privilèges sans invite), au lieu de l’utilisateur vercel-sandbox. Enfin, les images peuvent être référencées depuis n’importe quel dépôt du projet, un dépôt partagé avec l’équipe, ou un dépôt public, via un chemin complet du type team-slug/project/repo:tag. (vercel.com)
import { Sandbox } from '@vercel/sandbox';
const sandbox = await Sandbox.create({
image: 'vercel/sandbox/python:3.14',
});
Pour un développeur web ou backend, le signal à retenir est simple : Vercel remplace un réglage implicite de plateforme par un artefact explicite et versionné. Concrètement, cela facilite la reproductibilité des environnements, clarifie les dépendances réellement présentes au démarrage, et réduit le besoin d’installer des paquets à chaque boot. Si vous exploitez Sandbox dans une chaîne d’outillage ou de génération automatisée, le choix entre tag flottant (mise à jour automatique) et digest figé (stabilité maximale) devient le vrai arbitrage opérationnel. (vercel.com)