Cloudflare baut Containers für Agenten-Sandboxes um und startet sie sechsmal schneller

Gebaut für Sandboxes, die bei Bedarf entstehen

Cloudflare zufolge stellen Agenten Sandboxes nicht im Voraus bereit. Sie erzeugen sie für jede Aufgabe, erwarten sofortige Verfügbarkeit und müssen sie pausieren und wieder aufnehmen können. Bisher war Cloudflare Containers um Anwendungs-Deployments herum organisiert: Image und Rechenressourcen werden beim Deployment festgelegt und über die gesamte Anwendung ausgerollt.

Ein Agenten-Arbeitsbereich funktioniert nach Ansicht des Unternehmens anders. Die Aufgabe bestimmt Image, Ressourcen, Werkzeuge und das Start-Dateisystem, und der Arbeitsbereich existiert womöglich nur wenige Minuten, ruht zwischen Anfragen oder wird erst Tage später wiederhergestellt. Als Beispiele für dieses Muster nennt Cloudflare Base44 (Arbeitsbereiche zum Bau von Apps) und Kilo Code (Cloud-Agenten-Sitzungen) und erwähnt Integrationen mit Cursor Cloud Agents, Devin Outposts, der OpenAI Agents API und Claude Managed Agents.

Verschiedene Workloads stellen unterschiedliche Anforderungen an einen Arbeitsbereich. Coding-Agenten brauchen Repositories, Paketmanager, Compiler, Test-Runner und Entwicklungsserver. Evals benötigen Sandboxes, die von einem bekannten Zustand aus starten. Reinforcement-Learning-Systeme müssen große Mengen an Umgebungen erzeugen, bewerten und zurücksetzen. Längere Aufgaben müssen die von einem Agenten erzeugten Dateien behalten, damit die Arbeit später fortgesetzt werden kann.

Image und Instanztyp per Code gewählt

Jeder Cloudflare Container war schon immer an ein eigenes Durable Object gekoppelt, das der Umgebung eine stabile Identität gibt und es dem Anwendungscode erlaubt, Start, Ruhezustand und Stopp zu steuern. Bisher standen jedoch Image und Rechenleistung beim Deployment fest. Jede Kombination aus Image und Instanztyp war eine eigene Containers-Anwendung mit eigenem Durable-Object-Namespace, eingerichtet per wrangler deploy.

Nach dem alten Ansatz bedeuteten ein Agent mit kleiner Node.js-Sandbox und ein anderer mit großer Python-Sandbox für Builds zwei Anwendungen, zwei Namespaces und Routing-Logik in einem Worker. Die neue Scheduling-Policy durable_object ändert das. Entwickler deklarieren die Images, aus denen ein Durable Object wählen kann, jeweils verfügbar als this.ctx.container.images.<name>, und übergeben Image und Instanztyp als Argumente beim Start der Sandbox. Laut Cloudflare wird eine neue Umgebung dadurch zu einer Codeänderung statt zu einem neuen Deployment.

Auch Rollouts wandern in den Code. Mit dieser Policy gibt es keine Rollout-Konfiguration: Ein Container läuft mit dem Image weiter, mit dem er gestartet wurde, bis der Code ihn stoppt, und der nächste Start nutzt das Image, das der Code auswählt. Cloudflare nennt mehrere Strategien, die dadurch möglich werden:

• Ein neues Toolset auf 5 Prozent der neuen Sandboxes als Canary ausrollen, indem die Durable-Object-ID gehasht wird.
• Aktive Projekte auf ihr aktuelles Image festlegen, damit die Umgebung eines Agenten nie mitten in einer Aufgabe ausgetauscht wird.
• Einen Arbeitsbereich an einem natürlichen Kontrollpunkt migrieren, etwa bei der nächsten Sitzung oder nach einem Snapshot.
• Per Rollback ändern, welches Image künftige Starts wählen, ohne Konfigurations-Push und ohne auf das Leerlaufen warten zu müssen.

Ein kürzerer Weg zum ersten Befehl

Bisher musste der Start eines Containers über die globale Control Plane von Cloudflare laufen, um die Anwendungskonfiguration aufzulösen, Kapazität zu finden und die Platzierung abzustimmen. Damit stand laut Cloudflare Deployment-Mechanik im Weg des ersten Befehls eines Agenten.

Mit der neuen Policy beginnt die Nachfrage beim Durable Object. Die Infrastruktur sucht zuerst auf demselben Rechner nach Kapazität und weitet die Suche dann innerhalb desselben Standorts aus. Bevorzugt werden außerdem Hosts, die das Image oder den Snapshot des Containers bereits im lokalen Speicher haben, sodass zuvor nichts heruntergeladen werden muss.

Auch der Aufwand nach der Ankunft des Containers auf einem Host wurde reduziert. Statt eine neue virtuelle Maschine von Grund auf zu booten, stellt die Laufzeitumgebung eine vorbereitete, noch nicht zugewiesene virtuelle Maschine wieder her. Sie nutzt Netzwerk- und Dateisystem-Setup erneut, bündelt wiederholte Operationen und wartet nicht mehr auf Dienste, die der erste Befehl nicht braucht.

Im unabhängigen Benchmark von ComputeSDK sank die mediane Startzeit laut Cloudflare von knapp über vier Sekunden auf 648 Millisekunden. Außerdem hätten eigene, vorläufige Lasttests mit plötzlichen Lastspitzen erfolgreich Hunderttausende Container innerhalb von Sekunden erzeugt, so das Unternehmen.

Was das für Entwickler bedeutet

Cloudflare bringt außerdem weitere Funktionen in die native ctx.container-API, sodass ein Durable Object seinen Container ohne Wrapper-Klasse steuern kann, und übernimmt dieses Modell in das Sandbox SDK 1.0. Das Unternehmen positioniert Containers als Ergänzung zu Workers, Dynamic Workers und Durable Objects, wenn Agenten einen vollständigen Linux-Arbeitsbereich benötigen.

Für Teams, die Agentenprodukte bauen, besteht die praktische Änderung darin, dass Umgebungswahl, Dimensionierung und Rollout-Regeln nun in demselben Code liegen, der jede Aufgabe abwickelt, während Snapshots in der Public Beta es erlauben, Arbeitsbereiche zu speichern und wiederherzustellen. Die von Cloudflare zitierten Kunden Base44 und Kilo Code sagen, sie nutzten Containers, um jeder App oder Agenten-Sitzung bei Bedarf eine isolierte Umgebung zu geben.