Passer au contenu principal
Outposts vous permet d’exécuter des sessions Devin au sein d’une infrastructure que vous contrôlez — vos propres VM, conteneurs, clusters Kubernetes, ou même un Mac Mini sur votre bureau. La boucle de l’agent Devin (inférence et planification) continue de s’exécuter dans le cloud de Devin, tandis que l’exécution des commandes, les modifications de fichiers et l’accès aux dépôts ont lieu sur des machines que vous exploitez. Utilisez Outposts lorsque vous avez besoin de :
  • Sessions exécutées dans votre réseau, à proximité de services internes, de registries et de secrets
  • Profils matériels personnalisés (p. ex. GPU, machines dotées de beaucoup de mémoire, images de système d’exploitation spécifiques)
  • Infrastructure existante (postes de développement, VM ou Kubernetes) pour héberger les charges de travail Devin
  • Contrôles Enterprise sur l’accès réseau, les sorties de build et la supervision
La boucle de l’agent Devin et la file d’attente de l’outpost s’exécutent dans le cloud de Devin ; vos machines — une machine GPU dans votre laboratoire, une VM dans votre VPC ou un Mac mini sur votre bureau — prennent en charge les sessions via une connexion uniquement sortante

​
Comment ça marche

Un outpost est une file d’attente nommée de sessions Devin à exécuter sur vos propres machines. Une fois un outpost enregistré (par ex. gpu-h200 ou dev-boxes), il apparaît comme option de machine dans Devin Cloud, aux côtés d’Ubuntu, Windows, etc. — les sessions cloud démarrées sur un outpost attendent dans sa file d’attente jusqu’à ce que l’une de vos machines les prenne en charge. Chaque machine qui exécute des sessions depuis un outpost est un worker. Pour transformer une machine en worker, installez le Devin CLI et exécutez :
Le worker ouvre une connexion sortante vers le cloud de Devin et surveille la file d’attente de l’outpost. Lorsqu’une session est en attente, le worker la prend en charge et exécute ses appels d’outil localement — chaque commande, modification de fichier et opération sur le dépôt s’exécute sur votre machine. Lorsque la session se termine, le worker recommence à surveiller la file d’attente en attendant la session suivante. Pour passer à l’échelle, il suffit d’exécuter le worker sur davantage de machines : N workers prennent en charge N sessions simultanées, et les sessions supplémentaires attendent dans la file d’attente jusqu’à ce qu’un worker soit disponible. Les workers n’ont besoin que d’un accès HTTPS sortant. Aucun port entrant, aucune adresse IP publique ni aucun tunnel VPN ne sont requis.

​
Orchestration

Les machines worker persistantes constituent la configuration la plus simple, mais avec l’API Outposts, vous pouvez aussi écrire un orchestrateur : un logiciel qui surveille la file d’attente de l’outpost et qui, pour chaque session en attente, démarre une nouvelle VM ou un nouveau conteneur, y lance le worker, puis démonte la machine lorsque la session se termine. Consultez Orchestration pour savoir comment procéder, déployez devin-outpost-k8s — notre opérateur open source qui exécute cette boucle sur n’importe quel cluster Kubernetes — ou utilisez une plateforme partenaire qui l’implémente déjà pour vous (voir Intégrations).

​
Dépendances de la machine

Les sessions s’exécutent directement sur vos machines, donc le worker dépend des outils que vous y installez.

​
Premiers pas

Démarrage rapide

Créez un outpost et prenez en charge des sessions sur une seule machine avec devin worker start — aucun orchestrateur n’est nécessaire.

Orchestration

Passez à l’échelle avec une flotte : interrogez périodiquement la file d’attente, prenez en charge les sessions, provisionnez des machines et exécutez automatiquement les workers.

Référence

Référence complète : commandes CLI et flags, endpoints de la fleet API, distribution du binaire et contrat de spawn.

​
Intégrations

Les plateformes partenaires prennent en charge la boucle d’orchestration pour vous — les sessions s’exécutent sur leur infrastructure, sans worker à lancer ni orchestrateur à mettre en place. Chaque partenaire documente sa propre configuration :

​
Limites

  • Devin Outposts fonctionne actuellement uniquement avec l’hébergement multi-tenant ; il n’est pas disponible actuellement avec les déploiements Dedicated Tenant.
  • Outposts transfère au client une part importante des responsabilités d’infrastructure et d’exploitation. Les Teams doivent sécuriser et exploiter leurs VM de développement à distance à grande échelle, notamment en matière de provisioning, d’isolation, de contrôles d’accès, de gestion des capacités, de supervision et de reprise. Pour les clients particulièrement soucieux de la sécurité, nous vous recommandons Dedicated Tenant (Dedicated SaaS), qui fournit un environnement isolé pour le client, avec la sécurité et l’orchestration gérées par Cognition.