Zum Hauptinhalt springen
Mit Outposts können Sie Devin-Sitzungen auf einer 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 stattfinden, die Sie betreiben. Verwenden Sie Outposts, wenn Sie Folgendes benötigen:
  • Sitzungen, die innerhalb Ihres Netzwerks laufen, in der Nähe interner Dienste, Registries und Secrets
  • Benutzerdefinierte Hardwareprofile (z. B. GPUs, Maschinen mit viel Arbeitsspeicher, spezifische OS-Images)
  • Vorhandene Dev-Box-, VM- oder Kubernetes-Infrastruktur zum Ausführen von Devin-Workloads
  • Enterprise-Steuerung für Netzwerkzugriff, Build-Ausgaben 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 abholt. Jede Maschine, die Sitzungen aus einem Outpost ausführt, ist ein worker. Um eine Maschine in einen worker zu verwandeln, installieren Sie die Devin CLI und führen Sie Folgendes aus:
Der Worker öffnet eine ausgehende Verbindung zu Devins Cloud und überwacht die Warteschlange des Outposts. Wenn eine Sitzung wartet, beansprucht der Worker sie und führt ihre Tool-Aufrufe lokal aus — jeder Befehl, jede Dateibearbeitung und jede Operation im Repository läuft auf Ihrer Maschine. Wenn die Sitzung endet, überwacht der Worker wieder die Warteschlange für die nächste Sitzung. Die Skalierung erfolgt einfach dadurch, dass der Worker auf mehr Maschinen ausgeführt wird: 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 startet, den Worker darin ausführt 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 das bereits für Sie implementiert (siehe Integrationen).

​
Maschinenabhängigkeiten

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

​
Erste Schritte

Schnellstart

Erstellen Sie einen Outpost und führen Sie Sitzungen auf einer einzelnen Maschine mit devin worker start aus — ganz ohne Orchestrator.

Orchestrierung

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

Referenz

Der vollständige Funktionsumfang: CLI-Befehle und Flags, Endpunkte der Fleet API, Binärdistribution und der Spawn-Vertrag.

​
Integrationen

Partnerplattformen übernehmen den Orchestrierungszyklus für Sie — Sitzungen laufen auf deren Infrastruktur, ohne dass Sie einen Worker ausführen oder einen Orchestrator erstellen müssen. Jeder Partner dokumentiert sein eigenes Setup:

​
Einschränkungen

  • Devin Outposts funktioniert derzeit nur mit Multi-Tenant-Hosting; für Dedicated-Tenant-Bereitstellungen ist es aktuell nicht verfügbar.
  • Outposts verlagert einen erheblichen Teil der Verantwortung für Infrastruktur und Betrieb 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. Für sicherheitsbewusste Kunden empfehlen wir Dedicated Tenant (Dedicated SaaS), das eine isolierte Kundenumgebung bereitstellt, deren Sicherheit und Orchestrierung von Cognition verwaltet werden.