Cloudflare Containers, reconstruit pour faire évoluer les sandboxes d’agents, troque le déploiement statique contre le contrôle à l’exécution

Cloudflare Containers, reconstruit pour faire évoluer les sandboxes d’agents, démarre désormais plus de six fois plus vite, selon l’entreprise. La version du 30 septembre ajoute également la sélection d’images à l’exécution, le dimensionnement des instances à l’exécution et les instantanés du système de fichiers en bêta publique.

Le changement important ne se limite pas à un démarrage à froid plus court. Cloudflare a transféré le contrôle de chaque sandbox dans un Durable Object, son composant serverless avec état destiné à coordonner les requêtes et l’état persistant des applications. Cette décision remet en question le modèle de déploiement statique qui a façonné la première version de Cloudflare Containers.

Les développeurs peuvent désormais laisser un agent choisir l’environnement requis pour chaque tâche. Un travail de programmation peut nécessiter une instance plus grande et une chaîne d’outils Linux complète. Une automatisation plus modeste peut utiliser un environnement plus léger. Lorsque le travail s’interrompt, le système peut enregistrer le système de fichiers, arrêter le calcul et restaurer l’espace de travail ultérieurement.

Cela place Cloudflare plus directement sur le marché animé des infrastructures pour agents. E2B, Modal, Daytona, Vercel et les services cloud hyperscale proposent déjà différentes approches de l’exécution isolée. Cloudflare avance qu’un contrôleur adressable à l’échelle mondiale, un espace de travail Linux isolé et un état persistant devraient fonctionner comme une seule unité programmable.

L’architecture semble adaptée aux agents de programmation, aux évaluations et aux workflows de longue durée. Toutefois, l’affirmation d’un démarrage six fois plus rapide provient de Cloudflare, les instantanés restent en bêta publique et plusieurs limites opérationnelles comptent. Le véritable test sera de savoir si les équipes obtiennent un contrôle fiable sans hériter d’une complexité excessive du cycle de vie.

Cloudflare Containers, reconstruit pour faire évoluer les sandboxes d’agents, transforme le plan de contrôle

Le changement central de Cloudflare consiste à déplacer la configuration des sandboxes du moment du déploiement vers celui où un agent démarre une tâche.

Dans le modèle précédent, une application déclarait généralement une image de conteneur et un type d’instance dans sa configuration de déploiement. Modifier l’un ou l’autre déclenchait un déploiement à l’échelle de l’application. Ce modèle convient aux services prévisibles, mais les agents génèrent des charges de travail qui varient d’une requête à l’autre.

Un agent de correction de code peut nécessiter un dépôt, un compilateur, un gestionnaire de paquets, un navigateur et une suite de tests. Un worker d’évaluation peut nécessiter un environnement propre et reproductible avec des entrées étroitement contrôlées. Une autre tâche peut seulement exiger un court script avec une mémoire limitée et aucun accès à Internet.

La nouvelle politique de planification durable_object de Cloudflare permet au code applicatif de faire ces choix à l’exécution. Le Durable Object de contrôle appelle ctx.container.start() et fournit une configuration d’image, d’instantané et d’instance adaptée à cette tâche.

Les tailles prédéfinies disponibles comprennent lite et quatre configurations standard. Les développeurs peuvent également fournir des valeurs personnalisées de CPU, de mémoire et de disque dans les limites de la plateforme. La politique de planification à l’exécution remplace une configuration sélectionnée de manière centralisée par des décisions propres à chaque sandbox.

La sélection des images suit le même modèle. Les développeurs déclarent des images nommées via Wrangler, l’outil de déploiement en ligne de commande de Cloudflare. La plateforme prépare des références immuables, et le Durable Object en sélectionne une au démarrage d’une sandbox.

Cette organisation permet à une application de prendre en charge plusieurs rôles d’agents sans déployer une application de conteneurs distincte pour chaque rôle. Un coordinateur peut orienter une tâche de recherche légère vers une image, puis attribuer un travail de compilation à une autre image disposant de davantage de ressources.

