Zum Hauptinhalt springen
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 auf 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
Devins Agent-Loop und die Outpost-Warteschlange laufen in Devins Cloud; Ihre Maschinen — eine GPU-Box in Ihrem Labor, eine VM in Ihrer VPC oder ein Mac mini auf Ihrem Schreibtisch — führen Sitzungen über eine ausschließlich ausgehende Verbindung aus

​
Wie es funktioniert

Ein outpost ist eine benannte Warteschlange für Devin-Sitzungen, die auf Ihren eigenen Maschinen ausgeführt werden. Sobald Sie einen outpost registrieren (z. B. gpu-h200 oder dev-boxes), erscheint er in Devin Cloud neben Ubuntu, Windows usw. als Maschinenoption — Cloud-Sitzungen, die auf einem outpost gestartet werden, warten in dessen Warteschlange, bis eine Ihrer Maschinen sie übernimmt. Jede Maschine, die Sitzungen aus einem outpost bearbeitet, ist ein worker. Um eine Maschine in einen worker zu verwandeln, installieren Sie die Devin CLI und führen Sie Folgendes aus:
Der Worker baut eine ausgehende Verbindung zu Devins Cloud auf und überwacht die Warteschlange des Outposts. Wenn eine Sitzung ansteht, übernimmt der Worker sie und führt ihre Tool-Aufrufe lokal aus — jeder Befehl, jede Dateibearbeitung und jede Repository-Operation läuft auf Ihrer Maschine. Wenn die Sitzung endet, überwacht der Worker anschließend wieder die Warteschlange für die nächste Sitzung. Zum Skalieren müssen Sie den Worker nur auf mehr Maschinen ausführen: N Worker bedienen N gleichzeitige Sitzungen, und alle weiteren Sitzungen warten in der Warteschlange, bis ein Worker verfügbar ist. Worker benötigen nur ausgehenden HTTPS-Zugriff. Es sind keine eingehenden Ports, öffentlichen IPs oder VPN-Tunnel erforderlich.

​
Orchestrierung

Langlebige Worker-Maschinen sind das einfachste Setup, aber mit der Outposts API können Sie auch einen Orchestrator schreiben: eine Software, die die Warteschlange des Outposts überwacht, für jede wartende Sitzung eine neue VM oder einen neuen Container hochfährt, darin den Worker startet und die Maschine wieder herunterfährt, wenn die Sitzung endet. Unter Orchestrierung erfahren Sie, wie das funktioniert. Sie können devin-outpost-k8s bereitstellen — unseren Open-Source-Operator, der diesen Ablauf auf jedem Kubernetes-Cluster ausführt — oder eine Partnerplattform nutzen, die dies bereits für Sie implementiert (siehe Integrationen).

​
Abhängigkeiten der Maschine

Sitzungen werden direkt auf Ihren Maschinen ausgeführt, daher ist der Worker auf Tools angewiesen, die Sie dort installieren.

​
Erste Schritte

Schnellstart

Erstellen Sie einen Outpost und bedienen Sie Sitzungen von einer einzelnen Maschine mit devin worker start — kein Orchestrator erforderlich.

Orchestrierung

Skalieren Sie auf eine Flotte: pollen Sie die Warteschlange, beanspruchen Sie Sitzungen, stellen Sie Maschinen bereit und starten Sie workers automatisch.

Referenz

Der vollständige Umfang: CLI-Befehle und Flags, Endpunkte der fleet API, Binärdistribution und die Spawn-Spezifikation.

​
Integrationen

Partnerplattformen übernehmen die Orchestrierungsschleife für Sie — Sitzungen laufen auf ihrer Infrastruktur, ohne dass Sie einen worker ausführen oder einen orchestrator bauen müssen. Jeder Partner dokumentiert sein eigenes Setup:

​
Einschränkungen

  • Devin Outposts funktioniert derzeit nur mit Multi-Tenant-Hosting; es ist derzeit nicht mit Dedicated-Tenant-Deployments verfügbar.
  • Outposts verlagert erhebliche Infrastruktur- und Betriebsverantwortung auf den Kunden. Teams müssen ihre Remote-Development-VMs in großem Maßstab absichern und betreiben, einschließlich Provisionierung, Isolierung, Zugriffskontrollen, Kapazitätsmanagement, Überwachung und Wiederherstellung. Sicherheitsbewussten Kunden empfehlen wir Dedicated Tenant (Dedicated SaaS), das eine isolierte Kundenumgebung bereitstellt, bei der Cognition Sicherheit und Orchestrierung übernimmt.