Vai executar no Kubernetes? O 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
rhel, gpu-h200 ou my-outpost). Crie um com devin worker outpost create:
Na fleet API, os outposts são representados como recursos
outposts, no escopo da
sua conta (compartilhados entre todas as suas organizações). Consulte os
endpoints de outposts.2. Monitore a fleet API em busca de sessões em espera
metadata.session_id e tolere duplicatas. Consulte Listar sessões na fila e Acompanhar mudanças para ver os parâmetros de consulta, os formatos de resposta e a semântica completa da paginação.
3. Reivindique antes do provisionamento
acceptor_id — uma identidade informada pelo próprio worker:
409. Ao reivindicar, você garante que um worker estará pronto até o prazo de reivindicação atribuído pelo servidor (status.claim_deadline); reivindicações expiradas retornam automaticamente à fila. Se o provisioning falhar, libere a reivindicação para que a sessão retorne à fila imediatamente.
4. Inicie uma máquina e execute o worker
--acceptor-id que você usou na reivindicação via API e forneça o token por --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 finalizado
devin worker start é encerrado, a sessão termina (ou é suspensa). Encerre a VM ou o contêiner. Se o seu outpost for retomável, 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:
status.session_status de pending, running, suspended ou terminated.
Agendamento sem centralização
Planeja executar mais de ~16 coordenadores (workers ou orquestradores
monitorando e reivindicando de um outpost)? Entre em contato primeiro com a equipe responsável pela sua conta — frotas maiores ampliam a contenção de reivindicações e a carga de leitura da fila, e queremos
garantir que o outpost esteja provisionado para isso.
- 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 é um compare-and-swap atômico no servidor: exatamente um worker vence, e todos os demais recebem um
409e simplesmente passam para a próxima sessão pendente. Perder essa disputa de reivindicação é uma condição normal de operação, não um erro. - Cada worker tem sua própria identidade. O
acceptor_idlimita as reivindicações, renovações e a recuperação após reinicialização ao próprio worker.devin worker startgera e persiste um automaticamente por máquina, então uma frota não precisa de configuração de identidade. Nunca compartilhe um ID de acceptor (ou um diretório de dados de worker copiado) entre máquinas — workers em conflito roubarão as reivindicações uns dos outros. - As falhas se autorrecuperam. Se um worker parar depois de reivindicar, sua reivindicação expira no prazo de reivindicação e a sessão volta para a fila para que outro worker a assuma. Não é necessário monitoramento de integridade no nível da frota.
Criando um orquestrador personalizado
devin worker start faz está disponível diretamente na fleet API, então você pode substituir totalmente a CLI: faça o download do binário devin-remote da distribuição estática do Devin e inicie-o você mesmo com o ambiente documentado. Consulte Distribuição do binário remoto e o contrato de spawn na referência.
