Outposts

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:

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 enthält die Logik zum Abrufen und Ausführen dieser Binärdatei.
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 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
- 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, 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:

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.
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.
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:

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 installiert ist:

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 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 und die Maschinenabhängigkeiten, und starten Sie dann den Worker aus dem Verzeichnis, das Ihre ausgecheckten Repositorys enthält:

cd /path/to/repos
devin worker start --outpost=<outpost_id>

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=<session_id>, 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.

Nutzen Sie Kubernetes? Der Open-Source- 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:

helm install outposts charts/devin-outposts-k8s \
  --set defaultPool.enabled=true \
  --set defaultPool.poolId=<outpost_id> \
  --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:

devin worker outpost create <name> --platform <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:

curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&phase=pending"

Die Listenantwort enthält die in die Warteschlange eingereihten Sitzungen in items:

{
  "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:

curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&first=200&cursor=<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:

curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&watch=true&cursor=<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:

{
  "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:

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:

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:

cd /path/to/repos
devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_id>

Alle Repositorys der Sitzung müssen relativ zu dem Arbeitsverzeichnis ausgecheckt sein, von dem aus devin worker start aufgerufen wird:

repos

app

.git

infra

.git

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:

devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_id> --token="<token>"
DEVIN_OUTPOSTS_TOKEN="<token>" devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_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:

# 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:

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:

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/<session_id>`, 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:

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 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).

{
  "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.

Loslegen

Grundlegende Richtlinien

Einführung in Devin

Arbeiten mit Devin

Produktleitfäden

Integrationen

Admin

Versionshinweise

Wie es funktioniert

Voraussetzungen

Abhängigkeiten der Maschine

Schnellstart: einen Outpost erstellen und einen Worker starten

1. Service-User-Token erstellen

2. Einen Outpost erstellen

3. Worker starten

4. Starten Sie eine Sitzung auf dem Outpost

Der grundlegende Ablauf

1. Einen Outpost registrieren

2. Die Fleet-API auf wartende Sitzungen pollen

Änderungen beobachten

3. Eine Maschine starten und den Worker ausführen

4. Die Remote-Binärdatei direkt herunterladen

Spawn-Kontrakt

5. Die Maschine beenden, wenn der Worker endet

Planung ohne zentrale Koordination

API-Referenz

Devins (`/outposts/devins`)

Outposts (`/outposts`)

Was Worker können

​Wie es funktioniert

​Voraussetzungen

​Abhängigkeiten der Maschine

​Schnellstart: einen Outpost erstellen und einen Worker starten

​1. Service-User-Token erstellen

​2. Einen Outpost erstellen

​3. Worker starten

​4. Starten Sie eine Sitzung auf dem Outpost

​Der grundlegende Ablauf

​1. Einen Outpost registrieren

​2. Die Fleet-API auf wartende Sitzungen pollen

​Änderungen beobachten

​3. Eine Maschine starten und den Worker ausführen

​4. Die Remote-Binärdatei direkt herunterladen

​Spawn-Kontrakt

​5. Die Maschine beenden, wenn der Worker endet

​Planung ohne zentrale Koordination

​API-Referenz

​Devins (/outposts/devins)

​Outposts (/outposts)

​Was Worker können

Wie es funktioniert

Voraussetzungen

Abhängigkeiten der Maschine

Schnellstart: einen Outpost erstellen und einen Worker starten

1. Service-User-Token erstellen

2. Einen Outpost erstellen

3. Worker starten

4. Starten Sie eine Sitzung auf dem Outpost

Der grundlegende Ablauf

1. Einen Outpost registrieren

2. Die Fleet-API auf wartende Sitzungen pollen

Änderungen beobachten

3. Eine Maschine starten und den Worker ausführen

4. Die Remote-Binärdatei direkt herunterladen

Spawn-Kontrakt

5. Die Maschine beenden, wenn der Worker endet

Planung ohne zentrale Koordination

API-Referenz

Devins (`/outposts/devins`)

Outposts (`/outposts`)

Was Worker können