Outposts

Outposts est en accès anticipé. Les API et les commandes CLI décrites ici sont susceptibles d’évoluer. Contactez l’équipe en charge de votre compte pour activer Outposts pour votre organisation.

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 sous 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

Fonctionnement

Outposts comporte deux couches :

Le worker (p. ex. devin worker start) — un binaire que vous exécutez sur une machine pour prendre en charge une seule session en file d’attente. Il ouvre une connexion sortante vers le cloud de Devin et exécute localement les appels d’outil de la session. Cognition fournit ce binaire ; vous n’avez jamais besoin de l’implémenter. Le Devin CLI contient la logique permettant de récupérer et d’exécuter ce binaire.
L’orchestrateur — un logiciel qui surveille l’API de flotte pour repérer les sessions en attente d’un worker, provisionne une VM ou un conteneur pour chacune d’elles, puis y démarre le worker. Nous fournissons quelques implémentations de référence pour les plateformes courantes (comme Kubernetes), mais vous pouvez librement les adapter (elles sont open source !) ou écrire la vôtre.

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 nécessaires. Lorsqu’un utilisateur démarre une session dans Devin Cloud et sélectionne l’un de vos outposts enregistrés, la session est placée dans la file d’attente de cet outpost. Votre orchestrateur la prend en charge, lance une machine et y exécute le worker. Lorsque la session se termine, le worker s’arrête et votre orchestrateur supprime la machine.

Prérequis

Une organisation avec Outposts activé
Un jeton d’API v3 avec les périmètres Outposts appropriés :
- account.outposts.orchestrator pour les orchestrateurs qui gèrent les outposts (implique le périmètre machine)
- account.outposts.machine pour les workers qui lisent la file d’attente et prennent en charge/libèrent des sessions
Une image de machine (VM ou conteneur) avec :
- Devin CLI installé
- Les dépendances de la machine ci-dessous
- Vos dépôts clonés, avec des remotes configurées
- Un accès aux build tools, aux package registries, aux secrets et aux services internes dont vos sessions ont besoin

Dépendances de la machine

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

Dépendance	Utilisation
`git` (dans le `PATH`)	Clonage et toutes les opérations sur les dépôts

Facultatif — installez-les pour débloquer des fonctionnalités spécifiques :

Dépendance	Fonctionnalité
`ffmpeg` (dans le `PATH`)	Les fonctions d’enregistrement d’écran de Devin. Sans lui, les sessions ne peuvent pas enregistrer l’écran.
Chrome ou Chromium	Les fonctionnalités Browser et d’interaction avec l’ordinateur. Par défaut, le worker recherche Chrome dans les emplacements d’installation standard ; définissez `DEVIN_CHROME_PATH` dans l’environnement du worker avec le chemin absolu du binaire pour y déroger (p. ex. `DEVIN_CHROME_PATH=/usr/bin/google-chrome`). Sans cela, les outils Browser ne sont pas disponibles.
`sudo` sans mot de passe	Permet à Devin d’installer les logiciels dont il a besoin pendant une session (p. ex. des build tools manquants ou des packages système). N’accordez cet accès que si la machine est dédiée à Devin et reprovisionnée après chaque session — jamais sur des machines partagées ou de longue durée de vie.

Démarrage rapide : créer un outpost et lancer un worker

Cette procédure permet de créer un outpost et de le faire tourner sur une seule machine avec devin worker start, sans orchestrator. C’est le moyen le plus rapide d’essayer Outposts sur une machine de développement, et c’est aussi la commande qu’un orchestrator utilise à grande échelle.

1. Créer un jeton d’utilisateur de service

Le worker (et tout orchestrator) s’authentifie auprès de l’API Outposts avec un jeton d’API v3 appartenant à un utilisateur de service ; les autorisations de rôle ci-dessous confèrent au jeton ses périmètres Outposts (UseOutpostsMachine → account.outposts.machine, ManageOutpostsOrchestrator → account.outposts.orchestrator). Dans l’application web Devin :

Créez un rôle ayant accès à Outposts. Sous Settings → Roles, ajoutez un rôle Enterprise et activez Use outpost machine (UseOutpostsMachine) dans Outpost permissions. Activez également Manage outposts (ManageOutpostsOrchestrator) si cet utilisateur de service doit créer ou supprimer des outposts.
Provisionnez l’utilisateur de service. Sous Settings → Devin API → Service users, cliquez sur Provision service user, donnez-lui un nom (par ex. outposts-worker), attribuez-lui le rôle de l’étape 1 et définissez une date d’expiration.
Copiez le jeton. Le jeton cog_... n’est affiché qu’une seule fois lors de sa création — copiez-le maintenant ; vous ne pourrez plus le récupérer par la suite.

