Puppyone Sandbox-Vergleich: Docker-Sandbox vs Cloudflare-Sandbox — Welche passt zu Ihrem KI-Agenten?
23. April 2026Guanqun @puppyone
Wer KI-Agenten in der Produktion betreibt, kommt an Isolation nicht vorbei. Agenten führen Code aus, schreiben Dateien, rufen externe Dienste auf — und ohne saubere Sandbox kann ein einziger fehlerhafter Output Schaden anrichten, der sich nur schwer rückgängig machen lässt.
Puppyone bietet zwei verschiedene Sandbox-Umgebungen für unterschiedliche Workloads: eine Docker-basierte Sandbox für vollwertige, flexible Ausführung, und eine Cloudflare-basierte Sandbox für schnelle, global verteilte, leichtgewichtige Workloads. Dieser Beitrag zeigt, was hinter jeder steckt, wo die Unterschiede liegen und wie Sie die richtige auswählen.
Was ist eine Sandbox?
Eine Sandbox ist eine isolierte Ausführungsumgebung, in der alles, was ein Agent tut — Code ausführen, Dateien anfassen, Tools aufrufen — eingedämmt und kontrolliert bleibt. Eine gute Sandbox setzt klare Grenzen:
- Was der Agent lesen und schreiben darf
- Welche Netzwerkaufrufe er machen kann
- Wieviel CPU und Arbeitsspeicher er verbrauchen darf
- Wie lange er laufen darf, bevor er beendet wird
Beide Sandbox-Typen setzen diese Grenzen durch. Die spannende Frage ist wie — und welche Trade-offs jeder Ansatz mit sich bringt.
Docker-Sandbox vs Cloudflare-Sandbox: Der Kernunterschied
Der ganze Vergleich lässt sich in einem Satz zusammenfassen: Eine Docker-Sandbox gibt Ihnen einen vollwertigen Linux-Rechner; eine Cloudflare-Sandbox gibt Ihnen einen Slot zum Ausführen von JavaScript.
Die Docker-Sandbox baut auf Containern auf. Jede Sandbox ist im Grunde ein eigener Linux-Server — Sie können Pakete installieren (apt install, pip install), beliebige Runtimes laufen lassen (Python, Node, Go), Subprozesse starten, ein echtes Dateisystem lesen und schreiben, Tasks stundenlang laufen lassen. Der Preis dafür: ein mehrsekündiger Cold Start, und jede Sandbox verbraucht echte CPU- und RAM-Ressourcen, solange sie existiert.
Die Cloudflare-Sandbox baut auf V8 Isolates auf — derselben Isolationstechnik, mit der Chrome Browser-Tabs voneinander trennt. Sie kann ausschließlich JavaScript / WebAssembly ausführen: keine Paketinstallation, keine Subprozesse, kein lokales Dateisystem, eine einzelne Ausführung ist üblicherweise auf 30 Sekunden CPU-Zeit begrenzt. Im Gegenzug startet sie in unter 5 Millisekunden, packt Tausende Isolates auf eine einzige Maschine und läuft automatisch über Cloudflares 300+ globale Edge-Standorte.
| Was Sie vorhaben | Wahl |
|---|---|
| Python-Skripte ausführen, Bibliotheken installieren, Daten verarbeiten | Docker |
Einen Agenten Dateien bearbeiten, Reports generieren, git ausführen lassen | Docker |
| Tasks, die Minuten bis Stunden laufen | Docker |
| Eine Anfrage in Millisekunden beantworten | Cloudflare |
| Hochparallele JavaScript-Logik (Routing, Transformation, Filtering) | Cloudflare |
| Nahe an Nutzern in mehreren Regionen ausführen | Cloudflare |
Im Folgenden gehen wir beide im Detail durch.
Die Docker-basierte Sandbox
Wie sie funktioniert
Jeder Agent-Task läuft in seinem eigenen Container — einer Linux-Umgebung, die per Namespaces und cgroups vom Host isoliert ist. Wenn ein Task ankommt, startet Puppyone einen frischen Container aus einem vorgebauten Image, mountet die Inputs, weist ein Arbeitsverzeichnis zu und setzt Ressourcenlimits. Wenn der Task fertig ist, wird der gesamte Container abgebaut. Jede Ausführung beginnt aus einem bekannten, sauberen Zustand — keine übrig gebliebenen Prozesse, Dateien oder Umgebungsvariablen vom letzten Lauf.
Was Sie bekommen
Anpassbare Images. Das Standard-Base-Image basiert auf Ubuntu mit vorinstalliertem Python, Node, Git und curl. Reicht das nicht, bringen Sie Ihr eigenes Dockerfile mit — Puppyone unterstützt die Standard-Anweisungen (FROM, RUN, COPY, WORKDIR, ENV) — und packen Sie genau die Runtimes, CLI-Tools und privaten Abhängigkeiten rein, die Ihr Team braucht. Ihr Agent startet direkt in eine Umgebung, die auf Ihren Workflow zugeschnitten ist.
Konfigurierbare Ressourcen. Standardmäßig 2 vCPUs und 512 MB RAM, pro Task hochskalierbar bis zu 8 vCPUs und 8 GB. Geht einer Sandbox der Speicher aus, wird der Container sauber beendet — der Host bleibt davon unberührt.
Kontrollierte Task-Dauer. Standard-Timeout sind 5 Minuten pro Task, konfigurierbar bis zu 24 Stunden. Für länger laufende Workflows unterstützt die Sandbox pause / resume — Dateisystem und Speicherzustand werden beim Pausieren als Snapshot festgehalten und beim Resume wiederhergestellt, sodass Sie nicht für das erneute Hochfahren der Umgebung bezahlen.
Feingranulare Egress-Kontrolle. Ausgehender Traffic ist standardmäßig komplett blockiert. Sie definieren explizit per Allowlist, welche Domains oder Ports der Agent erreichen darf (z. B. api.openai.com, *.github.com) — alles andere wird abgewiesen. Genau so verhindert man, dass ein per Prompt-Injection manipulierter Agent unbemerkt Daten abfließen lässt.
Workspace, der mit Ihrem Dateisystem verdrahtet ist. Jede Sandbox mountet einen Namespace im Puppyone-Dateisystem — kein flüchtiges Scratch-Verzeichnis. Wenn der Agent im Container eine Datei schreibt, ist das effektiv ein Commit in Puppyone: versioniert, mit Berechtigungen, auditierbar. Sie können es zurückrollen, an einen anderen Agenten weiterreichen oder bis zum exakten Task und Schritt zurückverfolgen, der es erzeugt hat.
Abrechnung nach Container-Laufzeit. Sie zahlen für jede Sekunde, in der der Container existiert — egal, ob die CPU gerade etwas tut oder nicht. Das belohnt das "Run-and-Tear-Down"-Muster: Task starten, fertig, Container killen. Wenn Ihr Agent die meiste Zeit auf eine LLM-Antwort oder Nutzer-Input wartet, zahlen Sie auch für diese Wartezeit.
Wann sie nicht passt
- Antwortpfade unter 100 ms (Cold Starts dauern Sekunden, nicht Millisekunden)
- Tausende unabhängige Requests pro Sekunde (jeder Container kostet echte Ressourcen)
- Ein paar Zeilen leichtgewichtige JavaScript-Logik (Overkill)
Wann sie passt
- Python- / Node- / Shell-Skripte, die Dateien anfassen, Bibliotheken nutzen oder Artefakte erzeugen
- Mehrstufige Workflows, bei denen jeder Schritt auf dem Workspace des vorigen aufbaut
- Alles, was Pakete installieren, Code kompilieren oder System-Utilities aufrufen muss
- Kurz: alles, was tatsächlich einen Rechner braucht
Wie Puppyone sie unterstützt
Puppyones Docker-Sandbox ist auf API-Ebene kompatibel mit E2B — wenn Ihr Agent bereits auf E2B läuft, können Sie ihn ohne Änderungen an der Geschäftslogik auf Puppyone umlenken. Sandbox.create(), runCode(), commands.run(), Datei-I/O — alles passt eins zu eins. Was Sie zusätzlich gewinnen: Sandbox und Dateisystem sind eine Einheit. Sie müssen nicht mehr die umständliche Kette "Dateien in der Sandbox → in Object Storage persistieren → in die nächste Sandbox synchronisieren" verwalten. Jeder Schreibvorgang landet im Puppyone-Dateisystem mit Versionshistorie, Berechtigungen und Audit-Logs — derselbe Zustand, sichtbar über Tasks, Agenten und sogar Sandbox-Typen hinweg.
Die Cloudflare-basierte Sandbox
Wie sie funktioniert
Agent-Code läuft in einem V8 Isolate auf Cloudflares globalem Edge-Netzwerk — derselben Technologie, die Chrome zum Isolieren von Browser-Tabs einsetzt. Jedes Isolate ist ein abgeschotteter JavaScript-Ausführungskontext, der in Millisekunden startet (kein Betriebssystem zum Hochfahren) und nach dem Request wieder zerstört wird. Anfragen werden an den Edge-Standort geroutet, der dem Nutzer am nächsten liegt — Round-Trip-Latenzen bleiben im zweistelligen Millisekundenbereich.
Was Sie bekommen
Cold Starts im Millisekundenbereich. Ein einzelnes Isolate startet in unter 5 ms — etwa drei Größenordnungen schneller als ein Container. Sie können sich leisten, für jeden Request eine frische Sandbox zu starten — ohne Warm-Pool, ohne dauerhafte Instanzen.
Nur JavaScript / WebAssembly. Kein Python, keine Shell, keine nativen Binaries. Ihre Logik ist entweder JS/TS oder kompiliert nach WASM. Die meisten Node.js-Built-ins sind verfügbar, aber alles, was auf Systemcalls angewiesen ist (fs, child_process, native C-Erweiterungen), ist es nicht.
128 MB Speicherobergrenze, 30 Sekunden CPU pro Request. Jeder Request bekommt maximal 128 MB Speicher und 30 Sekunden CPU-Zeit (auf bezahlten Plänen bis zu 5 Minuten konfigurierbar). Wichtig zu wissen: Es zählt nur aktive CPU-Zeit — Wartezeit auf fetch() oder eine Datenbankabfrage zählt nicht, sodass ein Request mit 30-Sekunden-CPU-Limit in Wirklichkeit mehrere Minuten Wanduhrzeit offen bleiben kann.
Kein lokales Dateisystem. Isolates sind zustandslos. Was persistiert werden muss, geht in externen Storage — Cloudflare KV, R2, D1 oder Ihre eigene Datenbank. Um Zwischenzustand über Requests hinweg zu teilen, serialisieren Sie ihn raus und lesen ihn wieder ein, oder lagern es in einen separaten zustandsbehafteten Dienst aus.
Globale Edge-Ausführung + Autoscaling. Ihr Code wird automatisch über Cloudflares 300+ Edge-Standorte ausgerollt und läuft jeweils dort, wo es dem Nutzer am nächsten ist. Von null bis zu zehntausenden QPS müssen Sie keine Kapazität planen — die Plattform regelt das.
Cloudflares Security-Layer gibt's gratis. DDoS-Schutz, Rate Limiting, Bot Management, TLS-Terminierung — alles ist im Netzwerk eingebaut. Sie müssen dafür keinen separaten Layer aufstellen.
Abrechnung nur nach aktiven CPU-Millisekunden. Wartet das Isolate auf fetch(), eine Datenbank oder ein Nutzerereignis, zahlen Sie nicht. Berechnet werden nur die Millisekunden, in denen V8 tatsächlich Code ausführt. Für I/O-lastige Workloads — etwa Agenten, die hauptsächlich LLMs aufrufen und API-Antworten aggregieren — sind die Wartezeit-Kosten praktisch null.
Wann sie nicht passt
- Tasks, die Pakete installieren, Python / Shell oder native Binaries ausführen müssen
- Einzelne Workloads, die mehr als ein paar Minuten CPU brauchen
- Workflows, die in der Sandbox lokale Dateien lesen/schreiben oder Zustand zwischen Requests halten
- Speicherintensive Tasks, die mehr als 128 MB brauchen
Wann sie passt
- Hochparallele, kurzlebige Requests (Parsing, Transformation, Filtering, Routing)
- Als "Vordertür" des Agenten — schnell entscheiden, Parameter extrahieren, das nächste Tool wählen
- Global verteilte Low-Latency-Dienste (smarte API-Gateways, Edge-RAG)
- Glue-Code, der Cloudflare-Primitive (KV, R2, D1, Queues) verbindet
Wie Puppyone sie unterstützt
Die Cloudflare-Sandbox befindet sich derzeit in der Entwicklung und ist noch nicht öffentlich verfügbar. Wir verdrahten sie genau so mit dem Puppyone-Dateisystem wie die Docker-Sandbox: Wenn JS-Code in einem Isolate eine "Datei schreibt", ist das ein versionierter, berechtigter, auditierbarer Commit in Puppyone — und teilt sich Zustand mit der Docker-Sandbox. Derselbe Agent wird schwere Berechnungen in einer Docker-Sandbox laufen lassen und am Edge in einer Cloudflare-Sandbox antworten können — und beide schauen auf denselben Workspace.
Wenn Ihr Use-Case Edge-Ausführung braucht, abonnieren Sie unsere Updates — wir geben Bescheid, sobald es soweit ist.
Direkter Vergleich
Eine kompakte Übersicht aller oben genannten Punkte in einer Tabelle, die sich überfliegen lässt.
| Dimension | Docker-Sandbox | Cloudflare-Sandbox |
|---|---|---|
| Zugrundeliegende Technik | Linux-Container (Namespaces + cgroups) | V8 Isolates |
| Cold Start | 2-10 Sekunden | < 5 Millisekunden |
| Runtime | Python, Node, Go, Shell — beliebige Linux-Binaries | JavaScript / TypeScript / WebAssembly |
| Pakete installieren? | ✅ apt, pip, npm, eigenes Dockerfile | ❌ Muss vorab gebündelt sein |
| Subprozesse? | ✅ | ❌ |
| Lokales Dateisystem | ✅ Vollständig POSIX, gemountet zu Puppyone | ❌ Nur externer Storage (KV / R2 / D1) |
| Standardressourcen | 2 vCPU + 512 MB | 128 MB Speicher |
| Maximale Ressourcen | 8 vCPU + 8 GB (konfigurierbar) | 128 MB Speicher (fix) |
| Dauer pro Ausführung | Standard 5 Min, bis 24 Std | Standard 30 Sek CPU, bis 5 Min (zahlend) |
| Zustandserhaltung | pause / resume-Snapshots (Speicher + FS) | Keine (jeder Request bekommt ein neues Isolate) |
| Concurrency-Modell | Ein Container pro Sandbox (echte Ressourcen) | Tausende Isolates pro Maschine |
| Geografische Verteilung | Eine Region | 300+ Edge-Standorte, automatisches Routing |
| Egress-Kontrolle | Domain/Port-Allowlist | Konfiguriert über Workers |
| Plattform-Security | Selbst aufstellen | DDoS / Rate Limit / Bot / TLS eingebaut |
| Abrechnungsgranularität | Pro Sekunde Container-Laufzeit (inkl. Wartezeit) | Pro Millisekunde aktiver CPU (Warten zählt nicht) |
| Prozessmodell | Run-and-Tear-Down | On-Demand, kein Maintenance |
| API-Kompatibilität | Kompatibel mit E2B | Cloudflare Workers API |
| Puppyone-Status | ✅ Verfügbar | 🚧 In Entwicklung, noch nicht offen |
| Typische Einsatzfelder | 5-Min-Datenverarbeitung, Python mit Paketen, mehrstufige Workflows | Millisekunden-Routing, hochparallele JS-Logik, Edge-APIs |
| Ein 10-Minuten-Agent — welche? | Docker, wenn er tatsächlich rechnet | Cloudflare, wenn er 90 % der Zeit auf LLMs/APIs wartet |
Wie Sie wählen
Bei der Wahl der Sandbox geht es nicht darum, welche "besser" ist, sondern darum, wie Ihr Workload tatsächlich aussieht. Die folgenden fünf Dimensionen decken fast jede reale Entscheidung ab.
1. Runtime-Sprache
Wenn Ihr Agent Python, Shell, Go oder native Binaries braucht (denken Sie an ffmpeg, pandoc, git) — dann muss es Docker sein. Cloudflare kann nur JavaScript / TypeScript / WebAssembly. Nicht mal pip install ist drin.
Wenn Ihre Geschäftslogik bereits JS / TS ist und nicht in Systemcalls greift — beides geht. Lesen Sie weiter.
2. Task-Dauer
| Task-Dauer | Wahl | Warum |
|---|---|---|
| < 30 Sek CPU | Cloudflare | Millisekunden-Start + Pro-ms-Abrechnung — mit Abstand am günstigsten |
| 30 Sek - 5 Min CPU | Cloudflare (zahlende Pläne dehnen auf 5 Min) | Noch innerhalb des Limits |
| Mehrere Minuten bis Stunden | Docker | Cloudflare läuft in seine CPU-Decke |
| Mehrtägige Workflows | Docker + pause / resume-Snapshots | Zustand einfrieren und später weitermachen |
3. Kostenstruktur (die Dimension, bei der die meisten falsch wählen)
Die beiden Abrechnungsmodelle unterscheiden sich grundlegend — derselbe Workload kann eine Größenordnung mehr kosten, wenn Sie sich falsch entscheiden.
- Docker rechnet die Zeit ab, in der der Container existiert. Die Uhr läuft, sobald der Container hochfährt — egal, ob die CPU gerade etwas tut. Das belohnt kurze, dichte Arbeit: Task starten, fertig, Container killen. Lassen Sie einen leerlaufenden Container auf Nutzer-Input oder eine LLM-Antwort warten, zahlen Sie für diese Wartezeit.
- Cloudflare rechnet ausschließlich aktive CPU-Millisekunden ab. Wartet das Isolate auf
fetch(), eine Datenbank oder eine LLM-Streamingantwort, zahlen Sie nicht. Berechnet werden nur die Millisekunden, in denen V8 tatsächlich Code ausführt.
Konkret:
- Ein 5-Min-Datenverarbeitungstask (CPU dauerhaft am Anschlag) → Docker ist günstiger
- 10.000 Nutzer pro Sekunde, jeder löst 50 ms Logik aus → Cloudflare ist um Größenordnungen günstiger
- Ein 30-Min-Agent, der 90 % der Zeit auf LLM-Streams wartet → Cloudflare ist drastisch günstiger; Docker rechnet die vollen 30 Minuten ab
Vergleichen Sie keine Stundenpreise. Vergleichen Sie, welcher Anteil der Wanduhrzeit Ihres Workloads tatsächlich rechnet. Dieses Verhältnis entscheidet, welches Modell gewinnt.
4. Concurrency
- Wenige bis ein paar Dutzend Requests pro Sekunde → beides geht
- Hunderte pro Sekunde, jeweils kurz → Cloudflare (Tausende Isolates pro Maschine; Docker bräuchte einen Container pro paralleler Anfrage)
- Wenige Requests pro Sekunde, aber jeder mehrere Minuten Berechnung → Docker (Cloudflare hält das nicht durch)
5. Datenmenge und Zustand
- Tasks, die viele Dateien lesen/schreiben, GB-große Artefakte erzeugen oder einen mehrstufigen Workspace pflegen → Docker (echtes Dateisystem, gemountet zu Puppyone, automatisch versioniert)
- Tasks, die nur ein paar APIs aufrufen, leicht transformieren und in externen Storage zurückschreiben → Cloudflare (kein lokales Dateisystem, aber KV / R2 / D1 sind schnell zu lesen)
- Mehr als 128 MB Speicher → Docker (ein einzelnes Cloudflare-Isolate ist auf 128 MB begrenzt)
Immer noch unsicher? Standardmäßig Docker. Seine Fähigkeiten sind eine echte Obermenge der Cloudflare-Sandbox — Sie können sich praktisch nicht falsch entscheiden, zahlen höchstens etwas mehr in extremen High-Concurrency- oder I/O-lastigen Szenarien. Wenn der Traffic wirklich groß genug wird, können Sie die heißen Pfade später auf Cloudflare migrieren.
Die ideale Architektur, sobald Cloudflare-Sandboxes offen sind: beide arbeiten zusammen. Cloudflare-Sandboxes als Vordertür des Agenten — Routing in Millisekunden, Parameter extrahieren, leichte Entscheidungen. Wenn der Workload echte Rechenleistung braucht, wird er in eine Docker-Sandbox dispatched. Cloudflare übernimmt den schnellen Pfad; Docker die schwere Arbeit; dasselbe Puppyone-Dateisystem verbindet beide Enden.
Loslegen mit Sandboxes auf Puppyone
Wenn Ihr Agent bereits auf E2B läuft, lenken Sie ihn einfach auf Puppyone um — Sandbox.create(), runCode(), commands.run() sind alle API-kompatibel, kein Eingriff in die Geschäftslogik nötig, und Sie bekommen sofort Versionierung, Berechtigungen und Audit-Logs auf Dateisystemebene.
Wenn Sie bei null anfangen, zeigt Ihnen die Puppyone-Dokumentation im Quick-Start-Guide, wie Sie in wenigen Codezeilen eine Sandbox mit versioniertem Dateisystem hochziehen.
Brauchen Sie die Cloudflare-Edge-Sandbox? Updates abonnieren — wir geben Bescheid, sobald sie offen ist.