Cloudflare repense Containers pour les agents IA : un démarrage 6 fois plus rapide

Cloudflare a remanié l'infrastructure de Containers pour la charge que génèrent les agents IA : les bacs à sable apparaissent à la demande, pour chaque tâche, et doivent être prêts instantanément. Dans le benchmark indépendant ComputeSDK, le temps de démarrage médian est tombé de 4,049 secondes à 648 millisecondes (6,2 fois plus rapide). Dans un test préliminaire réalisé par l'entreprise elle-même, un seul compte a lancé 100 000 conteneurs en 5,387 secondes dans six localisations. Sont sortis en même temps le choix de l'image et des ressources directement depuis le code, ainsi que les snapshots du système de fichiers, en bêta publique.

C'est le code, et non le déploiement, qui choisit l'image et le matériel

Jusqu'ici, Containers était construit autour de l'application : l'image et les ressources de calcul étaient définies au déploiement, puis diffusées de manière centralisée. Ce modèle est peu pratique pour un bac à sable d'agent. Celui-ci a besoin d'outils, d'un volume de ressources et de fichiers de départ différents selon la tâche. Il peut aussi vivre quelques minutes, s'endormir entre deux requêtes ou être restauré plusieurs jours plus tard.

L'ancien modèle exigeait une application distincte pour chaque combinaison d'image et de type d'instance, avec son propre espace de noms Durable Objects et son routage dans un Worker. Un petit bac à sable Node.js et un grand environnement Python pour les builds représentaient donc deux déploiements. La nouvelle politique de planification `durable_object` ramène cela à une simple condition `if` : la configuration wrangler déclare les images disponibles (par exemple node et python), puis, au démarrage, le Durable Object transmet à `ctx.container.start()` l'image, le type d'instance (standard-1 ou standard-2, par exemple) et un indicateur d'accès à Internet. Un nouvel environnement s'obtient désormais en modifiant le code, et non en redéployant.

Il en va de même pour le déploiement des mises à jour. Les délais de grâce, les répartitions en pourcentage et les appels à l'API de configuration disparaissent : le conteneur tourne sur l'image avec laquelle il a démarré, tant que le code ne l'arrête pas, et le lancement suivant utilise l'image choisie par le code. On peut ainsi faire un déploiement canari sur 5 % des nouveaux bacs à sable à partir du hash de l'ID du Durable Object, maintenir les projets actifs sur l'image courante, migrer à un point de contrôle et revenir en arrière en changeant simplement l'image pour les futurs lancements.

Pourquoi la première commande s'exécute plus vite

Auparavant, le lancement d'un conteneur passait par un plan de contrôle global : il analysait la configuration de l'application, cherchait de la capacité et coordonnait le placement. Désormais, la demande naît au niveau du Durable Object. L'infrastructure cherche d'abord de la place sur la même machine, puis élargit la recherche à la localisation, en privilégiant les hôtes où l'image ou le snapshot sont déjà présents en local.

Une fois le conteneur arrivé sur l'hôte, Cloudflare a aussi supprimé le superflu : au lieu de démarrer une machine virtuelle de zéro, l'environnement d'exécution restaure une VM préparée à l'avance et non encore attribuée, réutilise la configuration du réseau et du système de fichiers, regroupe les opérations répétitives et n'attend pas les services dont la première commande n'a pas besoin. Résultats du benchmark Burst TTI (100 bacs à sable simultanés, mesure côté client) :

• médiane : 4,049 s → 648 ms (6,2 fois plus rapide) ; • 95e centile : 5,839 s → 910 ms (6,4 fois) ; • 99e centile : 6,717 s → 1129 ms (5,9 fois).

Cloudflare a par ailleurs publié l'image `cloudflare/debian-trixie`, avec Debian Trixie Slim et Node.js 24.20.0 LTS. Un agent peut démarrer un bac à sable Linux sans Dockerfile, sans build ni push d'image, puis cloner un dépôt et installer des paquets via `exec()`. Comme Cloudflare contrôle elle-même cette image, elle la distribue à l'avance sur les hôtes adaptés : au lancement, rien n'est téléchargé ni décompressé.

Snapshots : sauvegarder l'espace de travail et y revenir

Même un démarrage rapide n'élimine pas la phase de configuration : le clonage, l'installation des dépendances et la configuration de la chaîne d'outils prennent souvent plus de temps que le lancement du conteneur lui-même. Les snapshots natifs du système de fichiers, désormais en bêta publique, répondent à ce problème. La méthode `snapshotContainer()` sauvegarde l'espace de travail, et `start()` avec le paramètre `containerSnapshot` le restaure.

Les snapshots sont immuables et réutilisables, ce qui permet deux scénarios. Premier cas : un même espace de travail se poursuit d'une session à l'autre. Un agent de code sauvegarde le dépôt, les dépendances, les caches de build et les modifications quand l'utilisateur s'en va, puis les remonte le lendemain.

Second cas : un point de contrôle commun pour de nombreux bacs à sable. C'est pratique pour évaluer des agents : on exécute une même tâche avec différents prompts système, compétences, modèles ou versions de l'agent, alors que tout le reste doit rester identique. Un seul snapshot lance de nombreux environnements isolés avec la même base et élimine la dérive de l'environnement dans les résultats.

Le chaînage fonctionne aussi : l'agent démarre depuis debian-trixie, configure l'environnement via `exec()` et enregistre le résultat sous forme de snapshot.

À qui cela servira

Voici les scénarios pour lesquels la plateforme a été remaniée : agents de code avec dépôts, gestionnaires de paquets, compilateurs et serveurs de développement ; évaluations (evals) avec un état initial connu ; systèmes d'apprentissage par renforcement qui créent, évaluent et réinitialisent un grand nombre d'environnements ; tâches longues qui exigent de conserver des fichiers.

Base44 (un environnement de développement isolé pour chaque application, avec aperçu en direct) et Kilo Code (un environnement dédié à chaque session d'agent dans le cloud) bâtissent déjà leurs produits sur Containers. Des intégrations existent avec Cursor Cloud Agents, Devin Outposts, OpenAI Agents API et Claude Managed Agents. Le modèle est aussi repris dans Sandbox SDK 1.0, et l'API native `ctx.container` gagne de nouvelles possibilités pour qu'un Durable Object pilote le conteneur sans classe d'enrobage.

Pour les équipes qui développent des produits d'agents, la conclusion pratique est la suivante : si vous maintenez une application distincte par stack, vous pouvez les fusionner en une seule classe Durable Object qui choisit l'image à l'exécution. Pour les evals et le RL, il vaut mieux constituer un snapshot de référence et lancer des exécutions parallèles à partir de lui. Pour les sessions de longue durée, le duo « snapshot à la mise en pause, restauration au retour » convient bien. Les chiffres sur les 100 000 conteneurs sont préliminaires : mieux vaut donc tester la charge réelle sur son propre profil.