Cloudflare a également introduit cloudflare/debian-trixie, une image Debian gérée contenant Node.js. Un agent peut démarrer avec cette base, installer ses outils via exec() et conserver l’espace de travail obtenu sous forme d’instantané.

Selon l’annonce des sandboxes de Cloudflare, le nouveau chemin de planification démarre Containers plus de six fois plus vite. L’entreprise affirme avoir supprimé plusieurs étapes de coordination qui se situaient auparavant entre le Durable Object et l’environnement d’exécution des conteneurs.

Cette affirmation exige une interprétation prudente. Cloudflare n’a pas présenté de benchmark indépendant comparant des images, régions ou types de charges de travail représentatifs. La disponibilité d’un conteneur dépend également de la taille de l’image, du comportement de l’entrypoint, de la capacité et des vérifications d’intégrité au niveau de l’application.

La documentation d’architecture de Cloudflare indique elle-même que les démarrages à froid se situent souvent entre une et trois secondes. Elle précise aussi que le temps de démarrage varie selon l’image et son travail d’initialisation. Un planificateur plus rapide ne peut pas éliminer les délais créés à l’intérieur même de l’image.

La plateforme expose une propriété running avant qu’un processus soit nécessairement prêt à accepter du trafic. Les développeurs doivent toujours vérifier que le port est prêt avant d’envoyer la première requête. Pour un agent, « conteneur démarré » et « espace de travail prêt pour un travail utile » restent deux mesures distinctes.

Même avec ces réserves, la configuration à l’exécution change le modèle opérationnel du produit. Cloudflare Containers ne sont plus seulement des services déployés que les agents utilisent par hasard. Ils deviennent des ressources qu’un contrôleur d’agents peut assembler, dimensionner, arrêter et reconstruire autour de tâches individuelles.

Des sandboxes d’agents plus rapides mettent sous pression les modèles de déploiement statique

Les charges de travail des agents favorisent une infrastructure capable de changer de forme entre les tâches, et pas seulement une infrastructure qui exécute efficacement une image.

Les plateformes de conteneurs traditionnelles supposent que les développeurs connaissent la forme de l’application avant son déploiement. Les équipes choisissent une image, une allocation de ressources, une politique réseau et une configuration de mise à l’échelle. Un planificateur crée ensuite des répliques qui partagent globalement ces propriétés.

Les systèmes d’agents perturbent cette hypothèse. Leur prochaine action dépend des demandes des utilisateurs, des décisions du modèle, des résultats des outils et de l’état laissé par le travail précédent. Deux tâches consécutives au sein d’un même produit peuvent nécessiter des systèmes d’exploitation, dépendances, limites de ressources et autorisations réseau différents.

Cette variabilité exerce une pression sur les fournisseurs bâtis autour d’une configuration applicative statique. Les équipes peuvent toujours déployer plusieurs services et répartir le travail entre eux. Toutefois, chaque nouveau type de charge de travail ajoute une unité de déploiement, un chemin de déploiement, une décision de capacité et une source de dérive de configuration.

Le modèle d’exécution de Cloudflare transfère une partie de cette décision dans le code applicatif. Le contrôleur de l’agent peut choisir une image de sandbox et un type d’instance après avoir examiné la tâche. Il peut également décider si la sandbox reçoit un accès à Internet ou démarre à partir d’un instantané enregistré.

Le principal adversaire n’est donc pas un fournisseur nommé. C’est le modèle de déploiement statique qui traite chaque sandbox d’une application comme une copie du même service prédéfini.

E2B, Modal, Daytona et Vercel répondent déjà à ce marché à travers leurs propres abstractions. Certains mettent l’accent sur des API de sandbox conviviales pour les développeurs. D’autres s’appuient sur les fonctions, les machines virtuelles, les espaces de travail ou une orchestration cloud plus large. Les équipes qui exploitent Kubernetes ou Firecracker directement gagnent davantage de contrôle, mais elles possèdent aussi davantage d’infrastructure.

