Cloudflare Containers, für skalierbare Agent-Sandboxes neu aufgebaut, tauscht statische Bereitstellung gegen Laufzeitkontrolle

Cloudflare Containers, für skalierbare Agent-Sandboxes neu aufgebaut, startet laut dem Unternehmen nun mehr als sechsmal schneller. Das Release vom 30. September ergänzt außerdem die Auswahl von Images zur Laufzeit, die Dimensionierung von Instanzen zur Laufzeit sowie Dateisystem-Snapshots in der öffentlichen Beta.

Die entscheidende Änderung ist nicht allein ein kürzerer Kaltstart. Cloudflare hat die Kontrolle über jede Sandbox in ein Durable Object verlagert, seine zustandsbehaftete serverlose Komponente zur Koordinierung von Anfragen und persistentem Anwendungszustand. Diese Entscheidung stellt das statische Bereitstellungsmodell infrage, das die erste Version von Cloudflare Containers geprägt hat.

Entwickler können nun einen Agenten die für jede Aufgabe erforderliche Umgebung auswählen lassen. Eine Programmieraufgabe benötigt möglicherweise eine größere Instanz und eine vollständige Linux-Toolchain. Eine kleinere Automatisierung kann eine schlankere Umgebung nutzen. Wenn die Arbeit pausiert, kann das System das Dateisystem speichern, die Rechenressourcen anhalten und den Arbeitsbereich später wiederherstellen.

Damit positioniert sich Cloudflare unmittelbarer in einem umkämpften Markt für Agent-Infrastruktur. E2B, Modal, Daytona, Vercel und Hyperscale-Cloud-Dienste bieten bereits unterschiedliche Ansätze für isolierte Ausführung. Cloudflare argumentiert, dass ein global adressierbarer Controller, ein isolierter Linux-Arbeitsbereich und persistenter Zustand als eine programmierbare Einheit arbeiten sollten.

Die Architektur erscheint für Coding-Agenten, Evaluierungen und langlaufende Workflows geeignet. Die Behauptung eines sechsmal schnelleren Starts stammt jedoch von Cloudflare, Snapshots befinden sich weiterhin in der öffentlichen Beta, und mehrere betriebliche Grenzen sind relevant. Der eigentliche Test wird sein, ob Teams verlässliche Kontrolle gewinnen, ohne zu viel Komplexität beim Lebenszyklus zu übernehmen.

Cloudflare Containers, für skalierbare Agent-Sandboxes neu aufgebaut, verändert die Control Plane

Cloudflares zentrale Änderung besteht darin, die Konfiguration von Sandboxes vom Bereitstellungszeitpunkt auf den Moment zu verlagern, in dem ein Agent eine Aufgabe startet.

Im früheren Modell deklarierte eine Anwendung in ihrer Bereitstellungskonfiguration in der Regel ein Container-Image und einen Instanztyp. Die Änderung einer dieser Einstellungen löste einen Rollout auf Anwendungsebene aus. Dieses Muster funktioniert für vorhersehbare Dienste, doch Agenten erzeugen Workloads, die von Anfrage zu Anfrage variieren.

Ein Agent zur Code-Reparatur benötigt möglicherweise ein Repository, einen Compiler, einen Paketmanager, einen Browser und eine Testsuite. Ein Evaluierungs-Worker benötigt möglicherweise eine saubere, reproduzierbare Umgebung mit streng kontrollierten Eingaben. Eine andere Aufgabe erfordert eventuell nur ein kurzes Skript mit begrenztem Speicher und ohne Internetzugang.

Die neue durable_object-Scheduling-Richtlinie von Cloudflare erlaubt es Anwendungscode, diese Entscheidungen zur Laufzeit zu treffen. Das steuernde Durable Object ruft ctx.container.start() auf und übergibt ein für die jeweilige Aufgabe geeignetes Image, einen Snapshot und eine Instanzkonfiguration.

Zu den verfügbaren vordefinierten Größen gehören lite und vier standard-Konfigurationen. Entwickler können außerdem benutzerdefinierte Werte für CPU, Arbeitsspeicher und Festplatte innerhalb der Plattformgrenzen übergeben. Die Scheduling-Richtlinie zur Laufzeit ersetzt eine zentral ausgewählte Konfiguration durch Entscheidungen pro Sandbox.

Die Image-Auswahl folgt demselben Modell. Entwickler deklarieren benannte Images über Wrangler, Cloudflares Befehlszeilentool für Bereitstellungen. Die Plattform bereitet unveränderliche Referenzen vor, und das Durable Object wählt beim Start einer Sandbox eine davon aus.

