Pular para o conteúdo principal
Um orquestrador monitora a API do Outposts em busca de sessões aguardando em um outpost, provisiona uma VM ou contêiner para cada uma e inicia o worker dentro dele. Esta página descreve o loop de orquestração: consultar a fila, reivindicar sessões, executar workers e encerrar máquinas. Se você só quer atender sessões a partir de uma máquina que já tem, comece pelo guia de início rápido — nenhum orquestrador é necessário. Se você usa uma plataforma compatível, uma integração talvez já implemente esse loop para você. Para ver toda a API e a CLI, consulte a referência.
Vai executar no Kubernetes? devin-outpost-k8s é um operador de código aberto que implementa esse loop para você: ele monitora a fila, reivindica sessões pendentes e executa cada uma como um pod de worker em qualquer cluster certificado (GKE, EKS, …). Instale-o com seu chart Helm em vez de criar seu próprio orquestrador.

​
O fluxo principal

​
1. Registrar um outpost

Um outpost é uma fila nomeada de sessões processadas por muitos workers em sua infraestrutura (por exemplo, rhel, gpu-h200 ou my-outpost). Crie um com devin worker outpost create:
Depois de registrado, o outpost aparece como uma opção de máquina no Devin Cloud (junto com Ubuntu, Windows etc.) ao iniciar uma sessão. As sessões destinadas a ele ficam na fila até que um worker as reivindique.
Na fleet API, os outposts são representados como recursos outposts, com escopo na sua conta (compartilhados entre todas as suas organizações). Consulte os endpoints de outposts.

​
2. Monitore a fleet API para identificar sessões em espera

Seu orquestrador lista as sessões pendentes dos outposts aos quais atende:
Em seguida, ele mantém sua visualização atualizada com um monitoramento por Server-Sent Events (SSE), retomando a partir do cursor final da lista:
Este é o padrão do Kubernetes de listar e depois monitorar: percorra a lista com o cursor da resposta e, em seguida, inicie um watch a partir de onde a listagem terminou, persistindo o cursor de cada evento para que você possa se reconectar sem perder alterações. A entrega é do tipo at-least-once, então faça upsert por metadata.session_id e tolere duplicatas. Consulte List queued sessions e Watch for changes para ver os parâmetros de consulta, os formatos de resposta e a semântica completa da paginação.

​
3. Reivindique antes do provisionamento

Antes de iniciar uma máquina para uma sessão, reivindique-a atomicamente para que nenhum outro worker a pegue. Passe um acceptor_id — uma identidade informada pelo próprio worker:
As reivindicações são atômicas: se outro worker reivindicou a sessão primeiro, você recebe um 409. Ao reivindicar, você garante que um worker estará pronto dentro do prazo de reivindicação atribuído pelo servidor (status.claim_deadline); reivindicações expiradas retornam automaticamente à fila. Se o provisionamento falhar, libere a reivindicação para que a sessão retorne imediatamente à fila.

​
4. Inicie uma máquina e execute o worker

Para cada sessão reivindicada, provisione uma VM ou contêiner a partir da sua imagem. Dentro dela, execute o worker no diretório em que os repositórios da sessão já estão clonados:
Passe o mesmo --acceptor-id que você usou na reivindicação via API e informe o token com --token ou DEVIN_OUTPOSTS_TOKEN (consulte a lista completa de flags). O worker se conecta à nuvem do Devin, marca a sessão como pronta e começa a executar chamadas de ferramenta.

​
5. Encerre a máquina quando o worker for encerrado

Quando devin worker start é encerrado, a sessão terminou (ou foi suspensa). Encerre a VM ou o contêiner. Se o seu outpost permitir retomada, crie um snapshot da máquina antes de encerrá-la para poder restaurá-la se a sessão for retomada. Seu orquestrador pode acompanhar as sessões que reivindicou e seus estados:
Cada entrada informa o status.session_status como pending, running, suspended ou terminated.

​
Agendamento descentralizado

Está planejando executar mais de ~16 coordenadores (workers ou orquestradores monitorando e reivindicando sessões de um outpost)? Entre em contato com a equipe responsável pela sua conta primeiro — frotas maiores ampliam a contenção por reivindicações e a carga de leitura da fila, e queremos garantir que o outpost esteja provisionado para isso.
Você não precisa de um agendador central para operar uma frota. A API da fila foi projetada para que muitos workers independentes possam atender o mesmo outpost sem se comunicar entre si:
  • As reivindicações são o único mecanismo de coordenação. Cada worker monitora a fila de forma independente e disputa a reivindicação de sessões pendentes. A reivindicação é uma operação atômica de compare-and-swap no servidor: exatamente um worker vence, e todos os demais recebem um 409 e simplesmente passam para a próxima sessão pendente. Perder uma disputa por uma reivindicação faz parte da operação normal, não é um erro.
  • Cada worker tem sua própria identidade. O acceptor_id vincula as reivindicações, renovações e a recuperação após reinicialização exclusivamente àquele worker. devin worker start gera e persiste um automaticamente por máquina, então uma frota não precisa de configuração de identidade. Nunca compartilhe um acceptor ID (ou um diretório de dados de worker copiado) entre máquinas — workers com IDs conflitantes roubarão as reivindicações uns dos outros.
  • As falhas se recuperam automaticamente. Se um worker morrer depois de reivindicar uma sessão, sua reivindicação expira ao fim do prazo de reivindicação e a sessão retorna à fila para que outro worker a assuma. Nenhum monitoramento de integridade em nível de frota é necessário.
Isso significa que escalar horizontalmente é simplesmente executar o worker em mais máquinas apontadas para o mesmo outpost: N máquinas atendem N sessões simultâneas, e o restante fica aguardando como pendente.

​
Criando um orquestrador personalizado

Tudo o que devin worker start faz está disponível diretamente por meio da fleet API, então você pode substituir totalmente a CLI: obtenha o binário devin-remote na distribuição estática do Devin e inicie-o por conta própria usando o ambiente documentado. Consulte Distribuição do binário remoto e o contrato de spawn na referência.