- 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
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 :
Démarrer des sessions sur un outpost
Lors du démarrage d’une session dans Devin Cloud, sélectionnez l’outpost sous Configuration → Environnement virtuel (voir le Démarrage rapide). Vous pouvez également le faire depuis Slack à l’aide de la commande bang!outpost :
!outpost <name> accepte le nom exact de l’outpost, un préfixe unique (!outpost gpu si gpu-h200 est la seule correspondance) ou son ID. Envoyez simplement !outpost pour obtenir la liste des outposts que vous pouvez utiliser.
Pour que les nouvelles sessions s’exécutent par défaut sur un outpost partagé, un administrateur peut le définir comme plateforme par défaut de l’organisation dans Settings → Devin → Default platform, ou via l’API Set Organization Default Platform. L’API Get Organization Default Platform renvoie la valeur par défaut actuelle.
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 sont en exécution sur leur infrastructure, sans worker à mettre en exécution ni orchestrateur à mettre en place. Chaque partenaire documente sa propre configuration :| Plateforme | Ce que vous obtenez | Documentation |
|---|---|---|
 Namespace | Des environnements macOS natifs sur Apple Silicon — avec Computer Use, Devin compile, met en exécution et teste des applications iOS de bout en bout | Devin Outposts on Namespace |
 Modal | La même infrastructure que celle sur laquelle vous entraînez et servez vos modèles — reproduisez les échecs et analysez les correctifs sur du matériel de production, avec une mise à l’échelle jusqu’à zéro | Devin Outposts on Modal |
 OpenShell | Un sandbox pour chaque session via l’environnement d’exécution OpenShell — d’une VM unique à un cluster GPU, conçu pour les environnements sécurisés et gouvernementaux | Devin Outposts on NVIDIA OpenShell |
| Brev | Des instances GPU sur NVIDIA Brev, déployées via un Launchable en un clic | Devin Outposts on NVIDIA Brev |
 Daytona | Des sandbox Linux et Windows qui démarrent en moins de 90 ms à partir de snapshots — repos, dépendances et chaînes d’outils déjà en place | Devin Outposts on Daytona |
 E2B | Des machines pour agents avec n’importe quelle configuration CPU/RAM et des démarrages en moins d’une seconde — y compris l’accès à votre cloud privé | Devin Outposts on E2B |
 Cloudflare | Un sandbox isolé par session, avec un trafic transitant via des proxys personnalisables et une connectivité privée vers les services internes — sans VPN ni exposition publique | Devin Outposts on Cloudflare |
Limites
- Devin Outposts est disponible sur tous les comptes Pro, Max et Teams.
- Devin Outposts est disponible sur les déploiements Dedicated Tenant, mais est désactivé par défaut, car certaines fonctionnalités de Devin se comportent différemment lorsque des agents sont en cours d’exécution sur une infrastructure gérée par le client. Votre account team peut vous en expliquer les détails et l’activer.
- 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.