Diese Anordnung ermöglicht es einer Anwendung, mehrere Agentenrollen zu unterstützen, ohne für jede Rolle eine eigene Container-Anwendung bereitzustellen. Ein Koordinator kann eine schlanke Rechercheaufgabe einem Image zuweisen und anschließend einen Build-Job einem anderen Image mit mehr Ressourcen übergeben.

Cloudflare führte außerdem cloudflare/debian-trixie ein, ein verwaltetes Debian-Image mit Node.js. Ein Agent kann mit dieser Grundlage starten, seine Tools über exec() installieren und den daraus resultierenden Arbeitsbereich als Snapshot sichern.

Laut Cloudflares Sandbox-Ankündigung startet der neue Scheduling-Pfad Containers mehr als sechsmal schneller. Das Unternehmen erklärt, mehrere Koordinierungsschritte entfernt zu haben, die zuvor zwischen dem Durable Object und der Container-Laufzeitumgebung lagen.

Diese Behauptung erfordert eine vorsichtige Einordnung. Cloudflare hat keinen unabhängigen Benchmark vorgelegt, der repräsentative Images, Regionen oder Workload-Typen vergleicht. Die Bereitschaft eines Containers hängt zudem von der Image-Größe, dem Verhalten des Entrypoints, der Kapazität und anwendungsseitigen Health Checks ab.

Die eigene Architekturdokumentation von Cloudflare besagt, dass Kaltstarts häufig zwischen einer und drei Sekunden liegen. Sie weist außerdem darauf hin, dass die Startzeit je nach Image und dessen Initialisierungsarbeit variiert. Ein schnellerer Scheduler kann Verzögerungen nicht beseitigen, die innerhalb des Images selbst entstehen.

Die Plattform stellt eine running-Eigenschaft bereit, bevor ein Prozess notwendigerweise bereit ist, Datenverkehr anzunehmen. Entwickler müssen daher weiterhin die Port-Bereitschaft prüfen, bevor sie die erste Anfrage senden. Für einen Agenten bleiben „Container gestartet“ und „Arbeitsbereich für sinnvolle Arbeit bereit“ unterschiedliche Messgrößen.

Selbst unter diesen Vorbehalten verändert die Laufzeitkonfiguration das Betriebsmodell des Produkts. Cloudflare Containers sind nicht länger nur bereitgestellte Dienste, die Agenten zufällig nutzen. Sie werden zu Ressourcen, die ein Agenten-Controller für einzelne Aufgaben zusammenstellen, dimensionieren, anhalten und rekonstruieren kann.

Schnellere Agent-Sandboxes setzen statische Bereitstellungsmodelle unter Druck

Agenten-Workloads profitieren von Infrastruktur, die zwischen Aufgaben ihre Form ändern kann, nicht bloß von Infrastruktur, die ein Image effizient ausführt.

Traditionelle Container-Plattformen gehen davon aus, dass Entwickler die Form der Anwendung vor der Bereitstellung kennen. Teams wählen ein Image, eine Ressourcenzuweisung, eine Netzwerkrichtlinie und eine Skalierungskonfiguration. Ein Scheduler erstellt dann Replikate, die diese Eigenschaften weitgehend teilen.

Agentensysteme erschüttern diese Annahme. Ihre nächste Aktion hängt von Nutzeranfragen, Modellentscheidungen, Tool-Ergebnissen und dem Zustand ab, den frühere Arbeit hinterlassen hat. Zwei aufeinanderfolgende Aufgaben innerhalb desselben Produkts können unterschiedliche Betriebssysteme, Abhängigkeiten, Ressourcenlimits und Netzwerkberechtigungen benötigen.

Diese Variabilität setzt Anbieter unter Druck, die auf statischer Anwendungskonfiguration beruhen. Teams können weiterhin mehrere Dienste bereitstellen und Arbeit zwischen ihnen verteilen. Jeder neue Workload-Typ fügt jedoch eine weitere Bereitstellungseinheit, einen weiteren Rollout-Pfad, eine weitere Kapazitätsentscheidung und eine weitere Quelle für Konfigurationsdrift hinzu.

Cloudflares Laufzeitmodell verlagert einen Teil dieser Entscheidung in den Anwendungscode. Der Agenten-Controller kann nach Prüfung der Aufgabe ein Sandbox-Image und einen Instanztyp auswählen. Er kann außerdem entscheiden, ob die Sandbox Internetzugang erhält oder von einem gespeicherten Snapshot startet.

Der wichtigste Gegner ist daher kein einzelner namentlich genannter Anbieter. Es ist das statische Bereitstellungsmodell, das jede Sandbox einer Anwendung als Kopie desselben vordefinierten Dienstes behandelt.