Le facteur de différenciation de Cloudflare réside dans la relation entre chaque conteneur et son Durable Object. Un Durable Object fournit une identité stable, du code applicatif, du stockage, des alarmes et de la coordination en dehors de l’environnement Linux. Le conteneur fournit un calcul isolé pour les outils nécessitant un système d’exploitation conventionnel.

La boucle de décision de l’agent peut rester active pendant que l’espace de travail Linux est en veille. Elle peut communiquer avec les utilisateurs, conserver l’état d’autorisation et appeler des modèles sans laisser tourner la sandbox plus lourde. Lorsqu’un compilateur ou un serveur de développement devient nécessaire, le contrôleur réveille le conteneur.

Cloudflare décrit cette séparation comme le fait de garder le « cerveau » de l’agent séparé de ses « mains ». Le contrôleur conserve l’intention et l’état, tandis que la sandbox exécute des commandes susceptibles d’échouer, de s’arrêter ou de devoir être remplacées.

Cette séparation offre des avantages de sécurité autant qu’opérationnels. Le Durable Object peut conserver les identifiants en dehors du conteneur et servir d’intermédiaire pour les requêtes sortantes. Un agent n’a pas nécessairement besoin d’accéder directement à chaque secret requis pour un appel de service autorisé.

Cloudflare avait auparavant avancé que le code d’agent généré dynamiquement exige un environnement d’exécution isolé. Son précédent modèle de sandbox de code se concentrait sur les Dynamic Workers légers pour les tâches ne nécessitant pas un système Linux complet.

Containers couvre le volet plus lourd de cette répartition. Ils prennent en charge les gestionnaires de paquets, les binaires natifs, les dépôts, les compilateurs, les terminaux et les serveurs de développement. Dynamic Workers peut gérer des tâches d’exécution de code plus petites avec un environnement d’exécution plus restreint.

Cela crée une stratégie d’exécution à plusieurs niveaux. Un contrôleur peut utiliser une sandbox légère pour un court workflow d’API et réserver un conteneur aux tâches nécessitant Linux. La sélection à l’exécution compte, car maintenir chaque tâche dans un conteneur complet gaspille du temps de démarrage et des ressources.

La pression s’étend au-delà des fournisseurs de sandboxes. Les équipes de plateformes internes maintiennent souvent des pools d’environnements de développement chauds afin de masquer les délais de provisionnement. Des démarrages à froid plus rapides et des systèmes de fichiers pouvant reprendre affaiblissent l’argument en faveur du maintien de grands pools inactifs.

Toutefois, Cloudflare n’élimine pas l’orchestration. Elle déplace l’orchestration dans le Durable Object et son code applicatif. Les équipes doivent toujours concevoir des règles d’admission, des contrôles de concurrence, un comportement de nouvelle tentative, l’autorisation, le nettoyage et l’observabilité.

Le modèle gagnant ne sera pas celui dont la plateforme annonce le plus petit chiffre de démarrage isolé. Ce sera celui qui minimise le délai total entre la décision d’un agent et un résultat de tâche vérifié.

Cela inclut la préparation des images, l’accès aux dépôts, la restauration des dépendances, l’exécution des commandes, la latence réseau et l’arrêt. Cela inclut également le délai humain causé par les sessions en échec ou le travail perdu.

Pour les équipes d’ingénierie qui comparent les options, le benchmark pertinent doit reproduire leur workflow complet. Un test synthétique de conteneur vide ne peut pas représenter un grand dépôt, l’installation de paquets, le démarrage d’un navigateur ou une suite de tests.

Ces évaluations produisent également des connaissances de conception que les équipes doivent conserver. Une base de connaissances d’ingénierie consultable peut préserver les hypothèses de benchmark, les décisions de sécurité et les conclusions de migration aux côtés de l’implémentation.

Les Durable Objects transforment les Containers en calcul adapté aux tâches

