
Cursor Cloud Agents laufen jetzt in Vercel Sandbox als isolierte Firecracker-VMs
Die Integration verbindet zwei klar getrennte Verantwortungsbereiche: Cursor übernimmt weiterhin den Agent-Harness und den Inference-Loop, während Vercel Sandbox die eigentliche Ausführungsumgebung bereitstellt. Möglich wird das durch Cursors Self-Hosted-Machines-API, über die Unternehmen eine eigene Execution-Umgebung einbinden können – ein Feature, das einen Cursor-Enterprise-Plan voraussetzt. Jeder eingehende Agent-Request erhält dabei eine dedizierte Firecracker-MicroVM, die nach Abschluss automatisch bereinigt wird. Die Steuerungslogik übernehmen Vercel Functions und Vercel Workflow gemeinsam: Sie bilden eine dauerhafte Control Plane, die Requests aus einer Queue zieht, Worker provisioniert, Sessions überwacht und aufräumt. Innerhalb jeder Sandbox laufen die typischen Agent-Aufgaben ab – Repository klonen, Dateien editieren, Befehle und Tests ausführen. Vercel stellt eine Referenzimplementierung bereit, die Nutzer per Schritt-für-Schritt-Anleitung direkt in ihr eigenes Vercel-Konto deployen können. Das Modell vermeidet dauerhaft laufende VMs vollständig, da der Worker-Pool auf null skaliert, wenn keine Requests anliegen.
- Cursor Self-Hosted Machines API ist die Schnittstelle, über die externe Execution-Umgebungen angebunden werden – setzt Cursor Enterprise voraus.
- Vercel Functions und Vercel Workflow bilden gemeinsam die durable Control Plane: Queue-Claiming, Worker-Provisioning, Session-Monitoring und automatisches Cleanup.
- Innerhalb der Sandbox können Agents Repositories klonen, Dateien bearbeiten sowie Befehle und Tests ausführen.
- Jede Sandbox erhält kurzlebige, nutzer-scoped Credentials – keine dauerhaft gültigen Zugangsdaten in der Ausführungsumgebung.
- Vercel stellt eine Referenzimplementierung mit Schritt-für-Schritt-Anleitung zum Self-Deploy in eigene Vercel-Accounts bereit.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge

Cursor Cloud Agents laufen jetzt in Vercel Sandbox als isolierte Firecracker-VMs
Die Integration verbindet zwei klar getrennte Verantwortungsbereiche: Cursor übernimmt weiterhin den Agent-Harness und den Inference-Loop, während Vercel Sandbox die eigentliche Ausführungsumgebung bereitstellt. Möglich wird das durch Cursors Self-Hosted-Machines-API, über die Unternehmen eine eigene Execution-Umgebung einbinden können – ein Feature, das einen Cursor-Enterprise-Plan voraussetzt. Jeder eingehende Agent-Request erhält dabei eine dedizierte Firecracker-MicroVM, die nach Abschluss automatisch bereinigt wird. Die Steuerungslogik übernehmen Vercel Functions und Vercel Workflow gemeinsam: Sie bilden eine dauerhafte Control Plane, die Requests aus einer Queue zieht, Worker provisioniert, Sessions überwacht und aufräumt. Innerhalb jeder Sandbox laufen die typischen Agent-Aufgaben ab – Repository klonen, Dateien editieren, Befehle und Tests ausführen. Vercel stellt eine Referenzimplementierung bereit, die Nutzer per Schritt-für-Schritt-Anleitung direkt in ihr eigenes Vercel-Konto deployen können. Das Modell vermeidet dauerhaft laufende VMs vollständig, da der Worker-Pool auf null skaliert, wenn keine Requests anliegen.
- Cursor Self-Hosted Machines API ist die Schnittstelle, über die externe Execution-Umgebungen angebunden werden – setzt Cursor Enterprise voraus.
- Vercel Functions und Vercel Workflow bilden gemeinsam die durable Control Plane: Queue-Claiming, Worker-Provisioning, Session-Monitoring und automatisches Cleanup.
- Innerhalb der Sandbox können Agents Repositories klonen, Dateien bearbeiten sowie Befehle und Tests ausführen.
- Jede Sandbox erhält kurzlebige, nutzer-scoped Credentials – keine dauerhaft gültigen Zugangsdaten in der Ausführungsumgebung.
- Vercel stellt eine Referenzimplementierung mit Schritt-für-Schritt-Anleitung zum Self-Deploy in eigene Vercel-Accounts bereit.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.