E2B, Modal, Daytona und Vercel bedienen diesen Markt bereits mit eigenen Abstraktionen. Einige betonen entwicklerfreundliche Sandbox-APIs. Andere basieren auf Funktionen, virtuellen Maschinen, Arbeitsbereichen oder umfassenderer Cloud-Orchestrierung. Teams, die Kubernetes oder Firecracker direkt betreiben, erhalten mehr Kontrolle, verantworten jedoch auch mehr Infrastruktur.

Cloudflares Differenzierungsmerkmal ist die Beziehung zwischen jedem Container und seinem Durable Object. Ein Durable Object stellt eine stabile Identität, Anwendungscode, Speicher, Alarme und Koordination außerhalb der Linux-Umgebung bereit. Der Container liefert isolierte Rechenleistung für Tools, die ein konventionelles Betriebssystem benötigen.

Die Entscheidungsschleife des Agenten kann aktiv bleiben, während der Linux-Arbeitsbereich ruht. Sie kann mit Nutzern kommunizieren, Autorisierungszustände bewahren und Modelle aufrufen, ohne die schwergewichtigere Sandbox weiterlaufen zu lassen. Wenn ein Compiler oder Entwicklungsserver erforderlich wird, aktiviert der Controller den Container.

Cloudflare beschreibt diese Trennung als das Abtrennen des „Gehirns“ des Agenten von seinen „Händen“. Der Controller bewahrt Absicht und Zustand, während die Sandbox Befehle ausführt, die scheitern, stoppen oder ersetzt werden müssen.

Diese Trennung bietet neben betrieblichen auch Sicherheitsvorteile. Das Durable Object kann Zugangsdaten außerhalb des Containers halten und ausgehende Anfragen vermitteln. Ein Agent benötigt nicht zwingend direkten Zugriff auf jedes Secret, das für einen autorisierten Dienstaufruf erforderlich ist.

Cloudflare hatte zuvor argumentiert, dass dynamisch generierter Agenten-Code eine isolierte Ausführungsumgebung erfordert. Sein früheres Code-Sandbox-Modell konzentrierte sich auf schlanke Dynamic Workers für Aufgaben, die kein vollständiges Linux-System benötigen.

Containers deckt die anspruchsvollere Seite dieser Aufteilung ab. Sie unterstützen Paketmanager, native Binärdateien, Repositories, Compiler, Terminals und Entwicklungsserver. Dynamic Workers können kleinere Code-Ausführungsaufgaben mit einer enger abgegrenzten Laufzeitumgebung übernehmen.

Dadurch entsteht eine gestufte Ausführungsstrategie. Ein Controller kann für einen kurzen API-Workflow eine schlanke Sandbox verwenden und einen Container für Arbeiten reservieren, die Linux erfordern. Die Auswahl zur Laufzeit ist relevant, weil es Startzeit und Ressourcen verschwendet, jede Aufgabe in einem vollständigen Container auszuführen.

Der Druck reicht über Sandbox-Anbieter hinaus. Interne Plattformteams unterhalten häufig Pools warmer Entwicklungsumgebungen, um Bereitstellungsverzögerungen zu verbergen. Schnellere Kaltstarts und wiederaufnehmbare Dateisysteme schwächen das Argument, große ungenutzte Pools bereitzuhalten.

Cloudflare beseitigt Orchestrierung jedoch nicht. Es verlagert sie in das Durable Object und dessen Anwendungscode. Teams müssen weiterhin Zugangsregeln, Nebenläufigkeitskontrollen, Wiederholungsverhalten, Autorisierung, Bereinigung und Observability entwerfen.

Das Gewinner-Modell wird nicht die Plattform sein, die die geringste isolierte Startzeit ausweist. Es wird das Modell sein, das die Gesamtzeit von der Entscheidung eines Agenten bis zu einem verifizierten Aufgabenergebnis minimiert.

Dazu gehören Image-Vorbereitung, Repository-Zugriff, Wiederherstellung von Abhängigkeiten, Befehlsausführung, Netzwerklatenz und Abbau. Dazu gehört auch die Verzögerung für Menschen, die durch fehlgeschlagene Sitzungen oder verlorene Arbeit entsteht.

Für Engineering-Teams, die Optionen vergleichen, sollte der relevante Benchmark ihren vollständigen Workflow nachbilden. Ein synthetischer Test mit einem leeren Container kann weder ein großes Repository noch Paketinstallation, Browserstart oder eine Testsuite abbilden.

Diese Evaluierungen erzeugen zudem Designwissen, das Teams bewahren müssen. Eine durchsuchbare Engineering-Wissensbasis kann Benchmark-Annahmen, Sicherheitsentscheidungen und Migrationserkenntnisse neben der Implementierung festhalten.

Durable Objects machen Containers zu aufgabenspezifischer Rechenleistung

Der Mechanismus hinter dem Release ist ein zustandsbehafteter Controller, der seinen Container als austauschbare Rechenleistung statt als permanenten Anwendungszustand behandelt.