Le mécanisme derrière cette version est un contrôleur avec état qui traite son conteneur comme du calcul remplaçable plutôt que comme un état applicatif permanent.

Chaque Cloudflare Container est associé à un Durable Object. Les requêtes atteignent d’abord un Worker, puis transitent par cet objet avant d’atteindre le conteneur. Le Durable Object peut adresser un espace de travail spécifique et préserver l’état lié à son identité.

Avec la nouvelle API, les développeurs étendent directement DurableObject et accèdent au conteneur attaché via this.ctx.container. Cela supprime la classe wrapper que Cloudflare utilisait initialement pour faire ressembler Containers à des services de sandbox conventionnels.

Le contrôleur peut démarrer le conteneur, exécuter des commandes, l’inspecter, surveiller les arrêts, envoyer des signaux de processus, définir un délai d’inactivité et détruire l’instance. Il peut combiner ces contrôles avec le stockage Durable Object, les alarmes, les WebSockets et les appels de procédure distante.

Imaginez un agent de programmation répondant à un signalement de bug. Le Durable Object peut stocker l’identifiant de session, le dépôt approuvé, les autorisations utilisateur et la phase actuelle de la tâche. Il peut ensuite sélectionner une image contenant la chaîne d’outils linguistique appropriée et lancer une instance adaptée.

Le conteneur clone le dépôt, installe les dépendances, exécute la suite de tests et modifie des fichiers. Pendant ce temps, le Durable Object peut envoyer des informations d’avancement par WebSocket et enregistrer des points de contrôle en dehors du conteneur.

Si le processus du conteneur s’arrête, le contrôleur conserve l’identité et les métadonnées de la session. Il peut examiner l’échec, redémarrer depuis un état connu ou signaler le problème sans perdre l’intégralité de l’interaction.

Cloudflare exécute chaque conteneur dans une microVM Firecracker, une machine virtuelle légère dotée de son propre noyau et de son propre réseau. L’image client s’exécute comme conteneur Linux à l’intérieur de cette machine virtuelle.

L’architecture des conteneurs de la plateforme indique que les autres charges de travail Cloudflare ne partagent pas ce noyau. Cette isolation est importante, car les commandes générées par les agents ne devraient pas s’exécuter directement dans l’application qui traite des données utilisateur de confiance.

Le placement reste dynamique. Cloudflare choisit une capacité éligible là où l’image requise est disponible, le routage et la vitesse de démarrage influençant l’emplacement. Le Durable Object et le conteneur ne sont pas garantis de s’exécuter au même endroit.

Cette réserve compte pour les boucles de contrôle sensibles à la latence. Une identité adressable à l’échelle mondiale ne signifie pas que chaque opération s’exécute à côté de l’utilisateur, du fournisseur de modèle ou du sandbox. Les équipes devraient mesurer l’ensemble du chemin de requête dans leurs régions attendues.

La capacité peut aussi changer d’une session à l’autre. Si un conteneur s’arrête puis redémarre ultérieurement, Cloudflare peut placer son remplacement ailleurs. Les applications ne doivent pas considérer l’identité locale d’une machine comme permanente.

Le Durable Object devient la couche de continuité. Il stocke les informations nécessaires pour retrouver, reconstruire ou restaurer l’espace de travail. L’instance Linux devient une ressource d’exécution qui peut disparaître lorsqu’elle est inactive.

Cette architecture prend également en charge les charges de travail à embranchements. Un coordinateur peut lancer plusieurs tentatives indépendantes à partir de la même base préparée. Chaque tentative peut tester un modèle, un prompt système, un ensemble de compétences ou une stratégie de correction différents.

Le contrôleur peut surveiller ces exécutions, comparer les résultats et conserver la sortie privilégiée. Les systèmes d’apprentissage par renforcement peuvent suivre des schémas similaires afin de créer des environnements contrôlés, évaluer les résultats et réinitialiser l’état entre les essais.

