> ## 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. # Outposts > Execute sessões do Devin na sua própria infraestrutura O Outposts está em acesso antecipado. As APIs e os comandos de CLI descritos aqui podem mudar. Entre em contato com a equipe da sua conta para ativar o Outposts na sua organização. O Outposts permite executar sessões do Devin na infraestrutura que você controla — suas próprias VMs, contêineres, clusters do Kubernetes ou até mesmo um Mac Mini embaixo da sua mesa. O loop de agente do Devin (inferência e planejamento) continua sendo executado na nuvem do Devin, enquanto toda a execução de comandos, a edição de arquivos e o acesso a repositórios acontecem nas máquinas que você opera. Use o Outposts quando precisar de: * Sessões executadas dentro da sua rede, próximas de serviços internos, registros e segredos * Perfis de hardware personalizados (por exemplo, GPUs, máquinas com muita memória, imagens de SO específicas) * Infraestrutura existente de dev box, VM ou Kubernetes para hospedar as cargas de trabalho do Devin * Controles Enterprise sobre acesso à rede, saídas de build e monitoramento
## Como funciona
O Outposts tem duas camadas: 1. **O worker (por exemplo, `devin worker start`)** — um binário que você executa em uma máquina para atender a uma única sessão na fila. Ele abre uma conexão de saída com a nuvem do Devin e executa localmente as chamadas de ferramenta da sessão. A Cognition fornece esse binário; você nunca precisa implementá-lo. O [Devin CLI](/pt-BR/work-with-devin/devin-cli) contém a lógica para buscar e executar esse binário. 2. **O orquestrador** — um software que monitora a API de frota em busca de sessões aguardando workers, provisiona uma VM ou contêiner para cada uma e inicia o worker dentro dela. Fornecemos algumas implementações de referência para plataformas comuns (como Kubernetes), mas fique à vontade para adaptá-las (elas são de código aberto!) ou escrever a sua própria. Os workers só precisam de acesso HTTPS de **saída**. Nenhuma porta de entrada, IP público ou túnel VPN é necessária. Quando um usuário inicia uma sessão no Devin Cloud e seleciona um dos seus outposts registrados, a sessão é colocada na fila desse outpost. Seu orquestrador a reivindica, cria uma máquina e executa o worker. Quando a sessão termina, o worker é encerrado e seu orquestrador desprovisiona a máquina.
## Pré-requisitos
* Uma organização com o Outposts ativado * Um [token da API v3](/pt-BR/api-reference/v3/overview) com os escopos apropriados do Outposts: * `account.outposts.orchestrator` para orquestradores que gerenciam outposts (inclui o escopo da máquina) * `account.outposts.machine` para workers que leem a fila e reivindicam/liberam sessões * Uma imagem da máquina (VM ou contêiner) com: * O Devin CLI instalado * As [dependências da máquina](#machine-dependencies) abaixo * Seus repositórios clonados, com remotos configurados * Acesso às ferramentas de build, aos registros de pacotes, aos segredos e aos serviços internos de que suas sessões precisam
### Dependências da máquina
As sessões são executadas diretamente na sua máquina, portanto o worker depende das ferramentas que você instala nela. **Obrigatório** | Dependência | Usado para | | ----------------- | -------------------------------------------- | | `git` (em `PATH`) | Clonagem e todas as operações no repositório | **Opcional** — instale estes itens para desbloquear recursos específicos: | Dependência | Recurso | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ffmpeg` (em `PATH`) | Os recursos de gravação de tela do Devin. Sem ele, as sessões não podem gravar a tela. | | Chrome ou Chromium | Recursos de Browser e uso do computador. Por padrão, o worker procura o Chrome em locais de instalação padrão; defina `DEVIN_CHROME_PATH` no ambiente do worker como o caminho absoluto para o binário para fazer override (por exemplo, `DEVIN_CHROME_PATH=/usr/bin/google-chrome`). Sem ele, as ferramentas de Browser ficam indisponíveis. | | `sudo` sem senha | Permite que o Devin instale os softwares de que precisa durante uma sessão (por exemplo, `ferramenta de build` ausentes ou pacotes do sistema). Conceda isso apenas quando a máquina for dedicada ao Devin e recriada após cada sessão — nunca em máquinas compartilhadas ou de longa duração. |
## Guia de início rápido: crie um outpost e inicie um worker
Este passo a passo cria um outpost e o coloca para funcionar em uma única máquina com `devin worker start` — sem necessidade de orquestrador. Esta é a forma mais rápida de experimentar o Outposts em uma máquina de desenvolvimento, e é esse mesmo comando de worker que um orquestrador executa em escala.
### 1. Criar um token de usuário de serviço
O worker (e qualquer orquestrador) se autentica na API do Outposts com um [token da API v3](/pt-BR/api-reference/v3/overview) pertencente a um **usuário de serviço**; as permissões da função abaixo concedem ao token os escopos do Outposts (`UseOutpostsMachine` → `account.outposts.machine`, `ManageOutpostsOrchestrator` → `account.outposts.orchestrator`). No web app do Devin: 1. **Crie uma função** com acesso ao Outposts. Em **Configurações → Roles**, adicione uma função do Enterprise e ative **Use outpost machine** (`UseOutpostsMachine`) em *Outpost permissions*. Ative também **Manage outposts** (`ManageOutpostsOrchestrator`) se esse usuário de serviço for criar ou excluir outposts. 2. **Provisione o usuário de serviço.** Em **Configurações → Devin API → Service users**, clique em **Provision service user**, dê um nome a ele (por exemplo, `outposts-worker`), atribua a função da etapa 1 e defina uma data de expiração. 3. **Copie o token.** O token `cog_...` é exibido **apenas uma vez** no momento da criação — copie-o agora; ele não poderá ser recuperado depois. Exporte-o para os comandos abaixo: ```bash theme={null} export DEVIN_OUTPOSTS_TOKEN="cog_..." ```
### 2. Criar um outpost
Um outpost é uma fila de sessões com nome definido, atendida pela sua infraestrutura. Crie um em qualquer máquina com o [Devin CLI](/pt-BR/cli) instalado: ```bash theme={null} devin worker outpost create my-outpost --platform linux --description "Dev boxes in our VPC" ``` O comando exibe o ID do novo outpost (`outpost_env-...`) — anote-o para a próxima etapa. Você também pode criar outposts no app web em **Configurações → Outposts** ou pela [API de outposts](#outposts-outposts). Depois de criado, o outpost aparece como uma opção de máquina no Devin Cloud (junto com Ubuntu, Windows etc.) ao iniciar uma sessão.
### 3. Inicie o worker
Na máquina que atenderá às sessões, instale o [Devin CLI](/pt-BR/cli) e as [dependências da máquina](#machine-dependencies) e, em seguida, inicie o worker a partir do diretório que contém seus repositórios clonados: ```bash theme={null} cd /path/to/repos devin worker start --outpost= ``` O worker consulta a fila do outpost, reivindica a primeira sessão pendente, baixa o binário `devin-remote` correto e atende a sessão. Quando a sessão termina, ele volta para a fila e espera a próxima. Como alternativa, passe `--once` para sair após atender uma única sessão, ou `--session=` para reivindicar e atender uma sessão específica. Se `--token` e `DEVIN_OUTPOSTS_TOKEN` não estiverem definidos, o comando gera um erro. Se `--outpost` for omitido em um terminal interativo, o worker solicitará que você escolha um dos outposts da sua conta.
### 4. Inicie uma sessão no outpost
No Devin Cloud, inicie uma nova sessão e selecione seu outpost como máquina. A sessão entra na fila, seu worker a reivindica, e a execução começa na sua máquina. Para atender mais sessões ao mesmo tempo, execute o worker em mais máquinas apontadas para o mesmo outpost — consulte [agendamento sem centralização](#centralization-free-scheduling). Vai executar no Kubernetes? O operador open source [devin-outpost-k8s](https://github.com/CognitionAI/devin-outpost-k8s) é instalado via Helm e executa workers para um outpost em qualquer cluster certificado (GKE, EKS, ...). Com um clone desse repositório: ```bash theme={null} helm install outposts charts/devin-outposts-k8s \ --set defaultPool.enabled=true \ --set defaultPool.poolId= \ --set defaultPool.token.value="$DEVIN_OUTPOSTS_TOKEN" ```
## Fluxo principal
### 1. Registrar um outpost
Um outpost é uma fila de sessões identificada por um nome e atendida por muitos 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 direcionadas a ele ficam na fila até que um worker as reivindique. Na API de frota, os outposts são representados como recursos `outposts`, com escopo da sua conta (compartilhados entre todas as suas organizações).
### 2. Consulte a API de frota em busca de sessões em espera
Seu orquestrador lista as sessões pendentes dos Outposts que atende: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&phase=pending" ``` A resposta da listagem agrupa as sessões enfileiradas em `items`: ```json theme={null} { "items": [ { "metadata": { "session_id": "devin-...", "outpost_id": "outpost_env-...", "created_at": 1781050000, "updated_at": 1781050000 }, "spec": { "kind": "new", "platform": "linux", "remote_binary_sha": null }, "status": { "phase": "pending", "acceptor_id": null, "claim_deadline": null, "session_status": "pending" } } ], "cursor": "djE6MTc4MTA1MDAwMC4w", "has_next_page": false, "total": 1 } ``` Use o cursor da resposta para paginar sem precisar reconciliar repetidamente a fila inteira. Defina `first` como o tamanho da página (até 200) e, em seguida, passe o `cursor` de cada resposta para a próxima requisição enquanto `has_next_page` for `true`: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&first=200&cursor=" ``` A API oferece entrega com semântica de pelo menos uma vez. Uma sessão no limite entre páginas pode aparecer em ambas as páginas, então faça upsert das entradas por `metadata.session_id` em vez de tratar cada item como novo. Quando `has_next_page` se tornar `false`, salve o cursor retornado como a posição inicial da API de watch.
#### Monitore alterações
Após a listagem inicial, inicie um monitoramento por Server-Sent Events (SSE) com o cursor final: ```bash theme={null} curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&watch=true&cursor=" ``` O stream envia eventos `MODIFIED` quando o item da fila de uma sessão é alterado e eventos `DELETED` quando ela é removida. Sessões recém-enfileiradas também chegam como eventos `MODIFIED`. Cada campo `data` de SSE contém um JSON com este formato: ```json theme={null} { "type": "MODIFIED", "object": { "metadata": { "session_id": "devin-...", "outpost_id": "outpost_env-...", "created_at": 1781050000, "updated_at": 1781050100 }, "spec": { "kind": "new", "platform": "linux", "remote_binary_sha": null }, "status": { "phase": "pending", "acceptor_id": null, "claim_deadline": null, "session_status": "pending" } }, "cursor": "djE6MTc4MTA1MDEwMC4w" } ``` Persista o `cursor` de nível superior de cada evento após processá-lo. Se a conexão for encerrada, reconecte usando o último cursor persistido para reproduzir quaisquer mudanças que ocorreram enquanto estava desconectado. A entrega via watch também ocorre pelo menos uma vez, então os clientes devem tolerar eventos duplicados. Os streams se encerram em no máximo cinco minutos; espera-se um loop de watch com reconexão. O filtro `outpost` se aplica tanto a requisições de listagem quanto de watch. Os filtros `phase` e `acceptor_id` se aplicam apenas a requisições de listagem e são ignorados quando `watch=true`; filtre os eventos monitorados usando os campos do `object` de cada evento. Omitir o cursor faz a leitura começar do início, então use list-then-watch para reconciliação normal. Antes de iniciar uma máquina para uma sessão, reivindique-a de forma atômica para que nenhum outro worker a assuma. 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 operações de reivindicação são atômicas: se outro worker reivindicar a sessão primeiro, você receberá um `409`. Reivindicar garante que um worker ficará 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: ```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}/release" ```
### 3. 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 já foi feito o checkout dos repositórios da sessão: ```bash theme={null} cd /path/to/repos devin worker start --session= --outpost= --acceptor-id= ``` Todos os repositórios da sessão devem estar em checkout em relação ao diretório de trabalho de onde `devin worker start` é executado: Neste exemplo, você executaria `devin worker start` a partir de `repos/`, e a sessão vê `app/` e `infra/` em relação ao seu diretório de trabalho. Flags úteis: | Flag | Descrição | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--session` | Identifica a sessão a ser atendida; o worker é encerrado quando ela termina. | | `--outpost` | Identifica o outpost da sessão a ser atendida. | | `--acceptor-id` | Usa o mesmo ID de acceptor da reivindicação via API para este worker. | | `--token` | Token de autenticação opcional para o worker. Se omitido, o worker usa `DEVIN_OUTPOSTS_TOKEN`; se nenhum dos dois estiver definido, o comando gera erro. | Exemplos: ```bash theme={null} devin worker start --session= --outpost= --acceptor-id= --token="" DEVIN_OUTPOSTS_TOKEN="" devin worker start --session= --outpost= --acceptor-id= ``` O worker se conecta à nuvem do Devin, sinaliza que a sessão está pronta e começa a executar chamadas de ferramenta.
### 4. Obtendo o binário remoto diretamente
O comando `devin worker start` baixa automaticamente o binário `devin-remote` correto. Se você estiver criando um orquestrador personalizado que não usa o Devin CLI, poderá obter o binário diretamente em: ``` https://static.devin.ai/devin-rs/remote/ ``` **Identifique a versão mais recente:** ```bash theme={null} # Retorna o git SHA do binário publicado mais recente para sua plataforma curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64" ``` **Baixar e verificar:** ```bash theme={null} SHA=$(curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64") # Baixar o binário curl -fL "https://static.devin.ai/devin-rs/remote/devin-remote_${SHA}_linux_x64" \ -o devin-remote # Baixar e verificar o checksum curl -fsSL "https://static.devin.ai/devin-rs/remote/devin-remote_${SHA}_linux_x64.sha256" \ -o devin-remote.sha256 echo "$(cat devin-remote.sha256) devin-remote" | sha256sum -c chmod +x devin-remote ``` **Plataformas disponíveis:** | Suffix | OS / Architecture | | ----------------- | ------------------- | | `linux_x64` | Linux x86\_64 | | `macos_arm64` | macOS Apple Silicon | | `windows_x64.exe` | Windows x86\_64 | Se a entrada da fila da sessão incluir `spec.remote_binary_sha`, use esse SHA em vez de `latest` — isso fixa a sessão em uma versão específica já testada.
#### Contrato para iniciar
Se o seu orquestrador iniciar o `devin-remote` por conta própria, faça isso da seguinte forma: ```bash theme={null} devin-remote serve ``` com as seguintes variáveis de ambiente: | Variable | Required | Description | | ----------------------------- | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `DEVIN_OUTPOST_GATEWAY_URL` | Sim | URL base do gateway do Outpost, por exemplo `wss://outpost-gateway.devin.ai`. | | `DEVIN_OUTPOST_CONNECT_TOKEN` | Sim | Token Bearer de conexão para o gateway, obtido na resposta de reivindicação. | | `DEVIN_OUTPOST_SESSION_ID` | Sim | O ID da sessão atendida. Todas as três variáveis `DEVIN_OUTPOST_*` devem ser definidas juntas. | | `DEVIN_REMOTE_STATE_DIR` | Fortemente recomendado | Diretório de estado por sessão em que o remoto armazena credenciais, tokens e arquivos de integração com o shell. Use um diretório exclusivo para cada sessão (por exemplo `~/.devin/worker/sessions/`, que é o que `devin worker` usa). Se não estiver definido, o remoto recorrerá a um padrão compartilhado em todo o sistema (`/opt/.devin` no Linux, `~/.devin` no macOS, `C:\ProgramData\devin` no Windows), que nesse caso deve existir e ter permissão de gravação — e que expõe o estado de cada sessão entre sessões simultâneas. Sempre defina isso. | | `DEVIN_CHROME_PATH` | Opcional | Caminho para um binário do Chrome/Chromium na máquina para a ferramenta Browser (não há Chrome gerenciado pelo Devin no Outposts). | | `DEVIN_OUTPOST_DESKTOP` | Opcional | Defina como `true` para ativar o stream da área de trabalho (VNC). No lado remoto, ele funciona sob demanda — nada é capturado até que um visualizador se conecte — portanto, é seguro ativá-lo incondicionalmente. | Forneça ao remoto um ambiente limpo contendo apenas as variáveis acima, além das variáveis básicas do sistema (`PATH`, `HOME`, `USER`, `LOGNAME`, `TMPDIR`, `LANG`, `TZ` e — para a captura de tela do stream da área de trabalho no Linux/X11 — `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`). Não deixe vazar para o remoto nada que o agente não deva conseguir ver: isso será herdado pelo shell do agente. Expectativas adicionais do ciclo de vida: * **Diretório de trabalho**: inicie o remoto a partir do diretório que contém os repositórios da sessão (a mesma regra de `devin worker start`). * **Fim da sessão**: quando a sessão termina (entra em suspensão ou é encerrada), o Devin notifica o remoto e ele sai por conta própria com status 0. Trate uma saída limpa como o fim da sessão: confirme que `status.session_status` do item da fila é `suspended` ou `terminated` (a atualização de status pode demorar alguns segundos para refletir a saída, então consulte novamente algumas vezes) e então libere a reivindicação. Como fallback, também consulte `status.session_status` enquanto o remoto estiver em execução e finalize você mesmo o processo assim que ele atingir `terminated` (ou o item da fila desaparecer).
### 5. Encerre a máquina quando o worker for finalizado
Quando `devin worker start` é encerrado, a sessão chega ao fim (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 indica um `status.session_status` de `pending`, `running`, `suspended` ou `terminated`.
## Agendamento sem centralização
Está planejando executar mais de \~16 coordenadores (workers ou orquestradores monitorando e reivindicando a partir de um outpost)? Entre em contato primeiro com a equipe da sua conta — frotas maiores ampliam a contenção de reivindicação 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 para reivindicar sessões pendentes. A reivindicação é um compare-and-swap atômico no server: exatamente um worker vence, e todos os demais recebem um `409` e simplesmente passam para a próxima sessão pendente. Perder uma 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` restringe as reivindicações, renovações e a recuperação após reinicialização de um worker exclusivamente a esse worker. `devin worker start` gera e persiste um automaticamente por máquina, portanto 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 autocorrigem.** Se um worker morrer após reivindicar, sua reivindicação expira no prazo de reivindicação e a sessão retorna à fila para que outro worker a assuma. Não é necessário nenhum 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 fica aguardando como pendente. Duas observações operacionais: * **Use o endpoint de watch, não listagens completas repetidas.** Faça uma listagem paginada para criar o estado inicial e, em seguida, mantenha um [fluxo de watch](#watch-for-changes) a partir do cursor retornado. Consultar novamente toda a fila a partir de cada worker não escala bem e aumenta a latência de reivindicação; o fluxo de watch entrega as mudanças conforme elas acontecem. * **Fale conosco antes de passar de \~16 máquinas em um outpost.** A reivindicação sem coordenação funciona bem com frotas pequenas, mas frotas maiores ampliam a contenção de reivindicação e a carga de leitura da fila. Se você planeja executar mais de cerca de 16 workers em um único outpost, entre em contato primeiro com a equipe da sua conta para que possamos garantir que o outpost esteja provisionado para isso.
## Referência da API
Todos os endpoints de Outposts estão em `https://api.devin.ai/opbeta` e compartilham um formato de recurso comum (`metadata` / `spec` / `status`). As respostas de listagem retornam `items`, `cursor`, `has_next_page` e `total`.
### Devins (`/outposts/devins`)
| Endpoint | Descrição | | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | `GET /outposts/devins?outpost=...&phase=pending` | Lista as sessões aguardando um worker. | | `GET /outposts/devins?outpost=...&first=...&cursor=...` | Continua uma lista paginada a partir do cursor de uma resposta anterior. | | `GET /outposts/devins?outpost=...&watch=true&cursor=...` | Transmite eventos `MODIFIED` e `DELETED` após um cursor de lista ou de watch. | | `GET /outposts/devins?phase=claimed&acceptor_id=...` | Lista as sessões reivindicadas por um acceptor específico. | | `GET /outposts/devins/{session_id}` | Retorna um único item da fila. | | `POST /outposts/devins/{session_id}/claim` | Reivindica atomicamente uma sessão (`409` se já tiver sido reivindicada). Corpo: `{"acceptor_id": "..."}`. | | `POST /outposts/devins/{session_id}/release` | Libera uma reivindicação, retornando a sessão à fila. Corpo: `{"acceptor_id": "..."}`. |
### Outposts (`/outposts`)
| Endpoint | Descrição | | ------------------------------- | -------------------------------------------------------------------------------------------- | | `GET /outposts` | Lista os Outposts da sua conta. | | `POST /outposts` | Cria um Outpost. Corpo: `{"name": "my-outpost", "platform": "linux", "description": "..."}`. | | `GET /outposts/{outpost_id}` | Obtém um Outpost específico. | | `DELETE /outposts/{outpost_id}` | Exclui um Outpost (`409` enquanto houver reivindicações ativas). | ```json theme={null} { "metadata": { "outpost_id": "outpost_env-...", "account_id": "...", "created_at": 1781050000 }, "spec": { "name": "my-outpost", "platform": "linux", "description": "..." }, "status": { "queue_depth": 3, "active_claims": 2 } } ``` `status.queue_depth` e `status.active_claims` são sinais úteis para o escalonamento automático: se a fila estiver acumulando, seu orquestrador pode provisionar mais máquinas pré-aquecidas.
## O que os workers podem fazer
As sessões executadas em workers do Outposts são sessões do Devin com todos os recursos: skills, Knowledge, servidores MCP e segredos funcionam da mesma forma que no Devin Cloud, disponibilizados por meio da conexão do worker. Seus repositórios, caches de build e a execução de ferramentas permanecem no seu ambiente; artefatos da sessão, como capturas de tela, são importados para o Devin Cloud para que você possa visualizá-los na sessão e em PRs. As sessões do Outpost têm timeouts rígidos de prontidão. Depois que seu orquestrador reivindica uma sessão, o worker precisa se conectar antes do prazo limite da reivindicação — caso contrário, a reivindicação expira e você ainda é cobrado pelos custos fixos e por hora gerados durante a janela de timeout.