Self-hosted AI coding agents: which run in your VPC, on-prem, or air-gapped
Published
Summary
Which AI coding agents run in your own cloud, on your servers, or air-gapped, where each one’s model runs, and what it took us to self-host OpenHands.
Many coding agent vendors say their product can run in your VPC or be self-hosted. What they mean varies a lot. A coding agent has three parts that can each run in a different place: the agent loop that decides each step, the machine where it reads your code and runs commands, and the model it sends that context to. Most "runs in your VPC" options leave at least one of those parts with the vendor.
This guide shows which parts each vendor lets you run yourself, and what it took when we self-hosted an open-source agent and a model. Every claim about a vendor links to that vendor's own page. We checked them all on November 7, 2026.
How we tested
An AI agent working in a Replicas workspace did the research, ran the tests, and wrote this guide, and a person on our team reviewed it before it was published. The agent read each vendor's current docs. It then installed OpenHands, an open-source coding agent, with Docker on a Linux VM, and gave it two small tasks: first on a hosted model, then on an open-weight model it served itself with vLLM on a rented GPU. The timings, errors, and network traffic below come from those runs.
Who runs each part of a coding agent
Who runs each part of a coding agent, by deployment model
Deployment model
Agent loop
Your code and commands
Model calls
Who runs and updates it
Vendor cloud
Shared, multi-tenant service
Vendor's cloud
Vendor's machines
Vendor's model account, or your API key
Vendor
Dedicated, single-tenant
Hosted by the vendor, used only by you
Vendor, in an instance only you use
Vendor, isolated from other customers
Vendor's account, or your cloud account
Vendor
Runners in your VPC
Self-hosted workers, runners, or outposts
Vendor's cloud
Your machines, with output sent back to the vendor
Vendor's account, or your cloud account
You run the runners, the vendor runs the rest
Agent in your VPC
The vendor keeps the control plane
Your machines
Your machines
Vendor's account, or your cloud account
You run the machines, the vendor runs the control plane
Full stack in your VPC or data center
The whole product on your infrastructure
Your servers
Your machines
A model API, your cloud account, or your own GPUs
You
Air-gapped
No connection to the internet
Your servers
Your machines
Your own GPUs, inside the network
You, including bringing updates in
The agent loop sees everything the agent reads, because it has to pass it to the model. So when only the machines move into your network, your code still leaves it. Cursor's docs, for example, say a self-hosted worker sends Cursor "file contents, terminal output, diffs, screenshots, local MCP results, and routing metadata" during a run (Cursor).
Where the model runs is a separate choice. Claude and OpenAI's hosted GPT models can't run on your hardware, so "in your VPC" for those models means a cloud account you control, such as Amazon Bedrock or Microsoft Foundry. Only open-weight models can run on your own GPUs.
Deployment options by coding agent
In alphabetical order. "Runners only" means your machines run the agent's commands while the vendor runs the agent loop and model calls. Dedicated and self-hosted options are usually on an enterprise plan, through sales.
| Agent | Vendor cloud | Single-tenant or dedicated | Your cloud or VPC | On-prem or air-gapped | Where the model runs |
|---|---|---|---|---|---|
| Amp | Yes (Amp) | Not documented | Runners only (Amp) | Not documented | Amp's models, or your keys, Bedrock, Vertex, or Foundry (Amp) |
| Claude Code | Yes, cloud sessions (Anthropic) | Not documented | The CLI runs on your machines. Cloud sessions can run on your runners, in beta, with Anthropic's control plane (Anthropic) | The CLI only. No air-gapped mode is documented | Anthropic, or Claude in your Bedrock, Google Cloud, or Foundry account (Anthropic) |
| Codex | Yes, Codex Cloud (OpenAI) | Not documented | The CLI and GitHub Action run where you run them. Codex Cloud doesn't | The CLI can use local models. Air-gapped use isn't stated (OpenAI) | OpenAI, Azure, Bedrock, Google Cloud, a gateway, or a local model (OpenAI) |
| Coder | No (Coder) | Not documented | Yes, agent loop included (Coder) | Yes, air-gapped (Coder) | Any provider, or a self-hosted model (Coder) |
| Cursor | Yes (Cursor) | Not documented | Runners only (Cursor) | No (Cursor) | Cursor, or your OpenAI, Anthropic, Azure, or Bedrock keys (Cursor) |
| Devin | Yes (Cognition) | Yes, a single-tenant VPC that Cognition hosts (Cognition) | Runners only, with Devin Outposts (Cognition) | The desktop app and CLI only, in beta (Cognition) | Cognition's models, with no option for your own keys. The air-gapped build uses endpoints you host |
| Factory | Yes (Factory) | Enterprise lists "dedicated compute, partitioned inference" (Factory) | Sandboxes in your VPC, in private preview, with Factory's control plane (Factory) | Yes, air-gapped (Factory) | Factory's models, your keys, or local models (Factory) |
| GitHub Copilot | Yes (GitHub) | Data residency keeps model calls in your region (GitHub) | The cloud agent can run on your own Actions runners (GitHub) | No. Not on GitHub Enterprise Server (GitHub) | GitHub's models. Your own keys aren't listed for the cloud agent (GitHub) |
| Ona (formerly Gitpod) | No. Ona Cloud closed on October 31, 2026 (Ona) | Not documented | Yes, runners in your AWS or GCP account, with Ona's management plane (Ona) | Not documented | OpenAI models, directly or through Bedrock or a gateway (Ona) |
| OpenCode | No hosted agent (OpenCode) | Not documented | Yes, wherever you install it (OpenCode) | Local models work. Air-gapped use isn't stated | Any provider, or a local model (OpenCode) |
| OpenHands | Yes, OpenHands Cloud (OpenHands) | Not documented | Yes, open source, or Enterprise in your cloud (OpenHands) | On-prem, yes. Air-gapped isn't documented (OpenHands) | Any provider, or a local model (OpenHands) |
| Replicas | Yes, on every plan (Replicas) | Yes, on a custom contract (Replicas) | Yes, on a custom contract (Replicas) | Not documented | Your accounts, including Bedrock, Foundry, Ollama, or a compatible endpoint (Replicas) |
| Sourcegraph Cody | No (Sourcegraph) | Yes, Sourcegraph Cloud (Sourcegraph) | Yes, self-hosted (Sourcegraph) | On-prem, yes. Air-gapped isn't documented | Sourcegraph's models, your keys, or a self-hosted model (Sourcegraph) |
| Tabnine | Yes (Tabnine) | Not documented | Yes, on Enterprise (Tabnine) | Yes, air-gapped, on Enterprise (Tabnine) | Tabnine's models, or private endpoints on Bedrock, Vertex, Azure, or your own server (Tabnine) |
"Not documented" means the vendor's own pages don't describe it. Ask the vendor before you rule it in or out. Sourcegraph Cody and Tabnine mainly work inside your editor as assistants. The other products can take a task and work through it on their own.
Most "VPC" options keep part of the product in the vendor's cloud. Amp, Cursor, and Devin run commands on your machines while the agent loop and model calls stay with them. Ona, Factory's private preview, and Claude Code's self-hosted environments run the agent itself on your machines, but the vendor still runs the control plane, and Anthropic says Claude Code session content still goes to Anthropic. GitHub Copilot's cloud agent can run on your own Actions runners.
Few products document a full install inside your network with no internet. Coder, Tabnine, and Factory do, and Devin has a beta build for its desktop app and CLI. Open-source agents such as OpenHands, OpenCode, and the Codex CLI run anywhere you install them and can use local models, but their docs don't describe an air-gapped install.
An air gap also needs an open-weight model. Codex, OpenCode, OpenHands, and Coder can point at a model you serve yourself. Claude Code can too, through an Anthropic-compatible server such as Ollama (Ollama), but Anthropic doesn't support routing it to non-Claude models (Anthropic).
What it took to self-host OpenHands
We ran OpenHands Agent Canvas 1.37.0 with Docker on a Linux VM with 2 vCPUs, following its README. The task was the same in both runs: a small Python repository with a failing test, and the prompt "find the bug, fix it, run the tests with pytest, and commit the fix."
Run 1: OpenHands on a hosted model. Claude Sonnet 5.5 through an Anthropic API key.
| Step | Time | What happened |
|---|---|---|
| Pull the image | 30 s | 4.04 GB |
| First start | Failed | The container runs as user ID 10001 and couldn't write to the folders we mounted. Changing their owner fixed it |
| Second start | 11 s | Agent server, automation server, and web UI all running |
| Setup screens | 5 min 9 s | Pick the agent, the provider and model, and paste the key. Much of this was our agent working out the forms |
| First task | 10 s | Found the bug, installed pytest, ran the tests, and committed |
| Total | 9 min 22 s | From the first command to the first commit |
Run 2: OpenHands on an open-weight model we served. Qwen3-Coder-30B-A3B-Instruct in FP8, on one rented NVIDIA L40S GPU with 48 GB of memory, served by vLLM 0.33.
| Step | Time | What happened |
|---|---|---|
| Start a GPU with vLLM's Docker image | 5 min | Most of it was pulling the image |
| First vLLM start | Failed | The image starts its own server on port 8000 when the container starts, with a small default model and no API key. It held the port and most of the GPU memory, and stopping it stopped the container. We started over on a plain PyTorch image |
| New GPU, then install vLLM | 33 s | |
| Download and load the model | 2 min 17 s | 29.11 GiB of weights in GPU memory |
| Second vLLM start | Failed | The PyTorch runtime image has no C compiler, which vLLM needs to compile kernels. Installing gcc took 12 s |
| Third vLLM start | Failed | FlashInfer's sampler needs NVIDIA's CUDA compiler, which the image also lacks. Setting VLLM_USE_FLASHINFER_SAMPLER=0 uses PyTorch's sampler instead (vLLM) |
| Fourth vLLM start | 2 min 2 s | Weights loaded from disk in 16 s. Compiling and warming up took 79 s |
| Point OpenHands at the endpoint | 1 min 37 s | A new model profile with the endpoint's URL and API key |
| First task | 18 s | Same result as run 1: fixed, tested, and committed |
| Total | 18 min 19 s | From asking for the GPU to the first commit |
The model fit, but with room for little more than one agent at a time. After loading, vLLM had 10.2 GiB left for context, or 111,456 tokens. It reported that at 65,536 tokens per request, the GPU could serve 1.7 requests at once. Each agent you run at the same time needs its own share of that.
We also ran the OpenCode CLI against the same endpoint. The first run never finished. This machine's global OpenCode config loaded eight MCP servers and about 90 skills, so the very first prompt was over the 65,536-token limit we'd set for the model. OpenCode compacted and retried 255 times without running a command, until we stopped it at 10 minutes. With a clean config, it fixed the bug and ran the tests in 16 seconds. To get pytest, it ran pip install --break-system-packages on the host, because OpenCode runs commands on your machine, not in a container. Its commit then failed because git had no name and email set, and its final message didn't mention that.
What the agent connected to
We recorded every DNS lookup and new connection from the OpenHands container with tcpdump:
| When | Hosts contacted | Why |
|---|---|---|
| Startup | raw.githubusercontent.com | LiteLLM, the library OpenHands uses to call models, downloads its model price list. LITELLM_LOCAL_MODEL_COST_MAP=True turns that off (LiteLLM) |
| Task on the hosted model | api.anthropic.com | Model calls |
| Task on our GPU | Our GPU endpoint only | Model calls |
The first time it starts, OpenHands asks whether to send anonymous usage data, with the box already checked. We unchecked it and saw no analytics traffic. Our GPU was rented and reached over the internet with an API key, so this wasn't an air gap. We tested serving the model, and didn't test a disconnected network.
What you take on when you self-host
The more of the agent you run, the more of this list becomes your job:
| What you take on | Runners in your VPC | Full stack, model through an API | Air-gapped, with your own model |
|---|---|---|---|
| Model access | The vendor's account, or your cloud account if the vendor supports it | Your own API key or cloud account. The provider still sees prompts and code | Open-weight models only. You pick, download, and serve them |
| Updates | The vendor updates the agent. You update the runner image | You pull new releases. OpenHands shipped 1.37.0 the day before our test | You bring new images and model weights in by hand. Tools that download lists at startup need that turned off |
| GPUs or model endpoints | None | None | GPUs sized for the model. Our 30B model used 29 GiB of a 48 GB card before any context |
| Egress | Outbound HTTPS to the vendor, plus your code host and package registries | The model API, your code host, package registries, and anything the agent's tools call | Nothing outside the network. Package installs need an internal mirror |
| Who runs it | The vendor runs the service. You keep the runners up and patched | You run everything except the model, including access control and backups | You run everything, including the model |
Plan for egress first. An agent installs packages, clones repositories, and calls the tools you give it, so the allowlist is longer than the model API.
Where Replicas fits
Replicas runs coding agents such as Claude Code, Codex, and OpenCode in an isolated Linux VM for each task. Every plan runs in Replicas cloud. A dedicated single-tenant deployment and a self-hosted deployment in your own infrastructure are both available on a custom Enterprise contract. Contact sales to set one up, or see what Enterprise includes.
Agents use the model accounts you already have, including an OpenAI- or Anthropic-compatible endpoint or an Ollama server you run, as long as the workspace can reach it over HTTPS (Credentials).
Replicas falls short of the most locked-down options in three ways. The public docs don't cover how a self-hosted or dedicated deployment is installed or what it needs. Those details come with the contract. No air-gapped install is documented. Replicas isn't open source, so you can't read or change the code you'd be running. If you need a fully disconnected install today, Coder, Tabnine, and Factory document one.
For how Replicas handles code, credentials, and data retention, see Security. If you work with health data, see AI coding agents and HIPAA.
FAQ