Le dimensionnement des instances à l’exécution renforce ce modèle. Un contrôleur peut attribuer davantage de ressources aux builds et en réduire l’allocation pour les commandes plus légères. Un dimensionnement statique à l’échelle de l’application obligerait les équipes à provisionner pour la tâche courante la plus exigeante ou à maintenir des déploiements séparés.

Toutefois, la programmabilité transfère la responsabilité à l’application. Le contrôleur doit empêcher un modèle de sélectionner des ressources sans limites. Il devrait associer les requêtes de l’agent à des politiques approuvées plutôt que de transmettre une sortie de modèle arbitraire aux API d’infrastructure.

Le même principe s’applique aux images. Autoriser une sélection à l’exécution ne signifie pas laisser un agent exécuter n’importe quelle image non vérifiée. Cloudflare exige des références d’images déclarées et épinglées par digest, ce qui aide à préserver la reproductibilité des déploiements.

Les équipes devraient néanmoins maintenir une liste blanche d’images, analyser les dépendances, restreindre l’accès sortant et séparer les identifiants de l’environnement invité. Un sandbox réduit l’exposition, mais il ne définit pas la politique de sécurité complète.

Sur le plan opérationnel, le Durable Object devrait rester la source de vérité pour l’état du cycle de vie. L’API directe de Cloudflare offre le contrôle, mais les applications doivent décider à quel moment une tâche devient récupérable, abandonnée, terminée ou sûre à relancer.

C’est le véritable mécanisme derrière des sandboxes d’agents plus rapides. L’amélioration de l’ordonnanceur compte, mais le changement durable est un plan de contrôle explicite qui survit à n’importe quel processus de conteneur.

Les snapshots du système de fichiers préservent les fichiers, pas les sessions en cours

Les snapshots réduisent le travail de configuration répété, mais ce sont des points de contrôle immuables du système de fichiers plutôt que des images complètes de suspension et de reprise.

Les snapshots natifs du système de fichiers de Cloudflare sont disponibles en bêta publique via la politique d’ordonnancement durable_object. Un conteneur en cours d’exécution appelle snapshotContainer() pour capturer son système de fichiers racine accessible en écriture à un instant donné.

Le handle renvoyé contient un identifiant, une taille et un nom facultatif. Les développeurs doivent enregistrer ce handle, souvent dans le stockage du Durable Object, car l’API Worker ne fournit pas de commande permettant de lister les snapshots.

Un conteneur ultérieur peut démarrer à partir du handle stocké. Cela rend un espace de travail de programmation récupérable après l’arrêt du calcul d’origine. Le dépôt, les dépendances installées, les caches de build, les fichiers de configuration et les modifications peuvent revenir avec le système de fichiers restauré.

Ce modèle répond à une inadéquation fréquente dans l’infrastructure des agents. Démarrer un sandbox vide peut prendre quelques secondes, tandis que préparer un environnement de développement utile peut demander plusieurs minutes. La répétition de l’installation des dépendances peut dominer la mesure de démarrage réellement perçue par les utilisateurs.

Les snapshots fournissent aussi une base stable pour les évaluations. Une équipe peut préparer un dépôt et une chaîne d’outils, les enregistrer, puis lancer plusieurs expériences depuis le même point de contrôle. Après restauration, chaque sandbox reçoit un environnement accessible en écriture indépendant.

Cela réduit la dérive de l’environnement entre les tentatives. Si deux versions d’un modèle voient des états de dépendances différents, les résultats des tests deviennent plus difficiles à comparer. Un point de contrôle immuable partagé aide à isoler la variable évaluée.

Cette fonctionnalité prend également en charge les projets de plus longue durée. Un agent peut enregistrer son espace de travail lorsqu’un utilisateur part, arrêter le calcul, puis restaurer les fichiers lorsque l’utilisateur revient. Cela sépare la continuité du système de fichiers de l’utilisation continue des ressources.

Cependant, le mot « snapshot » peut suggérer que Cloudflare préserve davantage que ce qui est actuellement le cas. La documentation sur les snapshots indique que le système capture l’intégralité du système de fichiers du conteneur, mais pas la mémoire, les processus en cours d’exécution ni les systèmes de fichiers montés séparément.

