> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Outposts
> Exécutez des sessions Devin sur votre propre infrastructure
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 :
1. **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](/fr/work-with-devin/devin-cli) contient la logique permettant de récupérer et d’exécuter ce binaire.
2. **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](/fr/api-reference/v3/overview) 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](#machine-dependencies) 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](/fr/api-reference/v3/overview) 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 :
1. **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.
2. **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.
3. **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 :
```bash theme={null}
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](/fr/cli) est installé :
```bash theme={null}
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](#outposts-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](/fr/cli) et les [dépendances de la machine](#machine-dependencies), puis démarrez le worker depuis le répertoire contenant vos dépôts clonés :
```bash theme={null}
cd /path/to/repos
devin worker start --outpost=
```
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=` 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](#centralization-free-scheduling).
Vous utilisez Kubernetes ? L’opérateur open source
[devin-outpost-k8s](https://github.com/CognitionAI/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 :
```bash theme={null}
helm install outposts charts/devin-outposts-k8s \
--set defaultPool.enabled=true \
--set defaultPool.poolId= \
--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` :
```bash theme={null}
devin worker outpost create --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 :
```bash theme={null}
curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?outpost=&phase=pending"
```
La réponse de liste place les sessions en file d’attente dans `items` :
```json theme={null}
{
"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` :
```bash theme={null}
curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?outpost=&first=200&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 :
```bash theme={null}
curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?outpost=&watch=true&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 :
```json theme={null}
{
"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 :
```bash theme={null}
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 :
```bash theme={null}
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 :
```bash theme={null}
cd /path/to/repos
devin worker start --session= --outpost= --acceptor-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é :
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 :
```bash theme={null}
devin worker start --session= --outpost= --acceptor-id= --token=""
DEVIN_OUTPOSTS_TOKEN="" devin worker start --session= --outpost= --acceptor-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 :**
```bash theme={null}
# 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 :**
```bash theme={null}
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 :
```bash theme={null}
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/`, 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 :
```bash theme={null}
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](#watch-for-changes) à 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). |
```json theme={null}
{
"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.