> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/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 um 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 as máquinas. Se você só quer processar sessões usando uma máquina que já tem, comece pelo [guia de início rápido](/pt-BR/cloud/outposts/quickstart) — nenhum orquestrador é necessário. Se você usa uma plataforma compatível, uma [integração](/pt-BR/cloud/outposts/overview#integrations) talvez já implemente esse loop para você. Para ver toda a superfície da API e da CLI, consulte a [referência](/pt-BR/cloud/outposts/reference). Vai executar no Kubernetes? O [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 operada por vários workers na 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 (ao lado de 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`, no escopo da sua conta (compartilhados entre todas as suas organizações). Consulte os [endpoints de outposts](/pt-BR/cloud/outposts/reference#outposts).
### 2. Monitore a fleet API em busca de sessões em espera
Seu orquestrador lista as sessões pendentes dos outposts aos quais ele 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 a visualização atualizada com um watch de 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 padrão do Kubernetes de listar e depois acompanhar: percorra a lista em páginas com o cursor da resposta e, em seguida, inicie um acompanhamento a partir de onde a lista terminou, persistindo o cursor de cada evento para que você possa se reconectar sem perder mudanças. A entrega ocorre pelo menos uma vez, então faça upsert por `metadata.session_id` e tolere duplicatas. Consulte [Listar sessões na fila](/pt-BR/cloud/outposts/reference#list-queued-sessions) e [Acompanhar mudanças](/pt-BR/cloud/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. Informe 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 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](/pt-BR/cloud/outposts/reference#release-a-claim) para que a sessão retorne à fila imediatamente.
### 4. Inicie uma máquina e execute o worker
Para cada sessão atribuída, 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= ``` Use o mesmo `--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](/pt-BR/cloud/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 finalizado
Quando `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: ```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 apresenta um `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. 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 é um compare-and-swap atômico no servidor: exatamente um worker vence, e todos os demais recebem um `409` e 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_id` limita as reivindicações, renovações e a recuperação após reinicialização ao próprio 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 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. 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 aguarda como pendente.
## Criando um orquestrador personalizado
Tudo o que `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](/pt-BR/cloud/outposts/reference#remote-binary-distribution) e o [contrato de spawn](/pt-BR/cloud/outposts/reference#spawn-contract) na referência.