Un conteneur restauré exécute de nouveau son point d’entrée. Un build en mémoire, un débogueur actif, un processus de terminal ou un serveur de développement ne reprend pas exactement à l’instruction où il s’était arrêté. L’application doit reconstruire ces processus.

Les snapshots sont également liés à la version de l’image utilisée pour les créer. Les développeurs ne peuvent pas en restaurer un dans une image différente. Lorsqu’une image de base change, l’équipe doit créer un nouveau snapshot compatible.

Chaque handle de snapshot possède une durée de vie implicite de 30 jours. Sa restauration renouvelle cette période, mais les développeurs ne peuvent pas aujourd’hui configurer un intervalle de conservation différent. Cette limitation rend les snapshots inadaptés à un archivage indéfini sans plan de conservation externe.

Les snapshots sont immuables. Les modifications effectuées après restauration exigent un autre snapshot si l’équipe souhaite les conserver. Les applications ont donc besoin de politiques de points de contrôle qui équilibrent la valeur de récupération avec le stockage, la latence et la complexité opérationnelle.

Le statut de bêta publique ajoute une autre raison de faire preuve de prudence. Les équipes de production devraient valider la création et la restauration de snapshots lors d’interruptions, d’accès concurrents, de mises à jour d’images et de changements de placement régional.

Elles devraient aussi tester les limites d’échec. Si le conteneur s’arrête pendant un point de contrôle, l’application doit disposer d’un enregistrement clair indiquant quel snapshot reste valide. Si une tâche modifie un système externe, restaurer son système de fichiers n’annule pas cette action externe.

Cette distinction est particulièrement importante pour les agents autonomes. Un retour en arrière peut restaurer les fichiers locaux tout en laissant inchangés une pull request, une mise à jour de base de données, un e-mail ou une ressource cloud. Relancer aveuglément la tâche pourrait dupliquer une action irréversible.

Le contrôleur a donc besoin d’un registre des tâches en dehors du sandbox. Il devrait consigner les opérations approuvées, les effets de bord externes et les points de contrôle terminés. Le système de fichiers seul ne peut pas représenter toute la réalité du travail d’un agent.

Les équipes de sécurité doivent également examiner ce que les snapshots préservent. Les dépôts, le code généré, les journaux, les paquets mis en cache et les identifiants temporaires peuvent tous atteindre le système de fichiers accessible en écriture. Un snapshot peut conserver des éléments sensibles plus longtemps que la session en cours.

Cloudflare propose l’interception des requêtes sortantes et une gestion externe des identifiants, ce qui peut réduire l’exposition des secrets à l’intérieur de l’environnement invité. Les développeurs devraient néanmoins vérifier que les outils ne copient pas de jetons dans les fichiers de configuration, les historiques du shell ou les caches de paquets.

L’orientation de migration de l’entreprise introduit également un autre enjeu pratique. Les nouvelles fonctionnalités, notamment le chemin accéléré et les snapshots natifs, nécessitent un accès direct à ctx.container. Cloudflare indique qu’il maintiendra les anciennes classes Container et Sandbox héritée jusqu’au 31 décembre 2026.

Les déploiements existants continueront à fonctionner après cette date, selon l’entreprise, mais ces classes ne recevront plus de mises à jour. Les équipes qui souhaitent les nouvelles capacités doivent migrer leur logique de cycle de vie vers l’API directe de Durable Object.

Il s’agit d’un changement d’architecture significatif, et non d’un indicateur que chaque équipe peut activer sans risque. L’API directe expose davantage le modèle d’identité et de coordination du système. Elle demande aussi aux développeurs d’assumer explicitement la responsabilité de comportements auparavant masqués par une classe de base.

Cloudflare transforme Sandbox SDK 1.0 en une collection d’utilitaires plutôt qu’en une superclasse. Cela devrait permettre aux équipes d’associer des helpers pratiques au contrôle natif du cycle de vie. Cela confirme aussi que Cloudflare veut que le Durable Object, et non l’enveloppe du SDK, définisse l’abstraction centrale.

