> ## 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. # Orquestração > Provisione máquinas e execute workers automaticamente conforme as sessões entram na fila 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](/pt-BR/onboard-devin/outposts/quickstart) — nenhum orquestrador é necessário. Se você usa uma plataforma compatível, uma [integração](/pt-BR/onboard-devin/outposts#integrations) talvez já implemente esse loop para você. Para ver toda a API e a CLI, consulte a [referência](/pt-BR/onboard-devin/outposts/reference). Vai executar no Kubernetes? [devin-outpost-k8s](https://github.com/CognitionAI/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`: ```bash theme={null} devin worker outpost create --platform --description "..." ``` 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](/pt-BR/onboard-devin/outposts/reference#outposts).
### 2. Monitore a fleet API para identificar sessões em espera
Seu orquestrador lista as sessões pendentes dos outposts aos quais atende: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&phase=pending" ``` 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: ```bash theme={null} curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&watch=true&cursor=" ``` 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](/pt-BR/onboard-devin/outposts/reference#list-queued-sessions) e [Watch for changes](/pt-BR/onboard-devin/outposts/reference#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: ```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" ``` 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](/pt-BR/onboard-devin/outposts/reference#release-a-claim) 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: ```bash theme={null} cd /path/to/repos devin worker start --session= --outpost= --acceptor-id= ``` 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](/pt-BR/onboard-devin/outposts/reference#devin-worker-start)). 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: ```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 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](/pt-BR/onboard-devin/outposts/reference#remote-binary-distribution) e o [contrato de spawn](/pt-BR/onboard-devin/outposts/reference#spawn-contract) na referência.