Pular para o conteúdo principal
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 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 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 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 Opcional — instale estes itens para desbloquear recursos específicos:

​
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 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:

​
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 instalado:
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. 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 e as dependências da máquina e, em seguida, inicie o worker a partir do diretório que contém seus repositórios clonados:
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=<session_id> 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.
Vai executar no Kubernetes? O operador open source devin-outpost-k8s é instalado via Helm e executa workers para um outpost em qualquer cluster certificado (GKE, EKS, …). Com um clone desse repositório:

​
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:
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:
A resposta da listagem agrupa as sessões enfileiradas em items:
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:
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:
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:
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:
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:

​
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:
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:
repos
app
.git
infra
.git
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: Exemplos:
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:
Identifique a versão mais recente:
Baixar e verificar:
Plataformas disponíveis: 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:
com as seguintes variáveis de ambiente: 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:
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 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)

​
Outposts (/outposts)

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.