Les prochains tests porteront sur la fiabilité, l’adoption et la réponse concurrentielle

Cette sortie ne deviendra déterminante que si de vrais systèmes d’agents transforment ses nouveaux contrôles en une latence de tâche réduite et une récupération fiable.

Le premier signal à surveiller est la performance en production sur des charges de travail complètes. L’amélioration par six rapportée par Cloudflare concerne son chemin de démarrage, mais les développeurs ont besoin de mesures allant de l’envoi de la tâche jusqu’à la disponibilité de l’application.

Les tests utiles devraient couvrir des images petites et volumineuses, plusieurs régions, des snapshots restaurés, des systèmes de fichiers neufs et différentes tailles d’instances. Ils devraient distinguer la latence de l’ordonnanceur de l’initialisation de l’image, de la restauration des dépendances et de la disponibilité du service.

Si ces mesures montrent des délais de bout en bout constamment plus courts, l’argument de Cloudflare se renforce. Si les gains disparaissent dès que les dépôts et les serveurs de développement entrent dans le flux de travail, la vitesse de démarrage devient un avantage plus limité.

Le deuxième signal est la fiabilité des snapshots lorsque la bêta publique atteint des charges de travail exigeantes. Les équipes devraient surveiller les taux d’échec de restauration, la durée des points de contrôle, le comportement du stockage, les procédures de mise à niveau d’images et la récupération après des sessions interrompues.

Une adoption réussie par des agents de programmation serait particulièrement révélatrice. Cloudflare cite déjà Base44 et Kilo Code comme utilisateurs d’environnements isolés pour le travail des agents. Des documents antérieurs de Cloudflare identifiaient aussi Figma Make comme client de Containers pour l’exécution de code non fiable.

Ces références clients montrent de véritables cas d’usage, mais elles ne fournissent pas de données de performance comparatives. Des rapports d’ingénierie indépendants auraient davantage de poids que des témoignages de lancement.

Le comportement des snapshots avec de grands dépôts comptera également. Les répertoires de paquets et les sorties de build peuvent rapidement prendre de l’ampleur. Les équipes doivent comprendre si les snapshots restent rapides et gérables à mesure que les espaces de travail se développent au fil de points de contrôle répétés.

Si Cloudflare étend les contrôles de conservation des snapshots, les API de listing, l’observabilité ou les outils de migration interversions, cela indiquerait que la fonctionnalité progresse vers un usage de production plus large. Des limitations persistantes affaibliraient le récit de l’espace de travail de longue durée.

Le troisième signal est la manière dont les concurrents répondent au modèle combiné de contrôleur et de sandbox de Cloudflare. Le marché des sandboxes d’agents comprend des fournisseurs spécialisés et des plateformes de calcul plus généralistes, chacun avec des atouts différents.

E2B met l’accent sur des environnements cloud conçus spécifiquement pour les agents. Modal relie le calcul en sandbox à une plateforme serverless plus vaste. Daytona se concentre sur les environnements de développement, tandis que Vercel intègre des capacités de sandbox à sa plateforme applicative.

Les clouds hyperscale offrent aux équipes un contrôle étendu grâce aux machines virtuelles, conteneurs, systèmes d’identité et services d’orchestration. Leur inconvénient réside souvent dans le travail d’ingénierie nécessaire pour assembler ces composants en un produit d’agent à faible latence.

Cloudflare parie que les Durable Objects simplifient cet assemblage. L’identité, l’état, la communication, les politiques et le cycle de vie peuvent résider à côté du contrôleur de sandbox. Son réseau mondial fournit le routage et une capacité préprovisionnée.

Une réponse concurrentielle pourrait prendre plusieurs formes. D’autres fournisseurs pourraient ajouter une coordination avec état plus robuste, des instantanés plus flexibles, un dimensionnement d’exécution plus précis ou une médiation des identifiants plus étroite. Ils pourraient également publier des benchmarks remettant en cause les promesses de démarrage de Cloudflare.

