Comparatif des sandboxes Puppyone : Docker vs Cloudflare — laquelle choisir pour votre agent IA ?
23 avril 2026Guanqun @puppyone
Quand on fait tourner des agents IA en production, l'isolation n'est pas une option. Les agents exécutent du code, touchent au système de fichiers, appellent des services externes — et sans une vraie sandbox, une seule sortie qui dérape peut faire des dégâts difficiles à rattraper.
Puppyone propose deux environnements de sandbox distincts pour des charges de travail différentes : une sandbox basée sur Docker pour une exécution complète et flexible, et une sandbox basée sur Cloudflare pour des charges rapides, légères et distribuées globalement. Cet article décortique ce que chacune est vraiment, où elles diffèrent, et comment choisir la bonne.
Qu'est-ce qu'une sandbox ?
Une sandbox est un environnement d'exécution isolé où tout ce que fait un agent — exécuter du code, toucher à des fichiers, appeler des outils — reste contenu et sous contrôle. Une bonne sandbox impose des limites claires :
- Ce que l'agent peut lire et écrire
- Quels appels réseau il peut effectuer
- Combien de CPU et de mémoire il peut consommer
- Combien de temps il peut tourner avant d'être arrêté
Les deux types de sandbox font respecter ces limites. La vraie question, c'est comment — et quels compromis chaque approche implique.
Sandbox Docker vs sandbox Cloudflare : la différence de fond
Tout le comparatif tient en une phrase : une sandbox Docker vous donne une machine Linux complète ; une sandbox Cloudflare vous donne un slot pour exécuter du JavaScript.
La sandbox Docker s'appuie sur des conteneurs. Chaque sandbox est, en pratique, son propre serveur Linux — vous installez des paquets (apt install, pip install), faites tourner n'importe quel runtime (Python, Node, Go), lancez des sous-processus, lisez et écrivez sur un vrai système de fichiers, et laissez des tâches tourner pendant des heures. Le prix : un cold start de plusieurs secondes, et chaque sandbox consomme du CPU et de la mémoire bien réels tant qu'elle existe.
La sandbox Cloudflare repose sur les V8 Isolates — le même modèle d'isolation que celui que Chrome utilise pour cloisonner les onglets du navigateur. Elle ne peut exécuter que du JavaScript / WebAssembly : pas d'installation de paquets, pas de sous-processus, pas de système de fichiers local, et une exécution est généralement plafonnée à 30 secondes de CPU. En contrepartie, elle démarre à froid en moins de 5 millisecondes, fait cohabiter des milliers d'isolates sur une seule machine, et tourne automatiquement sur les 300+ POP edge mondiaux de Cloudflare.
| Ce que vous voulez faire | Choisir |
|---|---|
| Lancer des scripts Python, installer des bibliothèques, traiter des données | Docker |
Laisser un agent éditer des fichiers, générer des rapports, exécuter git | Docker |
| Tâches qui durent de quelques minutes à quelques heures | Docker |
| Répondre à une requête en quelques millisecondes | Cloudflare |
| Logique JavaScript hautement concurrente (routing, transformations, filtrage) | Cloudflare |
| Exécuter au plus près des utilisateurs dans plusieurs régions | Cloudflare |
La suite de l'article détaille chacune.
La sandbox basée sur Docker
Comment ça marche
Chaque tâche d'agent tourne dans son propre conteneur — un environnement Linux isolé du host par les namespaces et les cgroups. Quand une tâche arrive, Puppyone démarre un conteneur neuf depuis une image préconstruite, monte les inputs, alloue un répertoire de travail et applique les quotas de ressources. Quand la tâche se termine, le conteneur entier est démantelé. Chaque exécution part d'un état propre connu — aucun processus, fichier ou variable d'environnement résiduels du run précédent.
Ce que vous obtenez
Images personnalisables. L'image de base par défaut est Ubuntu avec Python, Node, Git et curl préinstallés. Si ça ne suffit pas, fournissez votre propre Dockerfile — Puppyone supporte les instructions standard (FROM, RUN, COPY, WORKDIR, ENV) — et embarquez les runtimes, outils CLI et dépendances privées qu'il vous faut. L'agent démarre directement dans un environnement taillé pour votre workflow.
Ressources configurables. Par défaut 2 vCPU et 512 Mo de RAM, ajustables par tâche jusqu'à 8 vCPU et 8 Go. Si une sandbox manque de mémoire, le conteneur est tué proprement — l'hôte reste indemne.
Durée maîtrisée. Timeout par défaut de 5 minutes par tâche, configurable jusqu'à 24 heures. Pour des workflows plus longs, la sandbox supporte pause / resume — le système de fichiers et l'état mémoire sont snapshottés à la mise en pause et restaurés à la reprise, vous évitant ainsi de payer pour relancer l'environnement de zéro.
Contrôle fin de l'egress réseau. Tout le trafic sortant est bloqué par défaut. Vous déclarez explicitement les domaines ou ports que l'agent a le droit d'atteindre (par exemple api.openai.com ou *.github.com) — tout le reste est refusé. C'est ainsi qu'on empêche un agent compromis par injection de prompt d'exfiltrer des données en douce.
Un workspace câblé sur votre système de fichiers. Chaque sandbox monte un namespace dans le système de fichiers Puppyone — pas un répertoire scratch éphémère. Quand l'agent écrit un fichier dans le conteneur, il commite, en pratique, un changement dans Puppyone : versionné, soumis à des permissions, auditable. Vous pouvez le rollback, le passer à un autre agent ou le retracer jusqu'à la tâche et à l'étape exactes qui l'ont produit.
Facturation au temps de vie du conteneur. Vous payez chaque seconde où le conteneur existe, que le CPU travaille ou non. Cela récompense le pattern « lance et démantèle » : démarre la tâche, termine-la, tue le conteneur. Si votre agent passe l'essentiel de son temps à attendre une réponse de LLM ou un input utilisateur, vous payez aussi pour cette attente.
Quand ce n'est pas le bon choix
- Chemins de réponse en dessous de 100 ms (les cold starts se comptent en secondes, pas en millisecondes)
- Des milliers de requêtes indépendantes par seconde (chaque conteneur coûte des ressources réelles)
- Quelques lignes de logique JavaScript légère (c'est sortir l'artillerie lourde)
Quand c'est le bon choix
- Scripts Python / Node / shell qui touchent à des fichiers, utilisent des bibliothèques ou produisent des artefacts
- Workflows multi-étapes où chaque étape s'appuie sur le workspace de la précédente
- Tout ce qui nécessite d'installer des paquets, compiler du code ou appeler des utilitaires système
- En bref : tout ce qui a réellement besoin d'une machine
Comment Puppyone la supporte
La sandbox Docker de Puppyone est API-compatible avec E2B — si votre agent tourne déjà sur E2B, vous pouvez le pointer sur Puppyone sans rien toucher à la logique métier. Sandbox.create(), runCode(), commands.run(), I/O fichier — tout se mappe directement. Ce que vous gagnez en plus : la sandbox et le système de fichiers ne font qu'un. Plus besoin de gérer la chaîne pénible « fichiers dans la sandbox → persistés en object storage → resynchronisés vers la sandbox suivante ». Chaque écriture atterrit dans le système de fichiers Puppyone avec historique de versions, permissions et logs d'audit — le même état, visible d'une tâche à l'autre, d'un agent à l'autre, et même d'un type de sandbox à l'autre.
La sandbox basée sur Cloudflare
Comment ça marche
Le code de l'agent tourne dans un V8 Isolate sur le réseau edge mondial de Cloudflare — la même technologie que celle utilisée par Chrome pour cloisonner les onglets. Chaque isolate est un contexte d'exécution JavaScript scellé qui démarre en quelques millisecondes (aucun OS à booter) et est détruit à la fin de la requête. Les requêtes sont routées vers le POP edge le plus proche de l'utilisateur, gardant la latence aller-retour à quelques dizaines de millisecondes.
Ce que vous obtenez
Cold starts en millisecondes. Un isolate démarre en moins de 5 ms — environ trois ordres de grandeur plus vite qu'un conteneur. Vous pouvez vous offrir le luxe de démarrer une sandbox neuve à chaque requête, sans warm pool ni instances de longue durée.
JavaScript / WebAssembly uniquement. Pas de Python, pas de shell, pas de binaires natifs. Votre logique est en JS/TS ou compile vers WASM. La plupart des built-ins Node.js sont disponibles, mais tout ce qui dépend de syscalls (fs, child_process, extensions C natives) ne l'est pas.
Plafond de 128 Mo de mémoire, 30 secondes de CPU par requête. Chaque requête a droit à 128 Mo de mémoire au maximum et à 30 secondes de CPU (configurable jusqu'à 5 minutes sur les plans payants). À noter : seul le temps CPU actif compte — le temps passé à attendre un fetch() ou une requête en base ne compte pas, donc une requête plafonnée à 30 secondes de CPU peut rester ouverte pendant plusieurs minutes au mur.
Pas de système de fichiers local. Les isolates sont sans état. Tout ce qui doit persister doit aller dans un stockage externe — Cloudflare KV, R2, D1, ou votre propre base de données. Pour partager de l'état intermédiaire entre requêtes, vous le sérialisez et le relisez, ou vous le confiez à un service à état séparé.
Exécution edge globale + autoscaling. Votre code est automatiquement déployé sur les 300+ POP edge de Cloudflare et tourne sur celui qui est le plus proche de chaque utilisateur. De zéro à des dizaines de milliers de QPS, vous ne planifiez aucune capacité — la plateforme s'en charge.
La couche sécurité de Cloudflare est offerte. Protection DDoS, rate limiting, gestion des bots, terminaison TLS — tout est intégré dans le réseau. Pas besoin de monter une couche dédiée pour ça.
Facturation aux seules millisecondes CPU actives. Quand un isolate attend un fetch(), une base ou un événement utilisateur, vous ne payez pas. Vous êtes facturé uniquement pour les millisecondes pendant lesquelles V8 exécute réellement du code. Pour les charges I/O-bound — typiquement les agents qui passent leur temps à appeler des LLMs et à agréger des réponses d'API — le coût de l'attente est à peu près nul.
Quand ce n'est pas le bon choix
- Tâches qui doivent installer des paquets, lancer du Python / shell ou exécuter des binaires natifs
- Charges en requête unique nécessitant plus de quelques minutes de CPU
- Workflows qui lisent ou écrivent des fichiers locaux ou maintiennent un état entre requêtes dans la sandbox
- Tâches gourmandes en mémoire qui dépassent 128 Mo
Quand c'est le bon choix
- Requêtes hautement concurrentes et de courte durée (parsing, transformation, filtrage, routing)
- Faire office de « porte d'entrée » de l'agent — décider vite, extraire des paramètres, choisir l'outil suivant
- Services à faible latence distribués globalement (gateways API intelligents, RAG en edge)
- Code de plomberie qui interconnecte les primitives Cloudflare (KV, R2, D1, Queues)
Comment Puppyone la supporte
La sandbox Cloudflare est actuellement en cours de développement et n'est pas encore ouverte au public. Nous sommes en train de la câbler avec le système de fichiers Puppyone exactement comme la sandbox Docker : quand du code JS dans un isolate « écrit un fichier », il commite un changement versionné, soumis à des permissions et auditable dans Puppyone — et partage cet état avec la sandbox Docker. Le même agent pourra faire tourner du calcul lourd dans une sandbox Docker et répondre depuis l'edge dans une sandbox Cloudflare, en regardant tous les deux le même workspace.
Si votre cas d'usage exige de l'exécution edge, abonnez-vous aux mises à jour — on vous prévient dès que c'est ouvert.
Comparatif côte à côte
Une vue condensée de tout ce qui précède dans un tableau qu'on peut parcourir d'un coup d'œil.
| Dimension | Sandbox Docker | Sandbox Cloudflare |
|---|---|---|
| Technologie sous-jacente | Conteneurs Linux (namespaces + cgroups) | V8 Isolates |
| Cold start | 2-10 secondes | < 5 millisecondes |
| Runtime | Python, Node, Go, shell — n'importe quel binaire Linux | JavaScript / TypeScript / WebAssembly |
| Installer des paquets ? | ✅ apt, pip, npm, Dockerfile personnalisé | ❌ Doit être bundlé en amont |
| Lancer des sous-processus ? | ✅ | ❌ |
| Système de fichiers local | ✅ POSIX complet, monté sur Puppyone | ❌ Stockage externe uniquement (KV / R2 / D1) |
| Ressources par défaut | 2 vCPU + 512 Mo | 128 Mo de mémoire |
| Plafond de ressources | 8 vCPU + 8 Go (configurable) | 128 Mo (fixe) |
| Durée par exécution | 5 min par défaut, jusqu'à 24 h | 30 s CPU par défaut, jusqu'à 5 min (payant) |
| Préservation d'état | Snapshots pause / resume (mémoire + FS) | Aucune (chaque requête, isolate neuf) |
| Modèle de concurrence | Un conteneur par sandbox (ressources réelles) | Des milliers d'isolates par machine |
| Distribution géographique | Une seule région | 300+ POP edge, routing automatique |
| Contrôle de l'egress | Allowlist de domaines/ports | Configuré via Workers |
| Couche sécurité plateforme | À monter vous-même | DDoS / rate limit / bot / TLS intégrés |
| Granularité de facturation | Par seconde de vie du conteneur (attente comprise) | Par milliseconde CPU active (l'attente ne compte pas) |
| Modèle de processus | Lance et démantèle | À la demande, sans maintenance |
| Compatibilité d'API | Compatible avec E2B | API Cloudflare Workers |
| Statut chez Puppyone | ✅ Disponible | 🚧 En développement, pas encore ouverte |
| Cas d'usage typiques | Traitement de données 5 min, Python avec paquets, workflows multi-étapes | Routing en millisecondes, logique JS hautement concurrente, APIs en edge |
| Un agent de 10 minutes — laquelle ? | Docker, s'il calcule réellement | Cloudflare, s'il passe 90 % à attendre des LLMs/APIs |
Comment choisir
Choisir une sandbox, ce n'est pas trancher laquelle est « la meilleure » — c'est regarder honnêtement à quoi ressemble votre charge. Les cinq dimensions qui suivent couvrent à peu près toutes les vraies décisions.
1. Langage du runtime
Si votre agent doit exécuter Python, du shell, du Go ou des binaires natifs (pensez à ffmpeg, pandoc, git) — ce sera Docker. Cloudflare ne sait faire tourner que du JavaScript / TypeScript / WebAssembly. Vous ne pouvez même pas faire un pip install.
Si votre logique métier est déjà en JS / TS et n'attaque pas les syscalls — les deux conviennent. Continuez à lire.
2. Durée de la tâche
| Durée de la tâche | Choisir | Pourquoi |
|---|---|---|
| < 30 s de CPU | Cloudflare | Démarrage en millisecondes + facturation à la ms — de loin le moins cher |
| 30 s - 5 min de CPU | Cloudflare (les plans payants étendent à 5 min) | On reste dans la limite |
| Plusieurs minutes à quelques heures | Docker | Cloudflare bute sur son plafond CPU |
| Workflows sur plusieurs jours | Docker + snapshots pause / resume | Geler l'état et reprendre plus tard |
3. Structure des coûts (la dimension qu'on rate le plus souvent)
Les deux modèles de facturation sont vraiment différents — la même charge peut coûter un ordre de grandeur de plus si vous choisissez mal.
- Docker facture le temps pendant lequel le conteneur existe. Le compteur démarre dès que le conteneur boote, que le CPU travaille ou non. Cela récompense le travail court et dense : démarre la tâche, termine-la, tue le conteneur. Si vous laissez un conteneur inactif attendre un input utilisateur ou une réponse de LLM, vous payez pour cette attente.
- Cloudflare facture uniquement les millisecondes CPU actives. Quand l'isolate attend un
fetch(), une base ou un stream de réponse de LLM, vous ne payez pas. Seules les millisecondes pendant lesquelles V8 exécute du code vous sont facturées.
Concrètement :
- Une tâche de traitement de données de 5 minutes (CPU saturé tout du long) → Docker est moins cher
- 10 000 utilisateurs par seconde, chacun déclenchant 50 ms de logique → Cloudflare est moins cher de plusieurs ordres de grandeur
- Un agent de 30 minutes qui passe 90 % du temps à attendre des streams de LLM → Cloudflare est radicalement moins cher ; Docker vous facture les 30 minutes complètes
Ne comparez pas les tarifs horaires. Comparez la fraction du temps mur de votre charge qui est réellement passée à calculer. C'est ce ratio qui décide quel modèle gagne.
4. Concurrence
- Quelques requêtes à quelques dizaines par seconde → l'un ou l'autre fonctionne
- Des centaines par seconde, en tâches courtes → Cloudflare (des milliers d'isolates par machine ; Docker exigerait un conteneur par requête concurrente)
- Quelques requêtes par seconde, mais chacune représente plusieurs minutes de calcul → Docker (Cloudflare ne peut pas tenir aussi longtemps)
5. Volume de données et état
- Tâches qui lisent ou écrivent beaucoup de fichiers, produisent des artefacts de plusieurs Go ou maintiennent un workspace multi-étapes → Docker (vrai système de fichiers, monté sur Puppyone, versionné automatiquement)
- Tâches qui appellent juste quelques APIs, font des transformations légères et écrivent dans un stockage externe → Cloudflare (pas de système de fichiers local, mais lire KV / R2 / D1 est rapide)
- Plus de 128 Mo de mémoire → Docker (un seul isolate Cloudflare plafonne à 128 Mo)
Toujours indécis ? Par défaut, partez sur Docker. Ses capacités sont un sur-ensemble strict de Cloudflare — il est presque impossible de se tromper, vous payerez juste un peu plus dans les scénarios extrêmes de très haute concurrence ou très intensifs en I/O. Quand le trafic croîtra vraiment, vous pourrez basculer les chemins critiques sur Cloudflare à ce moment-là.
L'architecture idéale, une fois les sandboxes Cloudflare ouvertes : les deux travaillent ensemble. Les sandboxes Cloudflare comme porte d'entrée de l'agent — routing en millisecondes, extraction de paramètres, décisions légères. Quand la charge demande vraiment du calcul lourd, elle est déléguée à une sandbox Docker. Cloudflare gère le chemin rapide ; Docker gère le travail lourd ; le même système de fichiers Puppyone relie les deux extrémités.
Démarrer avec les sandboxes Puppyone
Si votre agent tourne déjà sur E2B, il suffit de le pointer sur Puppyone — Sandbox.create(), runCode(), commands.run() sont API-compatibles, aucune modification de la logique métier requise, et vous récupérez immédiatement le versioning, les permissions et les logs d'audit au niveau du système de fichiers.
Si vous partez de zéro, la documentation Puppyone propose un guide de démarrage rapide qui vous monte une sandbox à système de fichiers versionné en quelques lignes de code.
Besoin de la sandbox edge Cloudflare ? Abonnez-vous aux mises à jour — on vous prévient dès l'ouverture.