Jeder Cloudflare Container ist einem Durable Object zugeordnet. Anfragen erreichen zunächst einen Worker und werden dann über dieses Objekt geleitet, bevor sie den Container erreichen. Das Durable Object kann einen bestimmten Arbeitsbereich adressieren und mit seiner Identität verbundenen Zustand bewahren.

Mit der neuen API erweitern Entwickler DurableObject direkt und greifen über this.ctx.container auf den angehängten Container zu. Dadurch entfällt die Wrapper-Klasse, mit der Cloudflare Containers ursprünglich konventionellen Sandbox-Diensten ähneln ließ.

Der Controller kann den Container starten, Befehle ausführen, ihn prüfen, Beendigungen überwachen, Prozesssignale senden, ein Inaktivitäts-Timeout festlegen und die Instanz zerstören. Er kann diese Steuerungsmöglichkeiten mit Durable-Object-Speicher, Alarmen, WebSockets und Remote-Procedure-Calls kombinieren.

Stellen Sie sich einen Coding-Agenten vor, der auf einen Bugreport reagiert. Das Durable Object kann die Sitzungskennung, das freigegebene Repository, Nutzerberechtigungen und die aktuelle Aufgabenphase speichern. Anschließend kann es ein Image mit der passenden Sprach-Toolchain auswählen und eine geeignete Instanz starten.

Der Container klont das Repository, installiert Abhängigkeiten, führt die Testsuite aus und bearbeitet Dateien. Währenddessen kann das Durable Object Fortschrittsmeldungen über einen WebSocket senden und Prüfpunkte außerhalb des Containers aufzeichnen.

Wenn der Containerprozess beendet wird, behält der Controller die Identität und Metadaten der Sitzung. Er kann den Fehler untersuchen, von einem bekannten Zustand neu starten oder das Problem melden, ohne die gesamte Interaktion zu verlieren.

Cloudflare führt jeden Container in einer Firecracker-MicroVM aus, einer schlanken virtuellen Maschine mit eigenem Kernel und Netzwerk. Das Kunden-Image läuft als Linux-Container innerhalb dieser virtuellen Maschine.

Die Container-Architektur der Plattform besagt, dass andere Cloudflare-Workloads diesen Kernel nicht gemeinsam nutzen. Diese Isolation ist wichtig, weil von Agenten erzeugte Befehle nicht direkt innerhalb der Anwendung ausgeführt werden sollten, die vertrauenswürdige Nutzerdaten verarbeitet.

Die Platzierung bleibt dynamisch. Cloudflare wählt verfügbare Kapazität aus, auf der das benötigte Image vorhanden ist; Routing und Startgeschwindigkeit beeinflussen den Standort. Durable Object und Container werden nicht zwingend am selben Ort ausgeführt.

Dieser Vorbehalt ist für latenzsensitive Kontrollschleifen wichtig. Eine global adressierbare Identität bedeutet nicht, dass jede Operation nahe beim Nutzer, beim Modellanbieter oder bei der Sandbox läuft. Teams sollten den vollständigen Anfragepfad über die von ihnen erwarteten Regionen hinweg messen.

Kapazität kann auch zwischen Sitzungen wechseln. Wenn ein Container stoppt und später neu startet, kann Cloudflare den Ersatz an einem anderen Ort platzieren. Anwendungen dürfen die lokale Identität eines einzelnen Rechners nicht als dauerhaft behandeln.

Das Durable Object wird zur Kontinuitätsschicht. Es speichert die Informationen, die erforderlich sind, um den Workspace zu finden, neu aufzubauen oder wiederherzustellen. Die Linux-Instanz wird zu einer Ausführungsressource, die im Leerlauf verschwinden kann.

Diese Architektur unterstützt auch verzweigte Workloads. Ein Koordinator kann mehrere unabhängige Versuche aus derselben vorbereiteten Ausgangsbasis starten. Jeder Versuch kann ein anderes Modell, einen anderen System-Prompt, ein anderes Skill-Set oder eine andere Reparaturstrategie testen.

Der Controller kann diese Durchläufe überwachen, die Ergebnisse vergleichen und die bevorzugte Ausgabe bewahren. Reinforcement-Learning-Systeme können ähnliche Muster nutzen, um kontrollierte Umgebungen zu erstellen, Ergebnisse zu bewerten und den Zustand zwischen Versuchen zurückzusetzen.

Die Dimensionierung von Laufzeitinstanzen stärkt dieses Modell. Ein Controller kann Builds mehr Ressourcen zuweisen und die Ressourcen für leichtere Befehle reduzieren. Eine statische, anwendungsweite Dimensionierung würde Teams dazu zwingen, für die größte übliche Aufgabe zu provisionieren oder getrennte Deployments zu betreiben.