Exportez-le pour les commandes ci-dessous :

export DEVIN_OUTPOSTS_TOKEN="cog_..."

2. Créer un outpost

Un outpost est une file d’attente de sessions identifiée par un nom et gérée par votre infrastructure. Créez-en un depuis n’importe quelle machine sur laquelle Devin CLI est installé :

devin worker outpost create my-outpost --platform linux --description "Dev boxes in our VPC"

La commande affiche l’ID du nouvel outpost (outpost_env-...) — notez-le pour l’étape suivante. Vous pouvez aussi créer des outposts dans l’application web, sous Settings → Outposts, ou via l’API Outposts. Une fois créé, l’outpost apparaît parmi les options de machine dans Devin Cloud (aux côtés d’Ubuntu, Windows, etc.) lors du démarrage d’une session.

3. Lancer le worker

Sur la machine qui hébergera les sessions, installez le Devin CLI et les dépendances de la machine, puis démarrez le worker depuis le répertoire contenant vos dépôts clonés :

cd /path/to/repos
devin worker start --outpost=<outpost_id>

Le worker interroge périodiquement la file de l’outpost, prend en charge la première session en attente, télécharge le binaire devin-remote approprié et exécute la session. Lorsque la session se termine, il revient à la file et attend la suivante. Passez --once pour quitter après avoir exécuté une seule session, ou --session=<session_id> pour prendre en charge et exécuter une session spécifique. Si --token et DEVIN_OUTPOSTS_TOKEN ne sont tous les deux pas définis, la commande échoue. Si --outpost est omis dans un terminal interactif, le worker vous invite à choisir parmi les outposts de votre compte.

4. Démarrer une session sur l’outpost

Dans Devin Cloud, démarrez une nouvelle session et sélectionnez votre outpost comme machine cible. La session est mise en file d’attente, votre worker la prend en charge et l’exécution démarre sur votre machine. Pour traiter davantage de sessions en parallèle, exécutez le worker sur plus de machines configurées pour le même outpost — voir ordonnancement sans centralisation.

Vous utilisez Kubernetes ? L’opérateur open source devin-outpost-k8s s’installe via Helm et exécute des workers pour un outpost sur n’importe quel cluster certifié (GKE, EKS, …). À partir d’un clone de ce dépôt :

helm install outposts charts/devin-outposts-k8s \
  --set defaultPool.enabled=true \
  --set defaultPool.poolId=<outpost_id> \
  --set defaultPool.token.value="$DEVIN_OUTPOSTS_TOKEN"

Le processus principal

1. Déclarer un outpost

Un outpost est une file d’attente nommée de sessions prises en charge par de nombreux workers sur votre infrastructure (par exemple, rhel, gpu-h200 ou my-outpost). Créez-en un avec devin worker outpost create :

devin worker outpost create <name> --platform <platform> --description "..."

Une fois enregistré, l’outpost apparaît comme option de machine dans Devin Cloud (aux côtés d’Ubuntu, Windows, etc.) au démarrage d’une session. Les sessions qui le ciblent attendent dans sa file d’attente jusqu’à ce qu’un worker les prenne en charge.

Dans l’API de flotte, les outposts sont représentés par des ressources outposts, rattachées à votre compte (et partagées entre toutes ses organisations).

2. Interroger périodiquement l’API de la flotte pour les sessions en attente

Votre orchestrateur liste les sessions en attente pour les Outposts qu’il gère :

curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&phase=pending"

La réponse de liste place les sessions en file d’attente dans items :

{
  "items": [
    {
      "metadata": {
        "session_id": "devin-...",
        "outpost_id": "outpost_env-...",
        "created_at": 1781050000,
        "updated_at": 1781050000
      },
      "spec": {
        "kind": "new",
        "platform": "linux",
        "remote_binary_sha": null
      },
      "status": {
        "phase": "pending",
        "acceptor_id": null,
        "claim_deadline": null,
        "session_status": "pending"
      }
    }
  ],
  "cursor": "djE6MTc4MTA1MDAwMC4w",
  "has_next_page": false,
  "total": 1
}

Utilisez le curseur de réponse pour paginer sans resynchroniser à plusieurs reprises la file d’attente complète. Définissez first sur la taille de page (jusqu’à 200), puis transmettez le cursor de chaque réponse dans la requête suivante tant que has_next_page vaut true :

curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&first=200&cursor=<cursor>"

L’API assure une livraison au moins une fois. Une session à la limite entre deux pages peut apparaître dans les deux pages, donc mettez à jour ou insérez les entrées selon metadata.session_id plutôt que de traiter chaque élément comme un nouvel élément. Lorsque has_next_page devient false, enregistrez le curseur renvoyé comme position de départ pour l’API point de surveillance.

Surveiller les modifications

Après la liste initiale, démarrez un point de surveillance Server-Sent Events (SSE) avec le curseur final :

curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&watch=true&cursor=<cursor>"

Le flux émet des événements MODIFIED lorsque l’entrée de file d’attente d’une session est modifiée et des événements DELETED lorsqu’elle est supprimée. Les sessions nouvellement placées en file d’attente arrivent également sous forme d’événements MODIFIED. Chaque champ SSE data contient du JSON avec cette structure :

{
  "type": "MODIFIED",
  "object": {
    "metadata": {
      "session_id": "devin-...",
      "outpost_id": "outpost_env-...",
      "created_at": 1781050000,
      "updated_at": 1781050100
    },
    "spec": {
      "kind": "new",
      "platform": "linux",
      "remote_binary_sha": null
    },
    "status": {
      "phase": "pending",
      "acceptor_id": null,
      "claim_deadline": null,
      "session_status": "pending"
    }
  },
  "cursor": "djE6MTc4MTA1MDEwMC4w"
}

Conservez le cursor de premier niveau de chaque événement après son traitement. Si la connexion se ferme, reconnectez-vous avec le dernier curseur persisté pour rejouer toute modification survenue pendant la déconnexion. La livraison en mode point de surveillance se fait elle aussi au moins une fois ; les clients doivent donc tolérer les événements en double. Les flux se terminent au bout de cinq minutes maximum ; une boucle point de surveillance avec reconnexion est donc attendue. Le filtre outpost s’applique à la fois aux requêtes de liste et de point de surveillance. Les filtres phase et acceptor_id s’appliquent uniquement aux requêtes de liste et sont ignorés lorsque watch=true ; filtrez les événements observés à l’aide des champs de l’object de chaque événement. Omettre le curseur démarre depuis le début, utilisez donc list-then-point de surveillance pour la réconciliation normale. Avant de démarrer une machine pour une session, prenez-la en charge de manière atomique afin qu’aucun autre worker ne la récupère. Transmettez un acceptor_id — une identité auto-déclarée pour votre worker :

curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"acceptor_id": "worker-1"}' \
  "https://api.devin.ai/opbeta/outposts/devins/{session_id}/claim"

Les prises en charge sont atomiques : si un autre worker a pris en charge la session en premier, vous recevez un 409. La prise en charge garantit qu’un worker sera prêt avant l’échéance de prise en charge attribuée par le serveur (status.claim_deadline) ; les prises en charge expirées retournent automatiquement dans la file d’attente. Si le provisionnement échoue, libérez la prise en charge afin que la session retourne immédiatement dans la file d’attente :

curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"acceptor_id": "worker-1"}' \
  "https://api.devin.ai/opbeta/outposts/devins/{session_id}/release"

3. Démarrer une machine et lancer le worker

Pour chaque session associée, provisionnez une VM ou un conteneur à partir de votre image. À l’intérieur, lancez le worker dans le répertoire où les dépôts de la session sont déjà extraits :

cd /path/to/repos
devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_id>

Tous les dépôts de la session doivent être extraits dans un emplacement relatif au répertoire de travail depuis lequel devin worker start est lancé :

repos

app

.git

infra

.git

Dans cet exemple, vous lanceriez devin worker start depuis repos/, et la session voit app/ et infra/ par rapport à son répertoire de travail. Options utiles :

Flag	Description
`--session`	Identifie la session à prendre en charge ; le worker se ferme lorsqu’elle se termine.
`--outpost`	Identifie l’outpost de la session à prendre en charge.
`--acceptor-id`	Utilise le même identifiant d’acceptor que la prise en charge API pour ce worker.
`--token`	Jeton d’authentification facultatif pour le worker. S’il est omis, le worker utilise `DEVIN_OUTPOSTS_TOKEN` ; si aucun des deux n’est défini, la commande renvoie une erreur.

Exemples :

devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_id> --token="<token>"
DEVIN_OUTPOSTS_TOKEN="<token>" devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_id>

