> ## 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
> Ejecuta sesiones de Devin en tu propia infraestructura
Outposts está en acceso anticipado. Las API y los comandos de la CLI que se describen aquí pueden cambiar.
Ponte en contacto con el equipo de tu cuenta para habilitar Outposts para tu organización.
Outposts te permite ejecutar sesiones de Devin dentro de la infraestructura que controlas: tus propias VM, contenedores, clústeres de Kubernetes o incluso un Mac Mini debajo de tu mesa. El bucle del agente de Devin (inferencia y planificación) sigue ejecutándose en la nube de Devin, mientras que toda la ejecución de comandos, la edición de archivos y el acceso a los repositorios se realizan en máquinas que tú operas.
Usa Outposts cuando necesites:
* Que las sesiones se ejecuten dentro de tu red, junto a servicios internos, registries y secretos
* Perfiles de hardware personalizados (p. ej., GPU, máquinas con mucha memoria o imágenes de SO específicas)
* Infraestructura existente de máquinas de desarrollo, VM o Kubernetes para alojar las cargas de trabajo de Devin
* Controles empresariales sobre el acceso a la red, los resultados de compilación y la supervisión
## Cómo funciona
Outposts tiene dos capas:
1. **El worker (p. ej. `devin worker start`)** — un binario que ejecutas en una máquina para atender una única sesión en cola. Abre una conexión saliente a la nube de Devin y ejecuta localmente las llamadas a herramientas de la sesión. Cognition proporciona este binario; nunca tendrás que implementarlo. [Devin CLI](/es/work-with-devin/devin-cli) contiene la lógica para obtener y ejecutar este binario.
2. **El orquestador** — software que supervisa la API de la flota para detectar sesiones a la espera de workers, aprovisiona una VM o un contenedor para cada una, e inicia el worker dentro de él. Proporcionamos algunas implementaciones de referencia para plataformas comunes (como Kubernetes), pero puedes adaptarlas libremente (¡son de código abierto!) o escribir la tuya.
Los workers solo necesitan acceso HTTPS **saliente**. No se requieren puertos de entrada, IP públicas ni túneles VPN.
Cuando un usuario inicia una sesión en Devin Cloud y selecciona uno de tus outposts registrados, la sesión se coloca en la cola de ese outpost. Tu orquestador la reclama, crea una máquina y ejecuta el worker. Cuando la sesión termina, el worker se cierra y tu orquestador elimina la máquina.
## Requisitos previos
* Una organización con Outposts habilitado
* Un [token de API v3](/es/api-reference/v3/overview) con los ámbitos de Outposts adecuados:
* `account.outposts.orchestrator` para los orquestadores que administran outposts (implica el ámbito de la máquina)
* `account.outposts.machine` para los workers que leen la cola y reclaman y liberan sesiones
* Una imagen de la máquina (VM o contenedor) con:
* Devin CLI instalado
* Las [dependencias de la máquina](#machine-dependencies) que aparecen a continuación
* Tus repositorios clonados, con los remotos configurados
* Acceso a las herramientas de compilación, los registry de paquetes, los secretos y los servicios internos que tus sesiones necesitan
### Dependencias de la máquina
Las sesiones se ejecutan directamente en tu máquina, por lo que el worker depende de las herramientas que instales allí.
**Obligatorio**
| Dependencia | Se usa para |
| -------------------- | ------------------------------------------------------- |
| `git` (en el `PATH`) | Clonar y realizar todas las operaciones del repositorio |
**Opcional** — instala estas dependencias para habilitar funciones específicas:
| Dependencia | Función |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ffmpeg` (en el `PATH`) | Las funciones de grabación de pantalla de Devin. Sin esto, las sesiones no pueden grabar la pantalla. |
| Chrome o Chromium | Las funciones de Browser y de uso del equipo. De forma predeterminada, el worker busca Chrome en las ubicaciones de instalación estándar; para usar una anulación, configura `DEVIN_CHROME_PATH` en el entorno del worker con la ruta absoluta del binario (p. ej. `DEVIN_CHROME_PATH=/usr/bin/google-chrome`). Sin esto, las herramientas del navegador no estarán disponibles. |
| `sudo` sin contraseña | Permite que Devin instale el software que necesita durante una sesión (p. ej., herramientas de compilación o paquetes del sistema que falten). Concede esto solo cuando la máquina esté dedicada a Devin y se recicle después de cada sesión; nunca en máquinas compartidas o de larga duración. |
## Inicio rápido: crear un outpost y ejecutar un worker
En este tutorial, crearás un outpost y lo pondrás en servicio desde una sola máquina con `devin worker start`, sin necesidad de un orquestador. Es la forma más rápida de probar Outposts en un entorno de desarrollo, y es el mismo comando de worker que ejecuta un orquestador a escala.
### 1. Crear un token de usuario de servicio
El worker (y cualquier orquestador) se autentica ante la API de Outposts con un [token de API v3](/es/api-reference/v3/overview) perteneciente a un **usuario de servicio**; los permisos del rol que se indican a continuación conceden al token sus ámbitos de Outposts (`UseOutpostsMachine` → `account.outposts.machine`, `ManageOutpostsOrchestrator` → `account.outposts.orchestrator`). En la web app de Devin:
1. **Crea un rol** con acceso a Outposts. En **Settings → Roles**, agrega un rol de Enterprise y habilita **Usar máquina de outpost** (`UseOutpostsMachine`) en *Permisos de outpost*. Habilita también **Gestionar outposts** (`ManageOutpostsOrchestrator`) si este usuario de servicio va a crear o eliminar outposts.
2. **Aprovisiona el usuario de servicio.** En **Settings → Devin API → Usuarios de servicio**, haz clic en **Aprovisionar usuario de servicio**, asígnale un nombre (p. ej., `outposts-worker`), asígnale el rol del paso 1 y establece una fecha de vencimiento.
3. **Copia el token.** El token `cog_...` se muestra **solo una vez** al crearlo; cópialo ahora, porque no se podrá recuperar más adelante.
Expórtalo para los comandos a continuación:
```bash theme={null}
export DEVIN_OUTPOSTS_TOKEN="cog_..."
```
### 2. Crear un outpost
Un outpost es una cola con nombre para sesiones atendida por tu infraestructura. Crea uno desde cualquier máquina con [Devin CLI](/es/cli) instalado:
```bash theme={null}
devin worker outpost create my-outpost --platform linux --description "Dev boxes in our VPC"
```
El comando muestra el ID del nuevo outpost (`outpost_env-...`) — anótalo para el siguiente paso. También puedes crear outposts en la aplicación web, en **Settings → Outposts**, o mediante la [API de outposts](#outposts-outposts).
Una vez creado, el outpost aparece como una opción de máquina en Devin Cloud (junto con Ubuntu, Windows, etc.) al iniciar una sesión.
### 3. Inicia el worker
En la máquina que se usará para las sesiones, instala el [Devin CLI](/es/cli) y las [dependencias de la máquina](#machine-dependencies), y luego inicia el worker desde el directorio que contiene tus repositorios clonados:
```bash theme={null}
cd /path/to/repos
devin worker start --outpost=
```
El worker sondea la cola del outpost, reclama la primera sesión pendiente, descarga el binario `devin-remote` adecuado y atiende la sesión. Cuando la sesión termina, vuelve a la cola y espera la siguiente. Usa `--once` para salir después de atender una sola sesión, o `--session=` para reclamar y atender una sesión específica.
Si `--token` y `DEVIN_OUTPOSTS_TOKEN` no están configurados, el comando devuelve un error. Si se omite `--outpost` en un terminal interactivo, el worker te pide que elijas entre los outposts de tu cuenta.
### 4. Inicia una sesión en el outpost
En Devin Cloud, inicia una nueva sesión y selecciona tu outpost como máquina. La sesión queda en cola, tu worker la reclama y la ejecución comienza en tu máquina. Para atender más sesiones de forma concurrente, ejecuta el worker en más máquinas que apunten al mismo outpost; consulta la [planificación descentralizada](#centralization-free-scheduling).
¿Lo ejecutas en Kubernetes? El operador de código abierto
[devin-outpost-k8s](https://github.com/CognitionAI/devin-outpost-k8s)
se instala mediante Helm y ejecuta workers para un outpost en cualquier
clúster certificado (GKE, EKS, ...). Desde un clon de ese repositorio:
```bash theme={null}
helm install outposts charts/devin-outposts-k8s \
--set defaultPool.enabled=true \
--set defaultPool.poolId= \
--set defaultPool.token.value="$DEVIN_OUTPOSTS_TOKEN"
```
## El flujo principal
### 1. Registrar un outpost
Un outpost es una cola de sesiones con nombre atendida por muchos workers en tu infraestructura (por ejemplo, `rhel`, `gpu-h200` o `my-outpost`). Crea uno con `devin worker outpost create`:
```bash theme={null}
devin worker outpost create --platform --description "..."
```
Una vez registrado, el outpost aparece como una opción de máquina en Devin Cloud (junto con Ubuntu, Windows, etc.) al iniciar una sesión. Las sesiones que lo tienen como destino esperan en su cola hasta que un worker las reclame.
En la API de la flota, los outposts se representan como recursos `outposts`, dentro del ámbito de
tu cuenta (compartidos entre todas sus organizaciones).
### 2. Sondea la API de la flota para obtener las sesiones en espera
Tu orquestador lista las sesiones pendientes de los Outposts que atiende:
```bash theme={null}
curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?outpost=&phase=pending"
```
La respuesta de listar incluye las sesiones en cola en `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
}
```
Usa el cursor de la respuesta para paginar sin tener que reconciliar repetidamente
toda la cola. Establece `first` con el tamaño de página (hasta 200) y luego pasa
el `cursor` de cada respuesta a la siguiente solicitud mientras `has_next_page` sea `true`:
```bash theme={null}
curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?outpost=&first=200&cursor="
```
La API ofrece entrega al menos una vez. Una sesión en el límite entre páginas puede
aparecer en ambas, así que haz upsert de las entradas por `metadata.session_id` en lugar de
tratar cada elemento como nuevo. Cuando `has_next_page` pase a ser `false`, guarda el
cursor devuelto como la posición inicial para la API de watch.
#### Watch los cambios
Después del listado inicial, inicia una watch de Server-Sent Events (SSE) con el cursor final:
```bash theme={null}
curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?outpost=&watch=true&cursor="
```
La transmisión envía eventos `MODIFIED` cuando cambia la entrada de cola de una sesión y
eventos `DELETED` cuando se elimina. Las sesiones recién encoladas también llegan como
eventos `MODIFIED`. Cada campo `data` de SSE contiene JSON con esta forma:
```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"
}
```
Guarda el `cursor` de nivel superior de cada evento después de procesarlo. Si la conexión
se cierra, vuelve a conectarte con el último cursor guardado para reproducir cualquier cambio que
haya ocurrido mientras estabas desconectado. La entrega de watch también es de al menos una vez, por lo que los clientes
deben tolerar eventos duplicados. Los streams terminan al cabo de un máximo de cinco minutos; se
espera un bucle de watch con reconexión.
El filtro `outpost` se aplica tanto a las solicitudes de listar como a las de watch. Los filtros `phase` y
`acceptor_id` se aplican solo a las solicitudes de listar y se ignoran cuando
`watch=true`; filtra los eventos recibidos por watch usando los campos del `object` de cada evento.
Si omites el cursor, se empieza desde el principio, así que usa listar y luego watch para la
reconciliación normal.
Antes de iniciar una máquina para una sesión, reclámala de forma atómica para que ningún otro worker la tome. Proporciona un `acceptor_id`: una identidad autodeclarada para tu 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"
```
La reclamación es atómica: si otro worker reclamó la sesión antes, recibirás un `409`. Reclamarla garantiza que un worker estará listo dentro del plazo de reclamación asignado por el servidor (`status.claim_deadline`); las reclamaciones vencidas vuelven a la cola automáticamente. Si el aprovisionamiento falla, libera la reclamación para que la sesión vuelva a la cola de inmediato:
```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. Crear una máquina y ejecutar el worker
Para cada sesión reclamada, aprovisiona una VM o un contenedor a partir de tu imagen. Dentro de ella, ejecuta el worker desde el directorio donde los repositorios de la sesión ya están descargados:
```bash theme={null}
cd /path/to/repos
devin worker start --session= --outpost= --acceptor-id=
```
Todos los repositorios de la sesión deben estar ubicados en relación con el directorio de trabajo desde el que se ejecuta `devin worker start`:
En este ejemplo, ejecutarías `devin worker start` desde `repos/`, y la sesión ve `app/` e `infra/` en relación con su directorio de trabajo.
Flags útiles:
| Flag | Descripción |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `--session` | Identifica la sesión que se atenderá; el worker finaliza cuando termina. |
| `--outpost` | Identifica el outpost de la sesión que se atenderá. |
| `--acceptor-id` | Usa el mismo ID de acceptor que la reclamación de la API para este worker. |
| `--token` | Token de autenticación opcional para el worker. Si se omite, el worker usa `DEVIN_OUTPOSTS_TOKEN`; si no se configura ninguno, el comando devuelve un error. |
Ejemplos:
```bash theme={null}
devin worker start --session= --outpost= --acceptor-id= --token=""
DEVIN_OUTPOSTS_TOKEN="" devin worker start --session= --outpost= --acceptor-id=
```
El worker establece una conexión saliente con la nube de Devin, marca la sesión como lista y comienza a ejecutar llamadas a herramientas.
### 4. Descargar el binario remoto directamente
El comando `devin worker start` descarga automáticamente el binario `devin-remote` correcto. Si estás creando un orquestador personalizado que no usa Devin CLI, puedes descargar el binario directamente desde:
```
https://static.devin.ai/devin-rs/remote/
```
**Determina cuál es la versión más reciente:**
```bash theme={null}
# Devuelve el git SHA del binario publicado más reciente para tu plataforma
curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64"
```
**Descarga y verifica:**
```bash theme={null}
SHA=$(curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64")
# Descargar el binario
curl -fL "https://static.devin.ai/devin-rs/remote/devin-remote_${SHA}_linux_x64" \
-o devin-remote
# Descargar y verificar el checksum
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
```
**Plataformas disponibles:**
| Sufijo | SO / Arquitectura |
| ----------------- | ------------------- |
| `linux_x64` | Linux x86\_64 |
| `macos_arm64` | macOS Apple Silicon |
| `windows_x64.exe` | Windows x86\_64 |
Si la entrada en la cola de la sesión incluye un `spec.remote_binary_sha`, usa ese SHA en lugar de `latest` — esto fija la sesión a una versión específica ya probada.
#### Contrato para crear
Si tu orquestador inicia `devin-remote` por sí mismo, créalo así:
```bash theme={null}
devin-remote serve
```
con las siguientes variables de entorno:
| Variable | Requerido | Descripción |
| ----------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `DEVIN_OUTPOST_GATEWAY_URL` | Sí | URL base de la puerta de enlace de Outpost, p. ej. `wss://outpost-gateway.devin.ai`. |
| `DEVIN_OUTPOST_CONNECT_TOKEN` | Sí | Token Bearer de conexión para la puerta de enlace, obtenido de la respuesta de reclamación. |
| `DEVIN_OUTPOST_SESSION_ID` | Sí | El ID de sesión que se está atendiendo. Las tres variables `DEVIN_OUTPOST_*` deben configurarse juntas. |
| `DEVIN_REMOTE_STATE_DIR` | Muy recomendable | Directorio de estado por sesión donde el proceso remoto almacena sus credenciales, tokens y archivos de integración del shell. Usa un directorio único por sesión (p. ej. `~/.devin/worker/sessions/`, que es lo que usa `devin worker`). Si no se configura, el proceso remoto recurre a un valor predeterminado compartido para todo el sistema (`/opt/.devin` en Linux, `~/.devin` en macOS, `C:\ProgramData\devin` en Windows), que en ese caso debe existir y tener permisos de escritura, y que mezcla el estado de cada sesión entre sesiones concurrentes. Configura esto siempre. |
| `DEVIN_CHROME_PATH` | Opcional | Ruta a un binario de Chrome/Chromium en la máquina para la herramienta Browser (no hay un Chrome gestionado por Devin en Outposts). |
| `DEVIN_OUTPOST_DESKTOP` | Opcional | Establécelo en `true` para habilitar el stream del escritorio (VNC). Se activa bajo demanda en el lado remoto — no se captura nada hasta que se conecta un visor —, así que es seguro habilitarlo incondicionalmente. |
Proporciona al proceso remoto un entorno limpio que contenga solo las variables anteriores más variables básicas del sistema (`PATH`, `HOME`, `USER`, `LOGNAME`, `TMPDIR`, `LANG`, `TZ` y — para la captura de pantalla del stream del escritorio en Linux/X11 — `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`). No expongas al proceso remoto nada que el agente no deba poder ver: el shell del agente lo hereda.
Expectativas adicionales del ciclo de vida:
* **Directorio de trabajo**: inicia el proceso remoto desde el directorio que contiene los repositorios de la sesión (la misma regla que `devin worker start`).
* **Fin de la sesión**: cuando la sesión termina (se duerme o finaliza), Devin notifica al proceso remoto y este sale por sí solo con código 0. Considera una salida limpia como el final de la sesión: confirma que `status.session_status` de la entrada de cola sea `suspended` o `terminated` (la actualización del estado puede retrasarse unos segundos respecto a la salida, así que vuelve a consultarlo varias veces), y luego libera la reclamación. Como alternativa de respaldo, también sondea `status.session_status` mientras el proceso remoto se ejecuta y finaliza tú mismo el proceso una vez que llegue a `terminated` (o desaparezca la entrada de cola).
### 5. Termina la máquina cuando el worker finalice
Cuando `devin worker start` finaliza, la sesión termina (o se ha suspendido). Termina la VM o el contenedor. Si tu outpost se puede reanudar, crea una instantánea de la máquina antes de terminarla para poder restaurarla si la sesión se reanuda.
Tu orquestador puede hacer un seguimiento de las sesiones que ha reclamado y de sus estados:
```bash theme={null}
curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?phase=claimed&acceptor_id=worker-1"
```
Cada entrada muestra un `status.session_status` de `pending`, `running`, `suspended` o `terminated`.
## Programación sin un coordinador central
¿Planeas ejecutar más de \~16 coordinadores (workers u orquestadores
que observan y reclaman desde un outpost)? Ponte en contacto primero con tu equipo de cuenta: las flotas más grandes amplifican la
contención de reclamaciones y la carga de lectura de la cola, y queremos
asegurarnos de que el outpost esté aprovisionado para ello.
No necesitas un coordinador central para ejecutar una flota. La API de la cola está diseñada para que muchos workers independientes puedan atender el mismo outpost sin comunicarse entre sí:
* **Las reclamaciones son el único mecanismo de coordinación.** Cada worker observa la cola de forma independiente y compite por reclamar las sesiones pendientes. La reclamación es una operación atómica de compare-and-swap en el server: exactamente un worker gana, y todos los demás reciben un `409` y simplemente pasan a la siguiente sesión pendiente. Perder una carrera por una reclamación es parte del funcionamiento normal, no un error.
* **Cada worker tiene su propia identidad.** El `acceptor_id` limita las reclamaciones, renovaciones y la recuperación tras reinicio de un worker únicamente a ese worker. `devin worker start` genera y conserva uno automáticamente por máquina, por lo que una flota no necesita configuración de identidad. Nunca compartas un ID de acceptor (ni un directorio de datos de worker copiado) entre máquinas: los workers que entren en conflicto se quitarán las reclamaciones entre sí.
* **Los fallos se recuperan solos.** Si un worker deja de funcionar después de reclamar, su reclamación vence al llegar el plazo de reclamación y la sesión vuelve a la cola para que otro worker la recoja. No se requiere supervisión del estado a nivel de flota.
Esto significa que escalar horizontalmente solo consiste en ejecutar el worker en más máquinas apuntando al mismo outpost: N máquinas atienden N sesiones concurrentes, y el resto esperan como pendientes.
Dos notas operativas:
* **Usa el endpoint watch, no listas completas repetidas.** Haz una lista paginada para construir el estado inicial y luego mantén un [flujo de watch](#watch-for-changes) desde el cursor devuelto. Volver a sondear toda la cola desde cada worker no escala bien y agrega latencia a las reclamaciones; el flujo de watch entrega los cambios a medida que ocurren.
* **Habla con nosotros antes de superar \~16 máquinas en un outpost.** La reclamación sin coordinación funciona bien con flotas pequeñas, pero las flotas más grandes amplifican la contención de reclamaciones y la carga de lectura de la cola. Si planeas ejecutar más de unos 16 workers contra un único outpost, ponte en contacto primero con tu equipo de cuenta para que podamos asegurarnos de que el outpost esté aprovisionado para ello.
## Referencia de la API
Todos los endpoints de Outposts están bajo `https://api.devin.ai/opbeta` y comparten una estructura de recurso común (`metadata` / `spec` / `status`). Las respuestas de listado devuelven `items`, `cursor`, `has_next_page` y `total`.
### Devins (`/outposts/devins`)
| Endpoint | Descripción |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| `GET /outposts/devins?outpost=...&phase=pending` | Listar las sesiones en espera de un worker. |
| `GET /outposts/devins?outpost=...&first=...&cursor=...` | Continuar una lista paginada desde el cursor de una respuesta anterior. |
| `GET /outposts/devins?outpost=...&watch=true&cursor=...` | Transmitir eventos `MODIFIED` y `DELETED` después de un cursor de lista o de watch. |
| `GET /outposts/devins?phase=claimed&acceptor_id=...` | Listar las sesiones reclamadas por un acceptor específico. |
| `GET /outposts/devins/{session_id}` | Obtener un único elemento de la cola. |
| `POST /outposts/devins/{session_id}/claim` | Reclamar atómicamente una sesión (`409` si ya fue reclamada). Cuerpo: `{"acceptor_id": "..."}`. |
| `POST /outposts/devins/{session_id}/release` | Liberar una reclamación y devolver la sesión a la cola. Cuerpo: `{"acceptor_id": "..."}`. |
### Outposts (`/outposts`)
| Endpoint | Descripción |
| ------------------------------- | --------------------------------------------------------------------------------------------- |
| `GET /outposts` | Lista los outposts de tu cuenta. |
| `POST /outposts` | Crea un outpost. Cuerpo: `{"name": "my-outpost", "platform": "linux", "description": "..."}`. |
| `GET /outposts/{outpost_id}` | Obtiene un outpost. |
| `DELETE /outposts/{outpost_id}` | Elimina un outpost (`409` mientras tenga reclamaciones activas). |
```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` y `status.active_claims` son señales útiles para el escalado automático: si la cola empieza a acumularse, tu orquestador puede aprovisionar más máquinas precalentadas.
## Lo que pueden hacer los workers
Las sesiones que se ejecutan en los workers de Outposts son sesiones de Devin con todas las funciones: skills, Knowledge, servidores MCP y secretos funcionan igual que en Devin Cloud, a través de la conexión del worker. Tus repositorios, cachés de compilación y la ejecución de herramientas permanecen en tu Environment; los artefactos de la sesión, como las capturas de pantalla, se suben a Devin Cloud para que puedas verlos en la sesión y en las PR.
Las sesiones de Outpost tienen tiempos de espera de preparación estrictos. Después de que tu orquestador
reclama una sesión, el worker debe conectarse antes de que venza el plazo de la reclamación;
de lo contrario, la reclamación caduca y se te siguen facturando los costos fijos y por hora
generados durante la ventana de tiempo de espera.