Doch Programmierbarkeit verlagert Verantwortung auf die Anwendung. Der Controller muss verhindern, dass ein Modell unbegrenzt Ressourcen auswählt. Er sollte Agentenanfragen auf genehmigte Richtlinien abbilden, anstatt beliebige Modellausgaben an Infrastruktur-APIs weiterzugeben.

Dasselbe Prinzip gilt für Images. Die Auswahl zur Laufzeit zu erlauben, bedeutet nicht, einem Agenten die Ausführung jedes ungeprüften Images zu gestatten. Cloudflare verlangt deklarierte, per Digest fixierte Image-Referenzen, was die Reproduzierbarkeit von Deployments unterstützt.

Teams sollten dennoch eine Image-Allowlist pflegen, Abhängigkeiten scannen, ausgehenden Zugriff beschränken und Anmeldedaten von der Gastumgebung trennen. Eine Sandbox verringert die Angriffsfläche, definiert jedoch nicht die vollständige Sicherheitsrichtlinie.

Operativ sollte das Durable Object die Quelle der Wahrheit für den Lebenszykluszustand bleiben. Die direkte API von Cloudflare ermöglicht Kontrolle, doch Anwendungen müssen entscheiden, wann eine Aufgabe wiederherstellbar, aufgegeben, abgeschlossen oder sicher erneut ausführbar ist.

Darin liegt der eigentliche Mechanismus hinter schnelleren Agenten-Sandboxes. Die Scheduler-Verbesserung ist relevant, doch die dauerhafte Veränderung ist eine explizite Control Plane, die über jeden einzelnen Containerprozess hinaus fortbesteht.

Dateisystem-Snapshots bewahren Dateien, keine laufenden Sitzungen

Snapshots verringern wiederholten Einrichtungsaufwand, sind jedoch unveränderliche Dateisystem-Prüfpunkte und keine vollständigen Suspend-and-Resume-Images.

Die nativen Dateisystem-Snapshots von Cloudflare sind über die durable_object-Scheduling-Richtlinie als öffentliche Beta verfügbar. Ein laufender Container ruft snapshotContainer() auf, um sein beschreibbares Root-Dateisystem zu einem bestimmten Zeitpunkt zu erfassen.

Der zurückgegebene Handle enthält eine Kennung, Größe und einen optionalen Namen. Entwickler müssen diesen Handle speichern, häufig im Durable-Object-Speicher, da die Worker-API keinen Befehl zum Auflisten von Snapshots bereitstellt.

Ein späterer Container kann anhand des gespeicherten Handles starten. Dadurch wird ein Coding-Workspace wiederherstellbar, nachdem die ursprüngliche Recheninstanz beendet wurde. Das Repository, installierte Abhängigkeiten, Build-Caches, Konfigurationsdateien und Bearbeitungen können mit dem wiederhergestellten Dateisystem zurückkehren.

Dieses Modell löst eine häufige Diskrepanz in der Agenteninfrastruktur. Das Starten einer leeren Sandbox kann Sekunden dauern, während die Vorbereitung einer nützlichen Entwicklungsumgebung Minuten beanspruchen kann. Wiederholte Abhängigkeitsinstallationen können die Startzeit dominieren, die Nutzer tatsächlich wahrnehmen.

Snapshots bieten zudem eine stabile Ausgangsbasis für Evaluierungen. Ein Team kann ein Repository und eine Toolchain vorbereiten, speichern und mehrere Experimente vom selben Prüfpunkt aus starten. Jede Sandbox erhält nach der Wiederherstellung eine unabhängige, beschreibbare Umgebung.

Das verringert Umgebungsdrift zwischen Versuchen. Wenn zwei Modellversionen unterschiedliche Abhängigkeitszustände sehen, lassen sich Testergebnisse schwerer vergleichen. Ein gemeinsamer unveränderlicher Prüfpunkt hilft, die zu evaluierende Variable zu isolieren.

Die Funktion unterstützt auch längere Projekte. Ein Agent kann seinen Workspace speichern, wenn ein Nutzer die Sitzung verlässt, die Recheninstanz anhalten und die Dateien wiederherstellen, wenn der Nutzer zurückkehrt. So wird Dateisystemkontinuität von kontinuierlicher Ressourcennutzung getrennt.

Allerdings kann das Wort „Snapshot“ mehr nahelegen, als Cloudflare derzeit bewahrt. Laut der Snapshot-Dokumentation erfasst das System das vollständige Container-Dateisystem, jedoch weder Speicher, laufende Prozesse noch separat eingehängte Dateisysteme.

