Mehr als 60 Prozent aller Pull Requests, die intern bei Cursor zusammenlaufen, werden nach eigenen Angaben inzwischen von Cloud Agents erzeugt. Die Zahl markiert eine Schwelle: KI-gestützte Coding-Agenten sind kein Randthema mehr für experimentierfreudige Teams, sondern übernehmen einen wachsenden Anteil der tatsächlichen Softwarearbeit. Genau dort, wo Agenten produktiv werden, entscheidet sich zunehmend, auf welcher Infrastruktur sie laufen dürfen – und genau hier setzt die neue Funktion Self-Hosted Machines an.
Was Self-Hosted Machines konkret löst
Bisher liefen Cloud Agents in einer eigenen VM in der Cursor-Cloud. Die Sitzung bekam ihre Abhängigkeiten, ihre Netzwerkregeln, ihre Isolierung – alles bereitgestellt vom Anbieter. Für viele Teams reicht das, für manche nicht. Sobald ein Agent Zugriff auf interne Repositories braucht, mit Diensten im eigenen Netz sprechen muss oder auf spezieller Hardware laufen soll – etwa einer GPU oder einem Mac für iOS-Builds – stößt die gehostete Umgebung an Grenzen. Self-Hosted Machines verschiebt deshalb nur die Ausführungsumgebung, nicht aber die Intelligenz des Agenten. Inferenz, Planung und der eigentliche Agent-Loop bleiben in der Cursor-Cloud. Was sich ändert, ist der Ort, an dem Werkzeugaufrufe tatsächlich ausgeführt werden.
Wer schon einmal versucht hat, einen Build-Server sauber in einen Container zu verpacken, kennt das Problem: Manche Pipelines sind schlicht zu eigen, zu betriebskritisch oder zu nahe an anderer Infrastruktur, um sie ohne Reibungsverluste auszulagern. Genau für diese Fälle ist die neue Option gedacht. Der Agent arbeitet im eigenen Netz, neben internen Diensten und Source Control, während die Steuerung weiterhin zentral über Cursor läuft.
Die Architektur: Worker verbinden Infrastruktur mit dem Agent-Loop
Das Prinzip ist bewusst einfach gehalten. Auf einer Maschine im eigenen Netz wird die Cursor-CLI installiert und ein Worker-Prozess gestartet. Dieser öffnet eine ausgehende HTTPS-Verbindung zur Cursor-Cloud – nicht umgekehrt. Cursor initiiert also nie eine Verbindung in das interne Netz, ein wichtiger Punkt für Teams mit restriktiven Firewall-Regeln. Wenn eine Agent-Sitzung startet, übernimmt der Cursor-Harness im Backend Inferenz und Planung. Die eigentlichen Werkzeugaufrufe – Dateien editieren, Tests laufen lassen, Repositories klonen – gehen an den Worker, der die Ergebnisse zurückmeldet. Im nächsten Schritt plant der Agent weiter, der Loop wiederholt sich.
Das Bild passt: Das Gehirn sitzt in der Cloud, die Hände greifen in die lokale Werkstatt. Diese Trennung hat zwei praktische Vorteile. Erstens muss das Team keine eigene Inferenz-Hardware aufbauen. Zweitens behalten die Beteiligten die volle Kontrolle über alles, was im eigenen Netz passiert. Geheimnisse bleiben im eigenen Netz, Builds können auf vorhandene Pipelines zugreifen, und Code verlässt die Infrastruktur nur, soweit er für die Verarbeitung durch das Modell notwendig ist.
Zwei Konfigurationen: My Machines und Pools
Wer eine einzelne Maschine anbinden will – etwa das eigene Laptop oder eine feste VM – nutzt die Konfiguration My Machines. Sie eignet sich für persönliche Workflows, in denen ein Entwickler seinem Agenten Zugriff auf die lokale Umgebung geben möchte. Sobald ein ganzes Team oder eine ganze Organisation arbeitet, kommen Pools ins Spiel. Ein Pool ist eine benannte Warteschlange von Workern, die Anfragen aus beliebigen Repositories bedienen können. Die Kapazität skaliert mit der Last: Steigen die Anfragen, startet der Controller neue Maschinen über ein vom Team bereitgestelltes Spawn-Skript. Sinkt die Last, werden Verbindungen nach einem konfigurierbaren Idle-Timeout geschlossen.
Diese Dynamik ist im Alltag oft der entscheidende Vorteil. Coding-Aufgaben kommen in Stoßzeiten, etwa morgens, wenn das Team Commits verarbeitet, oder nach Feierabend, wenn automatisierte Reviews laufen. Wer seine Infrastruktur manuell dimensioniert, zahlt entweder zu viel für ungenutzte Maschinen oder wartet zu lange, wenn plötzlich Last entsteht. Pools reagieren auf beides, ohne dass jemand morgens um drei entscheiden muss, wie viele Build-Server gerade sinnvoll sind.
Hibernation und Arbeitsspeicher: Kosten im Griff
Eine leere Maschine laufen zu lassen ist teuer. Sie freizugeben und später neu zu starten, kostet Minuten, in denen der Agent seinen Arbeitsstand rekonstruieren muss. Self-Hosted Machines führt deshalb einen Hibernate-Modus ein: Nach einem Idle-Timeout wird ein Snapshot der Maschine erstellt und angehalten. Kommt innerhalb des Reconnect-Fensters eine Folgeanfrage, wird der Snapshot wiederhergestellt und der Worker startet mit derselben ID – der Agent nimmt das Geschäft dort wieder auf, wo er aufgehört hat. Ist das Fenster abgelaufen, wandert die Anfrage an eine andere Maschine. Praktisch bedeutet das: Bezahlt wird nur für tatsächlich genutzte Kapazität, ohne den Komfort eines erhaltenen Arbeitszustands aufzugeben.
Im Hintergrund läuft ein Controller, der die Anfrage-Warteschlange beobachtet und entscheidet, wann Kapazität gebraucht wird. Die Teams liefern das Spawn-Skript, die Plattform steuert den Lebenszyklus. Diese Arbeitsteilung wirkt unspektakulär, ist aber genau das, was professionelle Infrastrukturteams brauchen: klare Verantwortlichkeiten, sauberes Skalieren, kein Wildwuchs.
Sandbox-Provider als Multiplikator
Self-Hosted Machines verlangt nicht, dass jedes Unternehmen eine eigene Sandbox-Schicht baut. Cursor arbeitet mit mehreren Anbietern zusammen, darunter AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace und Vercel. Jeder dieser Partner stellt eigene Sandbox-Umgebungen bereit, in denen Cursor-Agenten starten können. Wer Lambda nutzt, bekommt MicroVMs, die in Sekundenbruchteilen aus einem Snapshot starten und im Leerlauf pausieren. Wer Vercel Sandbox einsetzt, erhält on-demand isolierte Umgebungen ohne eigene Flottenverwaltung. Wer Modal verwendet, bekommt für jede Sitzung einen eigenen Sandbox-Container.
Für ein Team bedeutet das: Die Agenten nutzen genau die Plattform, in der die übrige Infrastruktur ohnehin läuft. Es entsteht kein paralleler Tech-Stack, keine zweite Fuhrungsstruktur, kein zusätzlicher Wildwuchs an Werkzeugen. Lambda-MicroVMs liefern schnelle Startzeiten und starke Isolierung ohne eigene Flottenverwaltung. Modale Sandbox-Container erlauben feinere Konfiguration pro Aufgabe, Vercel gliedert sich in bestehende Frontend-Workflows ein. Die Wahl des Providers ist am Ende eine Frage der bestehenden Infrastruktur und der jeweiligen Sicherheitsanforderungen.
Browser-Steuerung auf Linux und Mac
Eine kleinere, aber für bestimmte Workflows wichtige Erweiterung betrifft die sogenannte Computer-Use-Fähigkeit. Linux-Worker unterstützen sie jetzt ebenso wie Macs. Vorausgesetzt, die nötigen Abhängigkeiten – etwa Chrome oder Chromium – sind installiert, kann der Agent einen Browser öffnen, klicken, Screenshots anfertigen und Webseiten wie ein Mensch bedienen. Teams können den Desktop des Agenten live mitverfolgen oder selbst die Kontrolle übernehmen. Für Aufgaben, die über klassische API-Aufrufe hinausgehen – etwa das Klicken durch eine Legacy-Weboberfläche oder das Testen einer Webanwendung im Browser – ist das ein erheblicher Gewinn an praktischer Nützlichkeit.
Die Mac-Variante bleibt für Apple-spezifische Entwicklung unersetzlich. iOS- und macOS-Builds lassen sich nicht ohne echte Apple-Hardware erstellen; Namespace stellt dafür Mac-Maschinen auf Apple Silicon bereit, auf denen Cursor-Agenten genau diese Aufgaben übernehmen können.
Was das für den Alltag bedeutet
Wer in einem Unternehmen mit klaren Sicherheits- und Compliance-Regeln arbeitet, hatte bisher oft nur zwei Optionen: Entweder Cloud Agents komplett aussperren oder den Aufwand einer eigenen Agenten-Plattform tragen. Self-Hosted Machines schiebt sich genau in diese Lücke. Die Agenten bleiben verwaltbar, die Auswahl der unterstützten Sandbox-Provider bleibt flexibel, und die bestehende Infrastruktur im eigenen Netzwerk wird zum Standard-Arbeitsplatz für KI-gestützte Softwareentwicklung.
KI-Coding-Agenten werden nicht in einem Vakuum eingesetzt, sondern in Umgebungen mit gewachsener Tooling-Landschaft, mit eigenen CI-Pipelines, mit spezifischen Hardware-Anforderungen. Anbieter, die diese Realität akzeptieren und ihre Agenten in bestehende Strukturen einbetten, werden in Unternehmen eher Gehör finden als jene, die auf eine eigene, geschlossene Cloud setzen. Für Teams, die schon mit Lambda, Cloudflare oder Modal arbeiten, ist der Einstieg in Self-Hosted Machines vor allem eine Konfigurationsfrage. Für alle anderen ist es eine Gelegenheit, das eigene Infrastrukturkonzept zu schärfen – und dabei zu entscheiden, welche Aufgaben ein Agent übernehmen darf und auf welcher Maschine er das tun soll.
Quelle: cursor.com
