Skip to main content
Outposts lets you run Devin sessions inside infrastructure you control — your own VMs, containers, Kubernetes clusters, or even a Mac Mini on your desk. Devin’s agent loop (inference and planning) continues to run in Devin’s cloud, while all command execution, file edits, and repository access happen on machines you operate. Use Outposts when you need:
  • Sessions to run inside your network, next to internal services, registries, and secrets
  • Custom hardware profiles (e.g. GPUs, large memory machines, specific OS images)
  • Existing dev box, VM, or Kubernetes infrastructure to host Devin workloads
  • Enterprise controls over network access, build outputs, and monitoring
Devin's agent loop and the outpost queue run in Devin Cloud; your machines — a GPU box in your lab, a VM in your VPC, or a Mac mini on your desk — serve sessions over an outbound-only connection

​
How it works

An outpost is a named queue of Devin sessions to be served on your own machines. Once you register an outpost (e.g. gpu-h200 or dev-boxes), it appears as a machine option in Devin Cloud alongside Ubuntu, Windows, etc. — Cloud sessions started on an outpost wait in its queue until one of your machines picks them up. Every machine that serves sessions from an outpost is a worker. To turn a machine into a worker, install the Devin CLI and run:
The worker opens an outbound connection to Devin’s cloud and watches the outpost’s queue. When a session is waiting, the worker claims it and executes its tool calls locally — every command, file edit, and repository operation runs on your machine. When the session ends, the worker goes back to watching the queue for the next session. Scaling out is just running the worker on more machines: N workers serve N concurrent sessions, and any further sessions wait in the queue until a worker becomes available. Workers only need outbound HTTPS access. No inbound ports, public IPs, or VPN tunnels are required.

​
Orchestration

Long-lived worker machines are the simplest setup, but with the Outposts API you can also write an orchestrator: software that watches the outpost’s queue and, for each waiting session, spins up a fresh VM or container, starts the worker inside it, and tears the machine down when the session ends. See Orchestration to learn how, deploy devin-outpost-k8s — our open-source operator that runs the loop on any Kubernetes cluster — or run on a partner platform that already implements it for you (see Integrations).

​
Machine dependencies

Sessions execute directly on your machines, so the worker relies on tools you install there.

​
Get started

Quickstart

Create an outpost and serve sessions from a single machine with devin worker start — no orchestrator required.

Orchestration

Scale to a fleet: poll the queue, claim sessions, provision machines, and run workers automatically.

Reference

The full surface area: CLI commands and flags, fleet API endpoints, binary distribution, and the spawn contract.

​
Integrations

Partner platforms implement the orchestration loop for you — sessions run on their infrastructure with no worker to run and no orchestrator to build. Each partner documents its own setup:

​
Limitations

  • Devin Outposts currently works only with multi-tenant hosting; it is not currently available with Dedicated Tenant deployments.
  • Outposts shifts significant infrastructure and operational responsibility to the customer. Teams must secure and operate their remote development VMs at scale, including provisioning, isolation, access controls, capacity management, monitoring, and recovery. For security-conscious customers, we recommend Dedicated Tenant (Dedicated SaaS), which provides a customer-isolated environment with security and orchestration managed by Cognition.