Daytona-Sandboxes jetzt als Komponente im Convex-Verzeichnis verfügbar

Die Lücke zwischen Agentenzustand und Codeausführung schließen

Laut Daytona profitieren auf Convex aufgebaute Agenten bereits von dauerhaften Konversationen und reaktivem Zustand: Jeder geöffnete Browser-Tab zeigt ohne eigenen Synchronisationscode denselben Stand. Die Lücke entsteht, wenn ein Agent etwas ausführen muss, etwa soeben geschriebenen Code, Operationen auf einem Dateisystem oder einen Dev-Server. Dann muss er die Convex-Welt verlassen und rohe Infrastruktur ansprechen.

Die neue Komponente @daytona/convex soll diesen Schritt überflüssig machen. Sie ist im Convex-Komponentenverzeichnis gelistet und wird laut Daytona wie jede andere Komponente in ein Backend eingebunden.

So funktioniert das Zusammenspiel

Daytona beschreibt die Kernidee von Convex so: Zustand ist eine einzige, konsistente und abonnierbare Größe, wobei die Datenbank als Synchronisations-Engine dient. Daytonas eigener Ansatz lautet, dass Agentencode auf echten, isolierten und wegwerfbaren Maschinen laufen soll. Die Komponente verbindet beides: Jede Sandbox und jede Befehlsausführung wird zu einer Zeile in reaktiven Convex-Tabellen.

Daytona nennt dafür praktische Folgen:

• Der Status eines Befehls wechselt in der Oberfläche von „läuft“ auf „abgeschlossen“, sobald er beendet ist, ganz ohne Polling und ohne Websocket-Aufwand.
• Nutzer können die Seite mitten im Job neu laden und sehen den Fortschritt dort, wo er stand, weil er nie an der Verbindung hing.
• Ein zweiter Tab, der Browser eines Teammitglieds und ein Admin-Dashboard sehen alle denselben Ausführungsverlauf.

In Daytonas Darstellung ist die Ausführung damit kein Nebeneffekt mehr, dem die Oberfläche hinterherläuft, sondern ein Zustand, den sie einfach liest.

Was die Komponente umfasst

Von Daytona bringt die Komponente Sandboxes mit, die aus Snapshots oder beliebigen Docker-Images starten, dazu Shell- und Codeausführung, Dateisystemoperationen, signierte Vorschau-URLs für alles, was einen Port bedient, sowie Lebenszyklus-Steuerung wie Auto-Stop und Auto-Delete, damit Experimente hinter sich aufräumen.

Von Convex nutzt sie Live-Abfragen, dauerhafte Ausführungsprotokolle, Konsistenz über mehrere Clients und den Scheduler. Der Scheduler treibt runBackground an, Daytonas Ansatz für lang laufende Aufgaben. Entwickler starten einen Befehl und erhalten sofort eine Ausführungs-ID zurück, anschließend fließen Logs in die Zeile, während eine Kette schlanker, geplanter Funktionen den Job überwacht. Laut Daytona bleibt dabei keine Action offen, und es gibt keine Obergrenze von 10 Minuten.

Einrichtung und Beispiel-App

Die Installation besteht aus einem npm-Install von @daytona/convex, dem Setzen der Umgebungsvariable DAYTONA_API_KEY über die Convex-CLI und der Registrierung der Komponente in convex/convex.config.ts. Daytonas Beispiel zeigt ein Code-Interpreter-Tool in wenigen Zeilen: Eine Action erstellt eine Sandbox mit einem autoStopInterval von 15 und ruft dann runCode mit Python auf. Wer im Frontend daytona.listExecutions abonniert, sieht den Ausführungsverlauf laut Unternehmen live.

Um zu testen, wie weit das Muster trägt, hat Daytona darauf einen KI-App-Builder gebaut. Nutzer beschreiben eine App in einem Prompt, der Code des LLM wird als reaktiver Zustand in die Seite gestreamt, und die fertige App läuft in einem Iframe über eine Daytona-Vorschau-URL. Das Ergebnis übersteht laut Daytona ein Neuladen, funktioniert über mehrere Tabs hinweg und kommt insgesamt auf rund 200 Zeilen.

Was das für Entwickler bedeutet

Für Teams, die bereits Convex nutzen, bietet die Komponente die Möglichkeit, Code in Sandboxes auszuführen, ohne eine separate Infrastruktur oder eine eigene Schicht zur Statusverfolgung von Jobs aufzubauen. Daytona verweist Entwickler auf das Convex-Komponentenverzeichnis, npm und das Quell-Repository sowie auf eine Anleitung samt Beispiel-App mit dem Titel „Build an AI App Builder with Convex and Daytona“. Nötig sind API-Schlüssel aus dem Daytona-Dashboard und von Convex.