Passer au contenu principal
Outposts vous permet d’exécuter des sessions Devin dans 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 se font sur des machines que vous exploitez. Utilisez Outposts si 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 avec beaucoup de mémoire, images d’OS spécifiques)
  • Une infrastructure existante de dev box, de VM ou Kubernetes pour héberger les workloads de 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 — un serveur GPU dans votre labo, une VM dans votre VPC ou un Mac mini sur votre bureau — servent les sessions via une connexion uniquement sortante

​
Comment ça fonctionne

Un outpost est une file d’attente nommée de sessions Devin exécutées sur vos propres machines. Une fois un outpost enregistré (p. ex. gpu-h200 ou dev-boxes), il apparaît comme option de machine dans Devin Cloud aux côtés d’Ubuntu, de Windows, etc. — les sessions Cloud lancées sur un outpost attendent dans sa file d’attente jusqu’à ce qu’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 jusqu’à ce qu’un worker soit disponible. Les workers n’ont besoin que d’un accès HTTPS sortant. Aucun port entrant, aucune IP publique ni aucun tunnel VPN ne sont requis.

​
Orchestration

Les machines hébergeant des workers de longue durée 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, lance une nouvelle VM ou un nouveau conteneur, y démarre le worker, puis démonte la machine à la fin de la session. Consultez Orchestration pour savoir comment faire, 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, le worker dépend donc des outils que vous y installez.

​
Pour commencer

Démarrage rapide

Créez un outpost et exécutez des sessions sur une seule machine avec devin worker start — sans orchestrateur.

Orchestration

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

Référence

La 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 implémentent la boucle d’orchestration à votre place — les sessions s’exécutent sur leur infrastructure, sans worker à lancer ni orchestrateur à mettre en place. Chaque partenaire documente sa propre configuration :

​
Limitations

  • Devin Outposts fonctionne actuellement uniquement avec un 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 équipes doivent sécuriser et exploiter à grande échelle leurs VM de développement à distance, y compris le provisioning, l’isolation, les contrôles d’accès, la gestion des capacités, la supervision et la reprise. Pour les clients soucieux de la sécurité, nous vous recommandons Dedicated Tenant (Dedicated SaaS), qui offre un environnement isolé pour le client, avec la sécurité et l’orchestration gérées par Cognition.