Ein wiederhergestellter Container führt seinen Entrypoint erneut aus. Ein Build im Arbeitsspeicher, ein aktiver Debugger, ein Terminalprozess oder ein Entwicklungsserver wird nicht exakt an der Instruktion fortgesetzt, an der er angehalten wurde. Die Anwendung muss diese Prozesse neu aufbauen.

Snapshots sind außerdem an die Image-Version gebunden, mit der sie erstellt wurden. Entwickler können einen Snapshot nicht in einem anderen Image wiederherstellen. Wenn sich ein Basis-Image ändert, muss das Team einen neuen kompatiblen Snapshot erstellen.

Jeder Snapshot-Handle hat eine implizite Lebensdauer von 30 Tagen. Seine Wiederherstellung erneuert diesen Zeitraum, doch Entwickler können derzeit kein anderes Aufbewahrungsintervall konfigurieren. Diese Einschränkung macht Snapshots ohne externen Aufbewahrungsplan ungeeignet als unbefristetes Archiv.

Die Snapshots sind unveränderlich. Nach der Wiederherstellung vorgenommene Änderungen erfordern einen weiteren Snapshot, wenn das Team sie bewahren möchte. Anwendungen benötigen daher Prüfpunkt-Richtlinien, die Wiederherstellungswert gegen Speicherbedarf, Latenz und operative Komplexität abwägen.

Der Status als öffentliche Beta ist ein weiterer Grund zur Vorsicht. Produktionsteams sollten die Erstellung und Wiederherstellung von Snapshots bei Unterbrechungen, gleichzeitigem Zugriff, Image-Updates und Änderungen der regionalen Platzierung validieren.

Sie sollten auch Fehlergrenzen testen. Stoppt der Container während eines Prüfpunkts, benötigt die Anwendung eine eindeutige Aufzeichnung darüber, welcher Snapshot weiterhin gültig ist. Wenn eine Aufgabe ein externes System verändert, setzt die Wiederherstellung des Dateisystems diese externe Aktion nicht zurück.

Diese Unterscheidung ist besonders für autonome Agenten wichtig. Ein Rollback kann lokale Dateien wiederherstellen, während ein Pull Request, ein Datenbank-Update, eine E-Mail oder eine Cloud-Ressource unverändert bleibt. Ein blindes Wiederholen der Aufgabe könnte eine irreversible Aktion duplizieren.

Der Controller benötigt deshalb ein Aufgabenjournal außerhalb der Sandbox. Es sollte genehmigte Operationen, externe Nebenwirkungen und abgeschlossene Prüfpunkte aufzeichnen. Das Dateisystem allein kann nicht die vollständige Wahrheit über die Arbeit eines Agenten abbilden.

Sicherheitsteams müssen zudem prüfen, was Snapshots bewahren. Repositories, generierter Code, Logs, zwischengespeicherte Pakete und temporäre Anmeldedaten können sämtlich in das beschreibbare Dateisystem gelangen. Ein Snapshot kann sensibles Material länger als die laufende Sitzung aufbewahren.

Cloudflare bietet das Abfangen ausgehender Anfragen und die externe Verwaltung von Anmeldedaten, was die Preisgabe von Secrets innerhalb des Gasts verringern kann. Entwickler sollten dennoch prüfen, dass Tools keine Tokens in Konfigurationsdateien, Shell-Historien oder Paket-Caches kopieren.

Die Migrationsrichtung des Unternehmens bringt ein weiteres praktisches Problem mit sich. Neue Funktionen, einschließlich des schnelleren Pfads und nativer Snapshots, erfordern direkten ctx.container-Zugriff. Cloudflare erklärt, dass es die ältere Klasse Container und die Legacy-Klasse Sandbox bis zum 31. Dezember 2026 weiter pflegen wird.

Laut dem Unternehmen werden bestehende Deployments danach weiterlaufen, doch diese Klassen erhalten keine Updates mehr. Teams, die die neuen Fähigkeiten nutzen möchten, müssen ihre Lebenszykluslogik auf die direkte Durable-Object-API migrieren.

Das ist eine bedeutsame Architekturänderung, nicht nur ein Schalter, den jedes Team gefahrlos aktivieren kann. Die direkte API legt mehr vom Identitäts- und Koordinationsmodell des Systems offen. Außerdem fordert sie Entwickler auf, explizit Verantwortung für Verhalten zu übernehmen, das zuvor durch eine Basisklasse verborgen war.

Cloudflare wandelt Sandbox SDK 1.0 in eine Sammlung von Hilfsprogrammen statt in eine Oberklasse um. Das sollte Teams ermöglichen, praktische Helfer mit nativer Lebenszykluskontrolle zu kombinieren. Es bestätigt auch, dass Cloudflare das Durable Object und nicht den SDK-Wrapper als Kernabstraktion definieren möchte.

