Saltar al contenido principal
Un orquestador observa la API de Outposts en busca de sesiones que esperan en un outpost, aprovisiona una VM o un contenedor para cada una e inicia el worker dentro de él. Esta página describe el bucle de orquestación: sondear la cola, reclamar sesiones, ejecutar workers y desaprovisionar máquinas. Si solo quieres servir sesiones desde una máquina que ya tienes, empieza con la guía de inicio rápido: no se requiere ningún orquestador. Si ejecutas en una plataforma compatible, es posible que una integración ya implemente este bucle por ti. Para ver toda la API y la CLI, consulta la referencia.
¿Ejecutas en Kubernetes? devin-outpost-k8s es un operador de código abierto que implementa este bucle por ti: vigila la cola, reclama las sesiones pendientes y ejecuta cada una como un pod de worker en cualquier clúster certificado (GKE, EKS, …). Instálalo con su chart de Helm en lugar de crear tu propio orquestador.

​
El flujo principal

​
1. Registrar un outpost

Un outpost es una cola de sesiones con nombre atendida por varios 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 fleet API, los outposts se representan como recursos outposts, dentro del ámbito de tu cuenta (compartidos entre todas las organizaciones de la cuenta). Consulta los endpoints de outposts.

​
2. Vigila la fleet API para detectar sesiones en espera

Tu orquestador lista las sesiones pendientes de los outposts que atiende:
Luego mantiene su vista actualizada con un seguimiento mediante Server-Sent Events (SSE), reanudándolo desde el cursor final de la lista:
Este es el patrón estándar de Kubernetes de listar y luego monitorizar: recorre la lista por páginas con el cursor de la respuesta y, a continuación, inicia una monitorización desde donde terminó la lista, guardando el cursor de cada evento para que puedas reconectarte sin perder cambios. La entrega es de al menos una vez, así que haz upsert por metadata.session_id y tolera duplicados. Consulta List queued sessions y Watch for changes para conocer los parámetros de consulta, los formatos de respuesta y la semántica completa de la paginación.

​
3. Reclamar antes del aprovisionamiento

Antes de iniciar una máquina para una sesión, reclámala de forma atómica para evitar que otro worker la recoja. Proporciona un acceptor_id, una identidad autodeclarada de tu worker:
La operación de reclamar es atómica: si otro worker reclamó la sesión primero, obtendrás un 409. Reclamar 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.

​
4. Crear una máquina y ejecutar el worker

Para cada sesión reclamada, provisiona una VM o un contenedor usando tu imagen. Dentro, ejecuta el worker desde el directorio donde ya están clonados los repositorios de la sesión:
Pasa el mismo --acceptor-id que usaste al reclamar mediante la API y proporciona el token con --token o DEVIN_OUTPOSTS_TOKEN (consulta la lista completa de opciones). El worker se conecta a la nube de Devin, marca la sesión como preparada y empieza a ejecutar invocaciones de herramientas.

​
5. Termina la máquina cuando el worker finalice

Cuando devin worker start finaliza, la sesión ha terminado (o se ha suspendido). Termina la VM o el contenedor. Si tu outpost permite reanudar sesiones, crea una instantánea de la máquina antes de terminarla para poder restaurarla si la sesión se reanuda. Tu orquestador puede hacer 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 coordinador central

¿Planeas ejecutar más de ~16 coordinadores (workers u orquestadores que observan y reclaman desde un outpost)? Ponte primero en contacto con tu equipo de cuentas: las flotas más grandes aumentan la contención al reclamar 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 cada perdedor recibe un 409 y simplemente pasa a la siguiente sesión pendiente. Perder una carrera por una reclamación es 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 en conflicto se robarán las reclamaciones entre sí.
  • Los fallos se recuperan solos. Si un worker deja de funcionar después de reclamar, su reclamación expira al llegar a la fecha límite de reclamación y la sesión vuelve a la cola para que otro worker la recoja. No hace falta supervisar el estado de toda la flota.
Esto significa que escalar horizontalmente solo consiste en ejecutar el worker en más máquinas que apunten al mismo outpost: N máquinas atienden N sesiones concurrentes, y el resto quedan en espera como pendientes.

​
Creación de un orquestador personalizado

Todo lo que hace devin worker start está disponible directamente a través de la fleet API, así que puedes sustituir por completo la CLI: descarga el binario devin-remote de la distribución estática de Devin e inícialo tú mismo con el entorno documentado. Consulta Distribución del binario remoto y el contrato de creación en la referencia.