Si les concurrents convergent vers un contrôleur externe avec état, l’architecture de Cloudflare paraîtra visionnaire, même lorsque les clients choisiront une autre plateforme. Si les développeurs privilégient des API de sandbox hébergées plus simples, le modèle Durable Object pourrait sembler trop axé sur l’infrastructure.

L’adoption dépendra en partie du niveau de contrôle souhaité par les équipes applicatives. Une startup développant un agent de programmation pourrait valoriser une programmation directe du cycle de vie. Une équipe ajoutant une seule fonctionnalité d’exécution de code pourrait préférer un service prescriptif impliquant moins de décisions.

Cloudflare doit servir ces deux groupes sans masquer les capacités qui distinguent la plateforme. La nouvelle orientation du SDK tente de concilier ces besoins en proposant des utilitaires autour d’une API native plutôt qu’une autre abstraction obligatoire.

Les incidents de sécurité constitueront un autre critère décisif. Les sandboxes d’agents exécutent des commandes non fiables ou imprévisibles, souvent avec un accès réseau et à proximité de code propriétaire. Un environnement rapide qui divulgue des identifiants ou autorise des accès inter-clients manquerait à son objectif central.

L’utilisation par Cloudflare de microVM Firecracker assure une isolation au niveau du noyau entre les charges de travail. Toutefois, une exploitation sécurisée dépend également de l’hygiène des images, des contrôles sortants, de l’autorisation, de la gestion des secrets, de la journalisation et des politiques applicatives.

Les équipes doivent considérer ce modèle comme un confinement à plusieurs couches, et non comme une permission de faire confiance au code généré par les agents. Le Durable Object peut devenir le point d’application des politiques, mais les développeurs doivent mettre en œuvre et tester ces politiques.

Cette publication soulève également une question plus large sur l’architecture des produits d’agents. L’agent doit-il vivre hors de l’espace de travail et le traiter comme un outil remplaçable, ou doit-il s’exécuter dans son ordinateur ?

Cloudflare prend en charge les deux approches. Exécuter l’agent dans le Durable Object permet de maintenir la communication et l’état disponibles pendant que le calcul est en veille. L’exécuter dans le conteneur offre un modèle de processus Linux familier, tandis que l’objet le supervise depuis l’extérieur.

La première approche rend explicite la frontière entre le cerveau et les mains. La seconde peut simplifier les environnements d’exécution d’agents existants qui attendent des fichiers et processus locaux. L’adoption réelle montrera quel modèle les développeurs jugent le plus facile à exploiter.

Cloudflare Containers, reconstruit pour faire évoluer les sandboxes d’agents, représente plus qu’une amélioration du démarrage à froid. Il transforme le choix de l’environnement d’exécution, la continuité du système de fichiers et la politique de cycle de vie en décisions au niveau de l’application, contrôlées par un état durable.

Ce changement met sous pression les déploiements statiques et les API de sandbox simplistes. Il donne aussi aux développeurs davantage de moyens de créer des défaillances subtiles. La flexibilité d’exécution exige des politiques strictes, des enregistrements de tâches durables et des benchmarks qui mesurent une préparation utile plutôt qu’un processus vide.

Les équipes qui évaluent cette publication devraient commencer par une charge de travail réelle. Mesurez le démarrage à froid, le démarrage restauré, la disponibilité des dépendances, la récupération après défaillance et l’achèvement total de la tâche. Testez ensuite si le contrôleur survit à la perte de conteneurs sans répéter des actions externes.

Les prochains mois devraient révéler si les instantanés de la bêta publique de Cloudflare restent fiables, si les clients publient des résultats de latence indépendants et si les concurrents adoptent des contrôles avec état similaires. Ces signaux détermineront si cette architecture devient une base commune pour des agents de longue durée ou une autre option spécialisée dans un marché de plus en plus encombré.