Die nächsten Tests betreffen Zuverlässigkeit, Akzeptanz und die Reaktion der Konkurrenz

Die Veröffentlichung wird erst dann folgenreich, wenn reale Agentensysteme ihre neuen Steuerungsmöglichkeiten in niedrigere Aufgabenlatenz und zuverlässige Wiederherstellung umsetzen.

Das erste zu beobachtende Signal ist die Produktionsleistung über vollständige Workloads hinweg. Die von Cloudflare gemeldete sechsfach bessere Leistung betrifft den Startpfad, Entwickler benötigen jedoch Messwerte vom Task-Dispatch bis zur Einsatzbereitschaft der Anwendung.

Sinnvolle Tests sollten kleine und große Images, mehrere Regionen, wiederhergestellte Snapshots, frische Dateisysteme und unterschiedliche Instanzgrößen abdecken. Sie sollten Scheduler-Latenz von Image-Initialisierung, Wiederherstellung von Abhängigkeiten und Dienstbereitschaft unterscheiden.

Wenn diese Messungen durchgängig kürzere Ende-zu-Ende-Verzögerungen zeigen, wird das Argument von Cloudflare stärker. Wenn die Zugewinne verschwinden, sobald Repositories und Entwicklungsserver in den Workflow eintreten, bleibt Startgeschwindigkeit ein engerer Vorteil.

Das zweite Signal ist die Zuverlässigkeit von Snapshots, nachdem die öffentliche Beta anspruchsvolle Workloads erreicht. Teams sollten Wiederherstellungsfehlerraten, Dauer der Prüfpunkte, Speicherverhalten, Verfahren für Image-Upgrades und die Wiederherstellung nach unterbrochenen Sitzungen beobachten.

Eine erfolgreiche Nutzung durch Coding-Agenten wäre besonders aufschlussreich. Cloudflare nennt bereits Base44 und Kilo Code als Nutzer isolierter Umgebungen für Agentenarbeit. Frühere Cloudflare-Materialien nannten außerdem Figma Make als Containers-Kunden für die Ausführung nicht vertrauenswürdigen Codes.

Diese Kundenreferenzen zeigen echte Anwendungsfälle, liefern jedoch keine vergleichenden Leistungsdaten. Unabhängige Engineering-Berichte hätten mehr Gewicht als Testimonials zur Einführung.

Auch das Verhalten von Snapshots bei großen Repositories wird wichtig sein. Paketverzeichnisse und Build-Ausgaben können schnell anwachsen. Teams müssen verstehen, ob Snapshots schnell und handhabbar bleiben, wenn Workspaces über wiederholte Prüfpunkte hinweg wachsen.

Wenn Cloudflare die Aufbewahrungskontrollen für Snapshots, Listing-APIs, Observability oder Tools zur versionsübergreifenden Migration ausbaut, würde dies darauf hindeuten, dass sich die Funktion in Richtung einer breiteren Produktionsnutzung entwickelt. Anhaltende Einschränkungen würden die Geschichte vom langfristigen Workspace schwächen.

Das dritte Signal ist, wie Wettbewerber auf das kombinierte Controller- und Sandbox-Modell von Cloudflare reagieren. Der Markt für Agenten-Sandboxes umfasst spezialisierte Anbieter und breitere Compute-Plattformen, jeweils mit unterschiedlichen Stärken.

E2B setzt auf speziell entwickelte Cloud-Umgebungen für Agenten. Modal verbindet abgeschottete Rechenleistung mit einer größeren serverlosen Plattform. Daytona konzentriert sich auf Entwicklungsumgebungen, während Vercel Sandbox-Funktionen in seine Anwendungsplattform integriert.

Hyperscale-Clouds bieten Teams durch virtuelle Maschinen, Container, Identitätssysteme und Orchestrierungsdienste umfassende Kontrolle. Ihr Nachteil liegt oft im Entwicklungsaufwand, der nötig ist, um diese Komponenten zu einem Agentenprodukt mit geringer Latenz zusammenzufügen.

Cloudflare setzt darauf, dass Durable Objects diesen Zusammenbau vereinfachen. Identität, Zustand, Kommunikation, Richtlinien und Lebenszyklus können neben dem Sandbox-Controller angesiedelt sein. Sein globales Netzwerk liefert Routing und vorbereitete Kapazitäten.

Eine Reaktion der Konkurrenz könnte mehrere Formen annehmen. Andere Anbieter könnten stärkere zustandsbehaftete Koordination, flexiblere Snapshots, feinere Laufzeitdimensionierung oder eine engere Vermittlung von Anmeldedaten hinzufügen. Sie könnten auch Benchmarks veröffentlichen, die Cloudflares Behauptungen zu Startzeiten infrage stellen.

