Cognition's Devin Outposts Brings AI Coding Agent to Your Private GPU
Devin Outposts lets you run Devin sessions on your own hardware, private networks, and GPU clusters, with six launch partners ready to deploy.
- Devin Outposts lets you run Devin sessions on your own machines (GPUs, VMs, Mac minis, Kubernetes) while Devin's AI reasoning stays in Cognition's cloud.
- Six launch partners are ready: E2B, Daytona, Cloudflare, Namespace (M5 Mac), Modal (GPU), and NVIDIA Brev (GPU).
- Workers only need outbound HTTPS -- no inbound ports, public IPs, or VPN tunnels required.
- Key use cases: debug GPU training failures in place, access private-network services, and build iOS apps with Xcode on Apple silicon.
- Currently in early access; requires contacting your Devin account team to enable for your organization.
- Outposts is intended for tech-native teams comfortable operating remote dev VMs at scale -- not a drop-in for Devin's managed hosting.
Devin Outposts is Cognition's answer to a problem that has quietly blocked enterprise adoption of AI coding agents: the work lives on your machines, but the agent lives in someone else's cloud. With Outposts, you can run Devin sessions on any machine you operate, from a Mac mini on your desk to a GPU cluster inside your VPC, while Devin's inference and planning loop stays in Cognition's cloud.
The architectural split
Devin's agent loop handles inference and planning in Cognition's cloud, while all command execution, file edits, and repository access happen on machines you control. Cognition handles the expensive, stateful reasoning; your infrastructure handles the sensitive, environment-specific execution.
Workers only need outbound HTTPS access. No inbound ports, public IPs, or VPN tunnels required. Drop a worker inside a locked-down VPC and it connects out to Devin's cloud without opening any holes in your firewall.
The mechanics work in three steps:
- Create a pool with the Devin CLI, add a worker on your machine, then select it as your runtime when starting a session.
- When a session starts and a pool is selected, the session enters that pool's queue. Your orchestrator claims it, spawns a machine, and runs the worker.
- When the session ends, the worker exits and your orchestrator tears the machine down.
Claims are atomic, so exactly one worker wins per session. The queue is exposed through an API that tells your infrastructure which sessions are waiting, so an orchestrator can spin machines up on demand and shut them down when the session ends. You never need to keep workers running around the clock.