Saltar al contenido principal
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 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 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 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 Opcional — instala estas dependencias para habilitar funciones específicas:

​
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 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:

​
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 instalado:
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. 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 y las dependencias de la máquina, y luego inicia el worker desde el directorio que contiene tus repositorios clonados:
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=<session_id> 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.
¿Lo ejecutas en Kubernetes? El operador de código abierto 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:

​
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:
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:
La respuesta de listar incluye las sesiones en cola en items:
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:
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:
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:
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:
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:

​
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:
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:
repos
app
.git
infra
.git
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: Ejemplos:
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:
Determina cuál es la versión más reciente:
Descarga y verifica:
Plataformas disponibles: 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í:
con las siguientes variables de entorno: 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:
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 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)

​
Outposts (/outposts)

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.