Wenn Wettbewerber auf einen externen zustandsbehafteten Controller zulaufen, wird Cloudflares Architektur vorausschauend wirken – selbst wenn Kunden eine andere Plattform wählen. Wenn Entwickler einfachere gehostete Sandbox-APIs bevorzugen, könnte das Durable-Object-Modell zu stark nach Infrastruktur wirken.

Die Akzeptanz wird teilweise davon abhängen, wie viel Kontrolle Anwendungsteams wünschen. Ein Startup, das einen Coding-Agenten entwickelt, könnte direkte Programmierung des Lebenszyklus schätzen. Ein Team, das eine einzelne Code-Ausführungsfunktion ergänzt, bevorzugt womöglich einen stärker vorkonfigurierten Dienst mit weniger Entscheidungen.

Cloudflare muss beide Gruppen bedienen, ohne die Fähigkeiten zu verbergen, die die Plattform auszeichnen. Die neue SDK-Ausrichtung versucht, diesen Mittelweg zu gehen, indem sie Hilfsfunktionen rund um eine native API statt einer weiteren verpflichtenden Abstraktion bietet.

Sicherheitsvorfälle werden ein weiteres entscheidendes Kriterium sein. Agenten-Sandboxes führen nicht vertrauenswürdige oder unvorhersehbare Befehle aus, oft mit Netzwerkzugriff und in Nähe zu proprietärem Code. Eine schnelle Umgebung, die Zugangsdaten preisgibt oder mandantenübergreifenden Zugriff ermöglicht, würde ihren zentralen Zweck verfehlen.

Cloudflares Einsatz von Firecracker-MicroVMs sorgt für Kernel-Isolation zwischen Workloads. Der sichere Betrieb hängt jedoch auch von Image-Hygiene, ausgehenden Kontrollen, Autorisierung, dem Umgang mit Geheimnissen, Protokollierung und Anwendungsrichtlinien ab.

Teams sollten das Modell als mehrschichtige Abschottung behandeln, nicht als Erlaubnis, von Agenten generiertem Code zu vertrauen. Das Durable Object kann zum Durchsetzungspunkt für Richtlinien werden, doch Entwickler müssen diese Richtlinien implementieren und testen.

Die Veröffentlichung wirft zudem eine grundsätzlichere Frage zur Architektur von Agentenprodukten auf. Sollte der Agent außerhalb des Workspace leben und ihn als austauschbares Werkzeug behandeln, oder sollte der Agent innerhalb seines Computers laufen?

Cloudflare unterstützt beide Muster. Läuft der Agent im Durable Object, bleiben Kommunikation und Zustand verfügbar, während die Rechenleistung ruht. Läuft er im Container, bietet dies ein vertrautes Linux-Prozessmodell, während das Objekt ihn von außen überwacht.

Das erste Muster macht die Grenze zwischen Gehirn und Händen ausdrücklich sichtbar. Das zweite könnte bestehende Agenten-Laufzeiten vereinfachen, die lokale Dateien und Prozesse erwarten. Die tatsächliche Akzeptanz wird zeigen, welches Modell Entwickler leichter betreiben können.

Cloudflare Containers, neu aufgebaut für die Skalierung von Agenten-Sandboxes, steht für mehr als eine Verbesserung bei Kaltstarts. Es macht die Wahl der Laufzeit, Dateisystemkontinuität und Lebenszyklusrichtlinien zu Entscheidungen auf Anwendungsebene, die durch dauerhaften Zustand gesteuert werden.

Dieser Wandel setzt statische Deployments und vereinfachte Sandbox-APIs unter Druck. Er gibt Entwicklern jedoch auch mehr Möglichkeiten, subtile Fehler zu erzeugen. Laufzeitflexibilität erfordert strikte Richtlinien, dauerhafte Aufgabenaufzeichnungen und Benchmarks, die sinnvolle Bereitschaft statt eines leeren Prozesses messen.

Teams, die die Veröffentlichung bewerten, sollten mit einer realen Arbeitslast beginnen. Messen Sie frischen Start, wiederhergestellten Start, Abhängigkeitsbereitschaft, Fehlerbehebung und den vollständigen Abschluss der Aufgabe. Testen Sie anschließend, ob der Controller verlorene Container übersteht, ohne externe Aktionen zu wiederholen.

Die nächsten Monate sollten zeigen, ob Cloudflares Snapshots der öffentlichen Beta zuverlässig bleiben, ob Kunden unabhängige Latenzergebnisse veröffentlichen und ob Wettbewerber ähnliche zustandsbehaftete Kontrollen übernehmen. Diese Signale werden bestimmen, ob diese Architektur zu einer verbreiteten Grundlage für langlaufende Agenten wird oder zu einer weiteren spezialisierten Option in einem zunehmend überfüllten Markt.