> ## Documentation Index > Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt > Use this file to discover all available pages before exploring further. # Outposts > Devin-Sitzungen auf Ihrer eigenen Infrastruktur ausführen Outposts ist im Early Access. Die hier beschriebenen APIs und CLI-Befehle können sich ändern. Wenden Sie sich an Ihr Account-Team, um Outposts für Ihre Organisation zu aktivieren. Mit Outposts können Sie Devin-Sitzungen auf Infrastruktur ausführen, die Sie selbst kontrollieren — auf Ihren eigenen VMs, Containern, Kubernetes-Clustern oder sogar auf einem Mac Mini unter Ihrem Schreibtisch. Devins Agent-Loop (Inferenz und Planung) läuft weiterhin in Devins Cloud, während die gesamte Befehlsausführung, Dateibearbeitung und der Zugriff auf Repositories auf Maschinen erfolgen, die Sie selbst betreiben. Verwenden Sie Outposts, wenn Sie Folgendes benötigen: * Sitzungen, die innerhalb Ihres Netzwerks in der Nähe interner Services, Registries und Secrets laufen * Benutzerdefinierte Hardwareprofile (z. B. GPUs, Maschinen mit großem Arbeitsspeicher, spezifische OS-Images) * Bestehende Dev-Box-, VM- oder Kubernetes-Infrastruktur zum Hosten von Devin-Workloads * Enterprise-Steuerung für Netzwerkzugriff, Build-Ergebnisse und Monitoring
## Wie es funktioniert
Outposts hat zwei Schichten: 1. **Der Worker (z. B. `devin worker start`)** — eine Binärdatei, die Sie auf einer Maschine ausführen, um eine einzelne in der Warteschlange befindliche Sitzung zu bedienen. Sie baut eine ausgehende Verbindung zu Devins Cloud auf und führt die Tool-Aufrufe der Sitzung lokal aus. Cognition stellt diese Binärdatei bereit; Sie müssen sie nie selbst entwickeln. Die [Devin CLI](/de/work-with-devin/devin-cli) enthält die Logik zum Abrufen und Ausführen dieser Binärdatei. 2. **Der Orchestrator** — Software, die die Fleet-API auf Sitzungen überwacht, die auf Worker warten, für jede davon eine VM oder einen Container bereitstellt und darin den Worker startet. Wir stellen einige Referenzimplementierungen für gängige Plattformen (wie Kubernetes) bereit, aber Sie können diese gerne anpassen (sie sind Open Source!) oder Ihre eigene schreiben. Worker benötigen nur **ausgehenden** HTTPS-Zugriff. Es sind keine eingehenden Ports, öffentlichen IP-Adressen oder VPN-Tunnel erforderlich. Wenn ein Nutzer in Devin Cloud eine Sitzung startet und einen Ihrer registrierten Outposts auswählt, wird die Sitzung in die Warteschlange dieses Outposts eingereiht. Ihr Orchestrator beansprucht sie, startet eine Maschine und führt den Worker aus. Wenn die Sitzung endet, beendet sich der Worker und Ihr Orchestrator fährt die Maschine wieder herunter.
## Voraussetzungen
* Eine Organisation, für die Outposts aktiviert ist * Ein [v3-API-Token](/de/api-reference/v3/overview) mit den entsprechenden Outposts-Scopes: * `account.outposts.orchestrator` für Orchestratoren, die Outposts verwalten (schließt den Maschinen-Scope ein) * `account.outposts.machine` für Worker, die die Warteschlange lesen und Sitzungen beanspruchen/freigeben * Ein Maschinenabbild (VM oder Container) mit: * installiertem Devin CLI * den unten aufgeführten [Maschinenabhängigkeiten](#machine-dependencies) * Ihren geklonten Repositorys mit konfigurierten Remotes * Zugriff auf die Build-Tools, Paket-Registries, Secrets und internen Dienste, die Ihre Sitzungen benötigen
### Abhängigkeiten der Maschine
Sitzungen werden direkt auf Ihrer Maschine ausgeführt, daher ist der Worker auf Tools angewiesen, die Sie dort installieren. **Erforderlich** | Abhängigkeit | Verwendet für | | ----------------- | ----------------------------------- | | `git` (in `PATH`) | Klonen und alle Repository-Vorgänge | **Optional** — installieren Sie diese, um bestimmte Funktionen freizuschalten: | Abhängigkeit | Funktion | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ffmpeg` (in `PATH`) | Devins Funktionen zur Bildschirmaufzeichnung. Ohne diese können Sitzungen den Bildschirm nicht aufzeichnen. | | Chrome oder Chromium | Browser- und Computer-Use-Funktionen. Der Worker sucht standardmäßig an den üblichen Installationsorten nach Chrome; setzen Sie `DEVIN_CHROME_PATH` in der Umgebung des Workers auf den absoluten Pfad der Binärdatei, um dies zu überschreiben (z. B. `DEVIN_CHROME_PATH=/usr/bin/google-chrome`). Ohne diese sind Browser-Tools nicht verfügbar. | | Passwortloses `sudo` | Ermöglicht Devin, während einer Sitzung benötigte Software zu installieren (z. B. fehlende Build-Tools oder Systempakete). Gewähren Sie dies nur, wenn die Maschine ausschließlich für Devin vorgesehen ist und nach jeder Sitzung neu bereitgestellt wird — niemals auf gemeinsam genutzten oder langlebigen Maschinen. |
## Schnellstart: einen Outpost erstellen und einen Worker starten
In dieser Anleitung wird ein Outpost erstellt und auf einer einzelnen Maschine mit `devin worker start` betrieben — kein Orchestrator erforderlich. Das ist der schnellste Weg, Outposts auf einer Entwicklungsmaschine auszuprobieren, und genau denselben Worker-Befehl führt ein Orchestrator auch im großen Maßstab aus.
### 1. Service-User-Token erstellen
Der Worker (und jeder Orchestrator) authentifiziert sich bei der Outposts API mit einem [v3-API-Token](/de/api-reference/v3/overview), das zu einem **Service-Benutzer** gehört; die Rollenberechtigungen unten verleihen dem Token seine Outposts-Scopes (`UseOutpostsMachine` → `account.outposts.machine`, `ManageOutpostsOrchestrator` → `account.outposts.orchestrator`). In der Devin Web-App: 1. **Eine Rolle mit Outposts-Zugriff erstellen.** Fügen Sie unter **Settings → Rollen** eine Enterprise-Rolle hinzu und aktivieren Sie unter *Outpost-Berechtigungen* **Use outpost machine** (`UseOutpostsMachine`). Aktivieren Sie außerdem **Manage outposts** (`ManageOutpostsOrchestrator`), wenn dieser Service-Benutzer Outposts erstellen oder löschen soll. 2. **Den Service-Benutzer bereitstellen.** Klicken Sie unter **Settings → Devin API → Service users** auf **Provision service user**, geben Sie einen Namen ein (z. B. `outposts-worker`), weisen Sie die Rolle aus Schritt 1 zu und legen Sie ein Ablaufdatum fest. 3. **Das Token kopieren.** Das `cog_...`-Token wird bei der Erstellung **nur einmal** angezeigt — kopieren Sie es jetzt; es kann später nicht mehr abgerufen werden. Exportieren Sie es für die folgenden Befehle: ```bash theme={null} export DEVIN_OUTPOSTS_TOKEN="cog_..." ```
### 2. Einen Outpost erstellen
Ein Outpost ist eine benannte Warteschlange für Sitzungen, die von Ihrer Infrastruktur verarbeitet werden. Sie können ihn auf jeder Maschine erstellen, auf der die [Devin CLI](/de/cli) installiert ist: ```bash theme={null} devin worker outpost create my-outpost --platform linux --description "Dev boxes in our VPC" ``` Der Befehl gibt die ID des neuen Outposts (`outpost_env-...`) aus — merken Sie sie sich für den nächsten Schritt. Sie können Outposts auch in der Web-App unter **Settings → Outposts** oder über die [Outposts-API](#outposts-outposts) erstellen. Nach der Erstellung erscheint der Outpost in Devin Cloud beim Starten einer Sitzung als Maschinenoption (neben Ubuntu, Windows usw.).
### 3. Worker starten
Installieren Sie auf der Maschine, die Sitzungen ausführen wird, die [Devin CLI](/de/cli) und die [Maschinenabhängigkeiten](#machine-dependencies), und starten Sie dann den Worker aus dem Verzeichnis, das Ihre ausgecheckten Repositorys enthält: ```bash theme={null} cd /path/to/repos devin worker start --outpost= ``` Der Worker pollt die Warteschlange des Outposts, beansprucht die erste ausstehende Sitzung, lädt die richtige `devin-remote`-Binärdatei herunter und verarbeitet die Sitzung. Wenn die Sitzung endet, kehrt er zur Warteschlange zurück und wartet auf die nächste. Übergeben Sie stattdessen `--once`, um nach einer einzelnen Sitzung zu beenden, oder `--session=`, um eine bestimmte Sitzung zu beanspruchen und zu verarbeiten. Wenn weder `--token` noch `DEVIN_OUTPOSTS_TOKEN` gesetzt ist, gibt der Befehl einen Fehler aus. Wenn `--outpost` in einem interaktiven Terminal weggelassen wird, fordert der Worker Sie auf, einen Outpost aus Ihrem Konto auszuwählen.
### 4. Starten Sie eine Sitzung auf dem Outpost
Starten Sie in Devin Cloud eine neue Sitzung und wählen Sie Ihren Outpost als Maschine aus. Die Sitzung wird in die Warteschlange eingereiht, Ihr Worker beansprucht sie, und die Ausführung beginnt auf Ihrer Maschine. Um mehr Sitzungen parallel zu verarbeiten, führen Sie den Worker auf weiteren Maschinen aus, die auf denselben Outpost zeigen — siehe [Planung ohne zentrale Koordination](#centralization-free-scheduling). Nutzen Sie Kubernetes? Der Open-Source- [devin-outpost-k8s](https://github.com/CognitionAI/devin-outpost-k8s) Operator wird über Helm installiert und führt Worker für einen Outpost auf jedem zertifizierten Cluster (GKE, EKS, ...) aus. Aus einem Klon dieses Repos heraus: ```bash theme={null} helm install outposts charts/devin-outposts-k8s \ --set defaultPool.enabled=true \ --set defaultPool.poolId= \ --set defaultPool.token.value="$DEVIN_OUTPOSTS_TOKEN" ```
## Der grundlegende Ablauf
### 1. Einen Outpost registrieren
Ein Outpost ist eine benannte Warteschlange von Sitzungen, die von vielen Workern auf Ihrer Infrastruktur bedient wird (zum Beispiel `rhel`, `gpu-h200` oder `my-outpost`). Erstellen Sie einen mit `devin worker outpost create`: ```bash theme={null} devin worker outpost create --platform --description "..." ``` Nach der Registrierung erscheint der Outpost in Devin Cloud beim Starten einer Sitzung als Maschinenoption (neben Ubuntu, Windows usw.). Sitzungen, die auf diesen Outpost abzielen, warten in seiner Warteschlange, bis ein Worker sie beansprucht. In der Fleet-API werden Outposts als `outposts`-Ressourcen dargestellt, die auf Ihr Konto beschränkt sind (und von allen zugehörigen Organisationen gemeinsam genutzt werden).
### 2. Die Fleet-API auf wartende Sitzungen pollen
Ihr Orchestrator listet die ausstehenden Sitzungen für die von ihm betreuten Outposts auf: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&phase=pending" ``` Die Listenantwort enthält die in die Warteschlange eingereihten Sitzungen in `items`: ```json theme={null} { "items": [ { "metadata": { "session_id": "devin-...", "outpost_id": "outpost_env-...", "created_at": 1781050000, "updated_at": 1781050000 }, "spec": { "kind": "new", "platform": "linux", "remote_binary_sha": null }, "status": { "phase": "pending", "acceptor_id": null, "claim_deadline": null, "session_status": "pending" } } ], "cursor": "djE6MTc4MTA1MDAwMC4w", "has_next_page": false, "total": 1 } ``` Verwenden Sie den Response-Cursor, um zu paginieren, ohne die gesamte Warteschlange jedes Mal erneut abzugleichen. Setzen Sie `first` auf die Seitengröße (bis zu 200), und übergeben Sie dann den `Cursor` jeder Antwort an die nächste Anfrage, solange `has_next_page` den Wert `true` hat: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&first=200&cursor=" ``` Die API bietet eine At-least-once-Zustellung. Eine Sitzung am Seitenübergang kann auf beiden Seiten erscheinen; aktualisieren oder erstellen Sie Einträge daher anhand von `metadata.session_id`, anstatt jedes Element als neu zu behandeln. Wenn `has_next_page` zu `false` wird, speichern Sie den zurückgegebenen Cursor als Startposition für die Watch-API.
#### Änderungen beobachten
Nach der anfänglichen Liste starten Sie mit dem letzten Cursor eine Server-Sent-Events-(SSE)-Überwachung: ```bash theme={null} curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&watch=true&cursor=" ``` Der Stream sendet `MODIFIED`-Ereignisse, wenn sich der Warteschlangeneintrag einer Sitzung ändert, und `DELETED`-Ereignisse, wenn er entfernt wird. Neu in die Warteschlange aufgenommene Sitzungen werden ebenfalls als `MODIFIED`-Ereignisse übermittelt. Jedes SSE-`data`-Feld enthält JSON in dieser Form: ```json theme={null} { "type": "MODIFIED", "object": { "metadata": { "session_id": "devin-...", "outpost_id": "outpost_env-...", "created_at": 1781050000, "updated_at": 1781050100 }, "spec": { "kind": "new", "platform": "linux", "remote_binary_sha": null }, "status": { "phase": "pending", "acceptor_id": null, "claim_deadline": null, "session_status": "pending" } }, "cursor": "djE6MTc4MTA1MDEwMC4w" } ``` Persistieren Sie den `cursor` auf oberster Ebene jedes Ereignisses, nachdem Sie es verarbeitet haben. Wenn die Verbindung abbricht, verbinden Sie sich mit dem zuletzt persistierten Cursor erneut, um alle Änderungen nachzuvollziehen, die während der Unterbrechung aufgetreten sind. Die Watch-Zustellung erfolgt ebenfalls mindestens einmal, daher müssen Clients doppelte Ereignisse tolerieren. Streams enden nach spätestens fünf Minuten; eine Watch-Schleife mit Wiederverbindung wird erwartet. Der `outpost`-Filter gilt sowohl für Listen- als auch für Watch-Anfragen. Die Filter `phase` und `acceptor_id` gelten nur für Listenanfragen und werden ignoriert, wenn `watch=true`; filtern Sie beobachtete Ereignisse anhand der Felder im `object` des jeweiligen Ereignisses. Wird der Cursor weggelassen, beginnt die Ausgabe am Anfang. Verwenden Sie daher für den normalen Abgleich list-then-watch. Bevor Sie eine Maschine für eine Sitzung starten, beanspruchen Sie sie atomar, damit kein anderer Worker sie übernimmt. Übergeben Sie eine `acceptor_id` — eine vom Worker selbst gemeldete Identität: ```bash theme={null} curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{"acceptor_id": "worker-1"}' \ "https://api.devin.ai/opbeta/outposts/devins/{session_id}/claim" ``` Das Beanspruchen erfolgt atomar: Wenn ein anderer Worker die Sitzung zuerst beansprucht hat, erhalten Sie einen `409`. Das Beanspruchen garantiert, dass innerhalb der vom Server zugewiesenen Beanspruchungsfrist (`status.claim_deadline`) ein Worker bereitsteht; abgelaufene Beanspruchungen werden automatisch wieder in die Warteschlange eingereiht. Wenn die Bereitstellung fehlschlägt, geben Sie die Beanspruchung frei, damit die Sitzung sofort in die Warteschlange zurückkehrt: ```bash theme={null} curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{"acceptor_id": "worker-1"}' \ "https://api.devin.ai/opbeta/outposts/devins/{session_id}/release" ```
### 3. Eine Maschine starten und den Worker ausführen
Stellen Sie für jede beanspruchte Sitzung aus Ihrem Image eine VM oder einen Container bereit. Führen Sie darin den Worker in dem Verzeichnis aus, in dem die Repositories der Sitzung bereits ausgecheckt wurden: ```bash theme={null} cd /path/to/repos devin worker start --session= --outpost= --acceptor-id= ``` Alle Repositorys der Sitzung müssen relativ zu dem Arbeitsverzeichnis ausgecheckt sein, von dem aus `devin worker start` aufgerufen wird: In diesem Beispiel würden Sie `devin worker start` in `repos/` ausführen, und die Sitzung sieht `app/` und `infra/` relativ zu ihrem Arbeitsverzeichnis. Nützliche Flags: | Flag | Beschreibung | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--session` | Identifiziert die Sitzung, die der Worker bedienen soll; der Worker wird beendet, wenn sie endet. | | `--outpost` | Identifiziert den Outpost für die Sitzung, die bedient werden soll. | | `--acceptor-id` | Verwendet dieselbe Acceptor-ID wie die API-Beanspruchung für diesen Worker. | | `--token` | Optionales Auth-Token für den Worker. Wenn es weggelassen wird, verwendet der Worker `DEVIN_OUTPOSTS_TOKEN`; wenn keines von beiden gesetzt ist, gibt der Befehl einen Fehler zurück. | Beispiele: ```bash theme={null} devin worker start --session= --outpost= --acceptor-id= --token="" DEVIN_OUTPOSTS_TOKEN="" devin worker start --session= --outpost= --acceptor-id= ``` Der Worker stellt eine Verbindung zu Devins Cloud her, markiert die Sitzung als bereit und beginnt mit der Ausführung von Tool-Aufrufen.
### 4. Die Remote-Binärdatei direkt herunterladen
Der Befehl `devin worker start` lädt automatisch die richtige `devin-remote`-Binärdatei herunter. Wenn Sie einen benutzerdefinierten Orchestrator erstellen, der nicht das Devin CLI verwendet, können Sie die Binärdatei direkt hier herunterladen: ``` https://static.devin.ai/devin-rs/remote/ ``` **Bestimmen Sie die aktuelle Version:** ```bash theme={null} # Gibt den Git-SHA des neuesten veröffentlichten Binaries für Ihre Plattform zurück curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64" ``` **Herunterladen und überprüfen:** ```bash theme={null} SHA=$(curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64") # Binärdatei herunterladen curl -fL "https://static.devin.ai/devin-rs/remote/devin-remote_${SHA}_linux_x64" \ -o devin-remote # Prüfsumme herunterladen und verifizieren curl -fsSL "https://static.devin.ai/devin-rs/remote/devin-remote_${SHA}_linux_x64.sha256" \ -o devin-remote.sha256 echo "$(cat devin-remote.sha256) devin-remote" | sha256sum -c chmod +x devin-remote ``` **Verfügbare Plattformen:** | Suffix | OS / Architektur | | ----------------- | ------------------- | | `linux_x64` | Linux x86\_64 | | `macos_arm64` | macOS Apple Silicon | | `windows_x64.exe` | Windows x86\_64 | Wenn der Queue-Eintrag der Sitzung eine `spec.remote_binary_sha` enthält, verwenden Sie diese SHA anstelle von `latest` — damit wird die Sitzung an eine bestimmte getestete Version angepinnt.
#### Spawn-Kontrakt
Wenn Ihr Orchestrator `devin-remote` selbst startet, starten Sie ihn wie folgt: ```bash theme={null} devin-remote serve ``` mit den folgenden Umgebungsvariablen: | Variable | Required | Description | | ----------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `DEVIN_OUTPOST_GATEWAY_URL` | Ja | Base-URL des Outpost-Gateways, z. B. `wss://outpost-gateway.devin.ai`. | | `DEVIN_OUTPOST_CONNECT_TOKEN` | Ja | Bearer-Connect-Token für das Gateway aus der Antwort zum Beanspruchen. | | `DEVIN_OUTPOST_SESSION_ID` | Ja | Die Sitzungs-ID, für die der Dienst bereitgestellt wird. Alle drei `DEVIN_OUTPOST_*`-Variablen müssen zusammen gesetzt werden. | | `DEVIN_REMOTE_STATE_DIR` | Dringend empfohlen | Sitzungsspezifisches Zustandsverzeichnis, in dem die Remote-Komponente ihre Anmeldedaten, Tokens und Shell-Integrationsdateien speichert. Verwenden Sie für jede Sitzung ein eindeutiges Verzeichnis (z. B. `~/.devin/worker/sessions/`, wie von `devin worker` verwendet). Wenn die Variable nicht gesetzt ist, greift die Remote-Komponente auf einen gemeinsamen systemweiten Standardpfad zurück (`/opt/.devin` unter Linux, `~/.devin` unter macOS, `C:\ProgramData\devin` unter Windows), der dann vorhanden und beschreibbar sein muss — und wodurch sitzungsspezifischer Zustand zwischen gleichzeitigen Sitzungen offengelegt wird. Setzen Sie dies immer. | | `DEVIN_CHROME_PATH` | Optional | Pfad zu einer Chrome-/Chromium-Binärdatei auf dem Rechner für das Browser-Tool (auf Outposts gibt es kein von Devin verwaltetes Chrome). | | `DEVIN_OUTPOST_DESKTOP` | Optional | Auf `true` setzen, um den Desktop-Stream (VNC) zu aktivieren. Auf der Remote-Seite wird er nur bei Bedarf aktiviert — es wird also nichts erfasst, bis sich ein Viewer verbindet — daher kann er bedenkenlos immer aktiviert werden. | Geben Sie der Remote-Komponente eine saubere Umgebung, die nur die oben genannten Variablen sowie grundlegende Systemvariablen enthält (`PATH`, `HOME`, `USER`, `LOGNAME`, `TMPDIR`, `LANG`, `TZ` und — für die Bildschirmaufnahme des Desktop-Streams unter Linux/X11 — `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`). Geben Sie nichts an die Remote-Komponente weiter, das der Agent nicht sehen können soll: Diese Umgebung wird von der Shell des Agenten vererbt. Zusätzliche Erwartungen an den Lifecycle: * **Arbeitsverzeichnis**: Starten Sie die Remote-Komponente aus dem Verzeichnis, das die Repositorys der Sitzung enthält (dieselbe Regel wie bei `devin worker start`). * **Sitzungsende**: Wenn die Sitzung endet (in den Ruhezustand wechselt oder beendet wird), benachrichtigt Devin die Remote-Komponente, und sie beendet sich von selbst mit Status 0. Werten Sie einen sauberen Exit als Ende der Sitzung: Vergewissern Sie sich, dass `status.session_status` des Warteschlangeneintrags `suspended` oder `terminated` ist (die Statusaktualisierung kann dem Beenden um einige Sekunden hinterherhinken, lesen Sie den Wert also einige Male erneut), und geben Sie dann das Beanspruchen frei. Als Fallback pollen Sie `status.session_status` auch, während die Remote-Komponente läuft, und beenden den Prozess selbst, sobald der Wert `terminated` erreicht ist (oder der Warteschlangeneintrag verschwindet).
### 5. Die Maschine beenden, wenn der Worker endet
Wenn `devin worker start` endet, ist die Sitzung beendet (oder wurde ausgesetzt). Beenden Sie die VM oder den Container. Wenn Ihr Outpost Sitzungen wieder aufnehmen kann, erstellen Sie vor dem Beenden einen Snapshot der Maschine, damit Sie sie wiederherstellen können, falls die Sitzung fortgesetzt wird. Ihr Orchestrator kann die von ihm beanspruchten Sitzungen und deren Status nachverfolgen: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?phase=claimed&acceptor_id=worker-1" ``` Jeder Eintrag enthält für `status.session_status` einen der Werte `pending`, `running`, `suspended` oder `terminated`.
## Planung ohne zentrale Koordination
Planen Sie, mehr als ca. 16 Koordinatoren (Worker oder Orchestratoren, die einen Outpost überwachen und daraus beanspruchen) auszuführen? Wenden Sie sich zuerst an Ihr Account-Team — größere Flotten erhöhen die Konkurrenz um Beanspruchungen und die Leselast der Warteschlange, und wir möchten sicherstellen, dass der Outpost dafür entsprechend bereitgestellt ist. Sie benötigen keinen zentralen Scheduler, um eine Flotte zu betreiben. Die Queue-API ist so konzipiert, dass viele unabhängige Worker denselben Outpost bedienen können, ohne miteinander kommunizieren zu müssen: * **Beanspruchungen sind der einzige Koordinationsmechanismus.** Jeder Worker überwacht die Warteschlange unabhängig und versucht im Wettlauf, ausstehende Sitzungen zu beanspruchen. Die Beanspruchung ist ein atomisches Compare-and-Swap auf dem Server: Genau ein Worker gewinnt, und jeder Verlierer erhält einen `409` und macht einfach mit der nächsten ausstehenden Sitzung weiter. Einen Wettlauf um eine Beanspruchung zu verlieren, ist normal und kein Fehler. * **Jeder Worker hat eine eigene Identität.** Die `acceptor_id` begrenzt die Beanspruchungen, Verlängerungen und die Wiederherstellung nach einem Neustart eines Workers ausschließlich auf diesen Worker. `devin worker start` erzeugt und speichert automatisch eine pro Maschine, sodass eine Flotte keine Identitätskonfiguration benötigt. Teilen Sie niemals eine Acceptor-ID (oder ein kopiertes Worker-Datenverzeichnis) zwischen Maschinen — kollidierende Worker nehmen sich gegenseitig die Beanspruchungen weg. * **Fehler heilen sich selbst.** Wenn ein Worker nach dem Beanspruchen ausfällt, läuft seine Beanspruchung bis zur Beanspruchungsfrist ab, und die Sitzung kehrt in die Warteschlange zurück, damit ein anderer Worker sie übernehmen kann. Eine flottenweite Zustandsüberwachung ist nicht erforderlich. Das bedeutet: Zum Skalieren führen Sie den Worker einfach auf mehr Maschinen aus, die auf denselben Outpost zeigen: N Maschinen bedienen N gleichzeitige Sitzungen, der Rest wartet weiter als ausstehend. Zwei Betriebshinweise: * **Verwenden Sie den Watch-Endpunkt, nicht wiederholt vollständige Listen.** Führen Sie einmal eine paginierte Liste aus, um den Anfangszustand aufzubauen, und halten Sie dann einen [Watch-Stream](#watch-for-changes) ab dem zurückgegebenen Cursor offen. Die gesamte Warteschlange von jedem Worker immer wieder neu zu pollen skaliert schlecht und erhöht die Beanspruchungslatenz; der Watch-Stream liefert Änderungen, sobald sie auftreten. * **Sprechen Sie mit uns, bevor Sie über \~16 Maschinen pro Outpost hinausgehen.** Beanspruchen ohne Koordination funktioniert bei kleinen Flottengrößen gut, aber größere Flotten erhöhen die Konkurrenz um Beanspruchungen und die Leselast der Warteschlange. Wenn Sie planen, mehr als etwa 16 Worker für einen einzelnen Outpost auszuführen, wenden Sie sich zuerst an Ihr Account-Team, damit wir sicherstellen können, dass der Outpost dafür entsprechend bereitgestellt ist.
## API-Referenz
Alle Outposts-Endpunkte sind unter `https://api.devin.ai/opbeta` verfügbar und verwenden eine gemeinsame Ressourcenstruktur (`metadata` / `spec` / `status`). Listenantworten geben `items`, `cursor`, `has_next_page` und `total` zurück.
### Devins (`/outposts/devins`)
| Endpunkt | Beschreibung | | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | `GET /outposts/devins?outpost=...&phase=pending` | Sitzungen auflisten, die auf einen Worker warten. | | `GET /outposts/devins?outpost=...&first=...&cursor=...` | Eine paginierte Liste ab dem Cursor einer vorherigen Antwort fortsetzen. | | `GET /outposts/devins?outpost=...&watch=true&cursor=...` | `MODIFIED`- und `DELETED`-Ereignisse nach einem Listen- oder Watch-Cursor streamen. | | `GET /outposts/devins?phase=claimed&acceptor_id=...` | Von einem bestimmten Acceptor beanspruchte Sitzungen auflisten. | | `GET /outposts/devins/{session_id}` | Einen einzelnen Warteschlangeneintrag abrufen. | | `POST /outposts/devins/{session_id}/claim` | Eine Sitzung atomar beanspruchen (`409`, falls sie bereits beansprucht wurde). Body: `{"acceptor_id": "..."}`. | | `POST /outposts/devins/{session_id}/release` | Eine Beanspruchung freigeben und die Sitzung in die Warteschlange zurückstellen. Body: `{"acceptor_id": "..."}`. |
### Outposts (`/outposts`)
| Endpunkt | Beschreibung | | ------------------------------- | --------------------------------------------------------------------------------------------------- | | `GET /outposts` | Outposts Ihres Kontos auflisten. | | `POST /outposts` | Einen Outpost erstellen. Body: `{"name": "my-outpost", "platform": "linux", "description": "..."}`. | | `GET /outposts/{outpost_id}` | Einen einzelnen Outpost abrufen. | | `DELETE /outposts/{outpost_id}` | Einen Outpost löschen (`409`, solange er aktive Beanspruchungen hat). | ```json theme={null} { "metadata": { "outpost_id": "outpost_env-...", "account_id": "...", "created_at": 1781050000 }, "spec": { "name": "my-outpost", "platform": "linux", "description": "..." }, "status": { "queue_depth": 3, "active_claims": 2 } } ``` `status.queue_depth` und `status.active_claims` sind nützliche Signale für die Autoskalierung: Wenn sich die Warteschlange staut, kann Ihr Orchestrator mehr warme Maschinen bereitstellen.
## Was Worker können
Sitzungen, die auf Outposts-Workern laufen, sind vollwertige Devin-Sitzungen: Skills, Knowledge, MCP-Server und Secrets funktionieren genauso wie in Devin Cloud und werden über die Verbindung des Workers bereitgestellt. Ihre Repositorys, Build-Caches und die Tool-Ausführung bleiben in Ihrer Umgebung; Sitzungsartefakte wie Screenshots werden in Devin Cloud hochgeladen, sodass Sie sie in der Sitzung und in PRs ansehen können. Outpost-Sitzungen haben strenge Timeouts für die Einsatzbereitschaft. Nachdem Ihr Orchestrator eine Sitzung beansprucht hat, muss der Worker vor Ablauf der Beanspruchungsfrist eine Verbindung herstellen — andernfalls verfällt die Beanspruchung, und Ihnen werden dennoch die fixen und stündlichen Kosten berechnet, die während des Timeout-Zeitraums anfallen.