Le worker se connecte au cloud de Devin, indique que la session est prête et commence à exécuter des appels d’outil.

4. Récupération directe du binaire distant

La commande devin worker start télécharge automatiquement le binaire devin-remote approprié. Si vous créez un orchestrateur personnalisé qui n’utilise pas Devin CLI, vous pouvez récupérer le binaire directement depuis :

https://static.devin.ai/devin-rs/remote/

Déterminez la version la plus récente :

# Retourne le SHA git du dernier binaire publié pour votre plateforme
curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64"

Téléchargez et vérifiez :

SHA=$(curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64")

# Télécharger le binaire
curl -fL "https://static.devin.ai/devin-rs/remote/devin-remote_${SHA}_linux_x64" \
  -o devin-remote

# Télécharger et vérifier la somme de contrôle
curl -fsSL "https://static.devin.ai/devin-rs/remote/devin-remote_${SHA}_linux_x64.sha256" \
  -o devin-remote.sha256
echo "$(cat devin-remote.sha256)  devin-remote" | sha256sum -c

chmod +x devin-remote

Plateformes disponibles :

Suffixe	OS / architecture
`linux_x64`	Linux x86_64
`macos_arm64`	macOS Apple Silicon
`windows_x64.exe`	Windows x86_64

Si l’entrée de file d’attente de la session contient un spec.remote_binary_sha, utilisez ce SHA au lieu de latest — cela verrouille la session sur une version testée spécifique.

Convention de lancement

Si votre orchestrateur lance lui-même devin-remote, faites-le démarrer comme suit :

devin-remote serve

avec les variables d’environnement suivantes :

Variable	Obligatoire	Description
`DEVIN_OUTPOST_GATEWAY_URL`	Oui	URL de base de la passerelle Outpost, par ex. `wss://outpost-gateway.devin.ai`.
`DEVIN_OUTPOST_CONNECT_TOKEN`	Oui	Jeton Bearer de connexion à la passerelle, issu de la réponse de prise en charge.
`DEVIN_OUTPOST_SESSION_ID`	Oui	ID de la session prise en charge. Les trois variables `DEVIN_OUTPOST_*` doivent être définies ensemble.
`DEVIN_REMOTE_STATE_DIR`	Fortement recommandé	Répertoire d’état propre à chaque session dans lequel l’instance distante stocke ses identifiants, jetons et fichiers d’intégration du shell. Utilisez un répertoire unique par session (par ex. `~/.devin/worker/sessions/<session_id>`, comme le fait `devin worker`). S’il n’est pas défini, l’instance distante se rabat sur une valeur par défaut partagée à l’échelle du système (`/opt/.devin` sur Linux, `~/.devin` sur macOS, `C:\ProgramData\devin` sur Windows), qui doit alors exister et être accessible en écriture — et qui expose l’état propre à chaque session entre des sessions concurrentes. Définissez toujours cette variable.
`DEVIN_CHROME_PATH`	Facultatif	Chemin vers un binaire Chrome/Chromium sur la machine pour l’outil Browser (il n’y a pas de Chrome géré par Devin sur Outposts).
`DEVIN_OUTPOST_DESKTOP`	Facultatif	Définissez cette variable sur `true` pour activer le flux du bureau (VNC). Côté instance distante, rien n’est capturé tant qu’un visualiseur ne se connecte pas ; vous pouvez donc l’activer systématiquement sans risque.

Fournissez à l’instance distante un environnement propre ne contenant que les variables ci-dessus, ainsi que les variables système de base (PATH, HOME, USER, LOGNAME, TMPDIR, LANG, TZ, et — pour la capture d’écran du flux du bureau sur Linux/X11 — DISPLAY, WAYLAND_DISPLAY, XAUTHORITY). N’exposez à l’instance distante aucune information que l’agent ne devrait pas pouvoir voir : cet environnement est hérité par le shell de l’agent. Autres attentes concernant le cycle de vie :

Répertoire de travail : lancez l’instance distante depuis le répertoire contenant les dépôts de la session (même règle que pour devin worker start).
Fin de session : lorsque la session se termine (se met en veille ou prend fin), Devin avertit l’instance distante et celle-ci quitte d’elle-même avec le code de sortie 0. Traitez une sortie propre comme la fin de la session : confirmez que status.session_status de l’entrée de file d’attente vaut suspended ou terminated (la mise à jour du statut peut avoir quelques secondes de retard ; relisez donc plusieurs fois), puis libérez la prise en charge. En solution de repli, interrogez aussi périodiquement status.session_status pendant l’exécution de l’instance distante et tuez vous-même le processus dès qu’il atteint terminated (ou que l’entrée de file d’attente disparaît).

5. Terminer la machine lorsque le worker s’arrête

Lorsque devin worker start s’arrête, la session est terminée (ou a été suspendue). Terminez la VM ou le conteneur. Si votre outpost permet la reprise, créez un snapshot de la machine avant de la terminer afin de pouvoir la restaurer si la session reprend. Votre orchestrateur peut suivre les sessions qu’il a prises en charge ainsi que leur état :

curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?phase=claimed&acceptor_id=worker-1"

Chaque entrée indique un status.session_status égal à pending, running, suspended ou terminated.

Planification sans centralisation

Vous prévoyez d’exécuter plus de ~16 coordinateurs (workers ou orchestrateurs qui surveillent un outpost et y effectuent des prises en charge) ? Contactez d’abord l’équipe en charge de votre compte — des flottes plus importantes amplifient la contention sur les prises en charge et la charge de lecture de la file, et nous voulons nous assurer que l’outpost est dimensionné en conséquence.

Vous n’avez pas besoin d’un ordonnanceur central pour exploiter une flotte. L’API de file est conçue pour que de nombreux workers indépendants puissent desservir le même outpost sans communiquer entre eux :

Les prises en charge sont le seul mécanisme de coordination. Chaque worker surveille indépendamment la file et entre en concurrence pour effectuer des prises en charge sur les sessions en attente. La prise en charge est un compare-and-swap atomique sur le serveur : un seul worker l’emporte, et tous les autres reçoivent un 409 puis passent simplement à la session en attente suivante. Perdre une course à la prise en charge fait partie du fonctionnement normal, ce n’est pas une erreur.
Chaque worker a sa propre identité. acceptor_id limite les prises en charge, les renouvellements et la récupération après redémarrage à ce worker uniquement. devin worker start en génère et en conserve un automatiquement par machine ; une flotte n’a donc besoin d’aucune configuration d’identité. Ne partagez jamais un ID d’acceptor (ni un répertoire de données de worker copié) entre plusieurs machines — des workers en conflit se voleront mutuellement leurs prises en charge.
Les défaillances se résorbent d’elles-mêmes. Si un worker s’arrête après une prise en charge, celle-ci expire à l’échéance de prise en charge et la session retourne dans la file pour qu’un autre worker la prenne en charge. Aucun suivi de l’état de santé à l’échelle de la flotte n’est nécessaire.

Autrement dit, pour passer à l’échelle, il suffit d’exécuter le worker sur davantage de machines pointant vers le même outpost : N machines desservent N sessions simultanées, et les autres restent en attente. Deux remarques opérationnelles :

Utilisez l’endpoint point de surveillance, pas des listes complètes répétées. Effectuez une liste paginée pour construire l’état initial, puis maintenez un flux de point de surveillance à partir du curseur renvoyé. Réinterroger périodiquement l’ensemble de la file depuis chaque worker passe mal à l’échelle et ajoute de la latence aux prises en charge ; le flux de point de surveillance transmet les modifications au fur et à mesure qu’elles se produisent.
Parlez-nous avant de dépasser ~16 machines sur un outpost. Les prises en charge sans coordination fonctionnent bien pour des flottes de petite taille, mais les flottes plus importantes amplifient la contention sur les prises en charge et la charge de lecture de la file. Si vous prévoyez d’exécuter plus d’environ 16 workers sur un seul outpost, contactez d’abord l’équipe en charge de votre compte afin que nous puissions nous assurer que l’outpost est dimensionné en conséquence.

Référence API

Tous les endpoints d’Outposts relèvent de https://api.devin.ai/opbeta et partagent une structure de ressource commune (metadata / spec / status). Les réponses de liste renvoient items, cursor, has_next_page et total.

Devins (`/outposts/devins`)

Endpoint	Description
`GET /outposts/devins?outpost=...&phase=pending`	Liste les sessions en attente d’un worker.
`GET /outposts/devins?outpost=...&first=...&cursor=...`	Continue une liste paginée à partir du curseur de la réponse précédente.
`GET /outposts/devins?outpost=...&watch=true&cursor=...`	Diffuse en continu les événements `MODIFIED` et `DELETED` après un curseur de liste ou de watch.
`GET /outposts/devins?phase=claimed&acceptor_id=...`	Liste les sessions prises en charge par un acceptor donné.
`GET /outposts/devins/{session_id}`	Récupère une entrée unique de la file d’attente.
`POST /outposts/devins/{session_id}/claim`	Prend en charge une session de manière atomique (`409` si elle est déjà prise en charge). Corps : `{"acceptor_id": "..."}`.
`POST /outposts/devins/{session_id}/release`	Libère la prise en charge et remet la session dans la file d’attente. Corps : `{"acceptor_id": "..."}`.

Outposts (`/outposts`)

Endpoint	Description
`GET /outposts`	Liste les Outposts associés à votre compte.
`POST /outposts`	Crée un Outpost. Corps : `{"name": "my-outpost", "platform": "linux", "description": "..."}`.
`GET /outposts/{outpost_id}`	Récupère un Outpost spécifique.
`DELETE /outposts/{outpost_id}`	Supprime un Outpost (`409` tant qu’il existe des prises en charge actives).

{
  "metadata": {
    "outpost_id": "outpost_env-...",
    "account_id": "...",
    "created_at": 1781050000
  },
  "spec": {
    "name": "my-outpost",
    "platform": "linux",
    "description": "..."
  },
  "status": {
    "queue_depth": 3,
    "active_claims": 2
  }
}

status.queue_depth et status.active_claims sont des signaux utiles pour l’autoscaling : si la file d’attente s’accumule, votre orchestrateur peut allouer davantage de machines déjà prêtes.`

Ce que les workers peuvent faire

Les sessions exécutées sur les workers Outposts sont des sessions Devin complètes : skills, Knowledge, MCP servers et secrets fonctionnent exactement comme dans Devin Cloud, via la connexion du worker. Vos dépôts, caches de build et exécutions d’outils restent dans votre environnement ; les artefacts de session, comme les captures d’écran, sont transférés vers Devin Cloud afin que vous puissiez les consulter dans la session et dans les PR.

Les sessions Outpost ont des délais de disponibilité stricts. Une fois qu’une session est prise en charge par votre orchestrateur, le worker doit se connecter avant l’échéance de la prise en charge — sinon, la prise en charge expire et les coûts fixes et horaires engagés pendant ce délai vous sont tout de même facturés.

Prise en main

Concepts essentiels

Mise en place de Devin

Travailler avec Devin

Guides produit

Intégrations

Administration

Notes de version

Fonctionnement

Prérequis

Dépendances de la machine

Démarrage rapide : créer un outpost et lancer un worker

1. Créer un jeton d’utilisateur de service

2. Créer un outpost

3. Lancer le worker

4. Démarrer une session sur l’outpost

Le processus principal

1. Déclarer un outpost

2. Interroger périodiquement l’API de la flotte pour les sessions en attente

Surveiller les modifications

3. Démarrer une machine et lancer le worker

4. Récupération directe du binaire distant

Convention de lancement

5. Terminer la machine lorsque le worker s’arrête

Planification sans centralisation

Référence API

Devins (`/outposts/devins`)

Outposts (`/outposts`)

Ce que les workers peuvent faire

​Fonctionnement

​Prérequis

​Dépendances de la machine

​Démarrage rapide : créer un outpost et lancer un worker

​1. Créer un jeton d’utilisateur de service

​2. Créer un outpost

​3. Lancer le worker

​4. Démarrer une session sur l’outpost

​Le processus principal

​1. Déclarer un outpost

​2. Interroger périodiquement l’API de la flotte pour les sessions en attente

​Surveiller les modifications

​3. Démarrer une machine et lancer le worker

​4. Récupération directe du binaire distant

​Convention de lancement

​5. Terminer la machine lorsque le worker s’arrête

​Planification sans centralisation

​Référence API

​Devins (/outposts/devins)

​Outposts (/outposts)

​Ce que les workers peuvent faire

Fonctionnement

Prérequis

Dépendances de la machine

Démarrage rapide : créer un outpost et lancer un worker

1. Créer un jeton d’utilisateur de service

2. Créer un outpost

3. Lancer le worker

4. Démarrer une session sur l’outpost

Le processus principal

1. Déclarer un outpost

2. Interroger périodiquement l’API de la flotte pour les sessions en attente

Surveiller les modifications

3. Démarrer une machine et lancer le worker

4. Récupération directe du binaire distant

Convention de lancement

5. Terminer la machine lorsque le worker s’arrête

Planification sans centralisation

Référence API

Devins (`/outposts/devins`)

Outposts (`/outposts`)

Ce que les workers peuvent faire