Self-Hosted AI Coding Agents on Your Own Infrastructure

Updated October 9, 2026 · first published July 18, 2026 · by the AQ team

Running AI coding agents on your own infrastructure means owning the execution environment (the machine where the agent reads your code, runs commands, and holds your credentials), not the model. As of October 2026 there are five practical routes: run agent CLIs like Claude Code and Codex directly on a VM you own, deploy an open-source harness like OpenHands, run a fully self-hosted platform like Coder Agents (generally available September 9, 2026, air-gap capable), attach self-hosted workers to a vendor platform like Cursor or Warp's Oz, or use a harness like AQ built around your own cloud from the start. In almost every one of these setups the model is still a hosted API: unless you also serve open-weight models, you are self-hosting execution and custody, not intelligence. Choosing comes down to which boundary your policy actually requires: code, credentials, and execution on your machines (every route below delivers that), or source-derived prompts never leaving your network (only a locally served open-weight model, or an air-gapped platform pointed at one, delivers that). When you have picked a route, the step-by-step self-hosted AI coding agent setup guide walks the plain-VM path end to end.

What "self-hosted" actually means for a coding agent

A coding agent setup has three separable pieces, and vendors mean very different subsets by "self-hosted":

• The model. The LLM doing the reasoning. It sees every prompt, and prompts include code context.
• The harness and orchestration. The software that turns model output into tool calls, manages sessions, and gives you a dashboard: open source on your box, or a service in the vendor's cloud.
• The execution environment. The filesystem with your repository clone, the shell, your GitHub tokens, cloud credentials, and network position. The highest custody stakes live here.

When a vendor says "self-hosted," ask which pieces move onto your infrastructure. Usually it is only the third. That is still valuable, but it is not the same claim as "nothing leaves our network."

Why teams run agents on their own infrastructure

• Code custody. The repository clone, build artifacts, and everything the agent writes stay in your own cloud account.
• Credential custody. A useful agent holds real secrets: a GitHub token that can push, database URLs, cloud credentials. On your VM they stay on hardware you can audit and wipe. Custody is necessary but not sufficient: keeping secrets out of coding agent prompts covers the other half, since anything the agent reads can end up in a prompt to the model provider.
• Internal network access. Agents inside your network can reach private package registries, staging databases, and services behind your VPN.
• Data residency and review. Regulated teams must document where source code and secrets go. "Execution stays in our cloud account" is a short answer.
• Laptop lifetime. An agent on your laptop dies when the lid closes. A server session keeps working through your commute and overnight.
• Compute economics. You pay your cloud provider's price for the VM, not a platform's bundled compute margin.

Option 1: A plain VM with tmux and SSH

The simplest setup needs no platform at all: a Linux VM, SSH, tmux, and the agent CLI of your choice. Claude Code and Codex run happily on a headless server, and tmux keeps the session alive when your connection drops.

# On the VM (once): install your agent CLI and log in
ssh dev-box

# Per task: a named tmux session that outlives your SSH connection
tmux new -s fix-auth
claude            # or codex, or any terminal agent

# Detach with Ctrl-b then d. Close your laptop. Later, from anywhere:
ssh dev-box
tmux attach -t fix-auth

Add mosh for flaky networks and Tailscale to keep the VM off the public internet. Total control, minimal moving parts, every CLI works, and it costs only the VM. The setup guide covers sizing, hardening, headless CLI auth, and keeping sessions alive; running Claude Code on a cloud VM walks the provisioning end of it (picking a provider, instance size, and headless login), and keeping Claude Code running after closing your laptop goes deep on the persistence patterns.

The limits arrive with teammates and scale: sharing a session means sharing SSH access, two tasks in one checkout trample each other unless you script git worktrees per task (isolation is half of limiting what a coding agent can destroy), tmux sessions are in-memory so a reboot clears them, and nobody sees what agents are doing without logging in.

Option 2: OpenHands and Coder, the fully self-hostable platforms

OpenHands is the most established fully self-hostable harness. As of October 2026 its core is MIT-licensed (the enterprise control plane is a separate commercial tier) and it typically runs via Docker: an application server serves the web UI and conversation logic, and spawns sandboxed runtime containers where the agent edits files and runs commands. It can also drive third-party agents such as Claude Code and Codex over the Agent Client Protocol, alongside its own agent. If you are weighing it against the routes on this page, the OpenHands alternatives page compares them head on.

The model is bring-your-own: paste an API key for a hosted provider, or set a custom base URL to point at a local server such as Ollama, vLLM, or LM Studio. That makes OpenHands one of the few options where every piece (harness, execution, even the model) can run inside your network. One sharp edge from its own docs: Ollama's default context window (4,096 tokens) is far too small for the agent's system prompt, so a local setup needs OLLAMA_CONTEXT_LENGTH raised to at least 22,000 tokens before it behaves correctly, with 32,768 the documented recommendation.

Coder Agents went generally available on September 9, 2026 and is the strongest "everything on our infrastructure" answer among the platforms: the control plane, orchestration, and execution all run in your own cloud VPC, on-prem, or fully air-gapped, and the model can be any hosted provider (Anthropic, OpenAI, Google, AWS Bedrock) or your own self-hosted endpoint, so a locked-down deployment can keep code, prompts, and model traffic entirely inside the network. The underlying platform is open source under AGPL v3; as of October 2026 Coder's pricing page allows up to five active Coder Agents on the Community and Premium tiers, with an AI Premium tier that is unlimited.

The tradeoff for both: you operate them. OpenHands needs Docker socket access to spawn sandbox containers (fiddly on locked-down hosts), Coder is a platform to deploy rather than a CLI to install, and upgrades, persistence, and access control are your job either way.

Option 3: Self-hosted workers for a vendor platform (Cursor, Warp Oz)

The newest pattern is "execution local, brain remote": the vendor's product, with the worker that touches your code on your machines.

Cursor runs cloud agents on machines you manage through Self-Hosted Machines, documented in two shapes as of October 2026: My Machines, which connects a personal laptop or VM to your own account, and Team Pools, named pools of workers on Enterprise plans that route agent runs to shared company-managed capacity (a pool request queues until a free worker picks it up, and admins can keep separate pools for different hardware, such as GPU boxes or Macs for iOS builds). Workers open a long-lived outbound HTTPS connection to Cursor's cloud, with no inbound ports, public IPs, or VPN tunnels, and the documented ceiling is 200 workers per user and 1,000 per team. Cursor's docs draw the boundary precisely: terminal commands, file edits, browser actions, and other tool calls execute on your worker, next to your repos, build caches, secrets, and internal services, while the agent loop, planning, and model inference run in Cursor's cloud; during a run the worker sends Cursor the file chunks the model reads, and uploads artifacts such as screenshots, videos, and log references to Cursor-managed storage. The repository clone stays local; the context the model reads does not.

Warp's Oz platform offers self-hosting exclusively on its Enterprise plan, in two shapes as of October 2026: a managed worker daemon (oz-agent-worker, open source on GitHub) that connects out to the platform and executes tasks in Docker containers, Kubernetes Jobs, or directly on hosts, or an unmanaged mode where your own CI or scripts invoke the agent command and Warp only tracks the session. Repository clones, source files, build artifacts, and runtime secrets stay on your infrastructure. Warp's documentation is direct about the boundary: orchestration metadata, session transcripts (including code context in prompts), and LLM inference route through Warp's control plane under Zero Data Retention agreements. A bring-your-own-LLM option on Enterprise can route inference through your own cloud provider account instead, and as of October 2026 it covers cloud agents, with support varying by provider.

This pattern satisfies "our code artifacts stay in our network." It does not satisfy "no source-derived context leaves our network": prompts still flow through the vendor and the model provider.

The model is usually still someone else's computer

Self-hosting the agent almost never means self-hosting the model. Claude Code executes on your machine but calls Anthropic's API. Codex CLI is open source under Apache 2.0 and runs locally, but the reasoning happens at OpenAI. Wherever the agent runs, prompts carry code context to the model provider under its data terms.

The exception is open-weight models. As of October 2026, Ollama, vLLM, LM Studio, and llama.cpp can serve models like the Qwen3-Coder family on your own GPUs, and all four speak an Anthropic-compatible /v1/messages API (Ollama shipped its native endpoint in v0.14.0 in January 2026, and vLLM's own docs cover pointing Claude Code at a vLLM server directly), so even Claude Code can point its base URL at a local endpoint, and nothing leaves your network at all. Budget context as well as GPUs: Ollama's docs recommend at least a 32k token context window for Claude Code, the same lesson as the OpenHands guidance above. The costs are real: serious GPU capacity, and open-weight coding models that still trail the hosted frontier on hard agentic work. Most teams split it: self-host execution and custody, keep a frontier hosted model under your own accounts and keys, and cover the prompt flow with the provider's enterprise data terms. The open-weights shelf is also refreshing faster than it ever has: DeepSeek V4 Pro went GA under MIT on August 13, 2026, and Z.ai's GLM-5.3 (August 14) ships its weights roughly two weeks after launch, so a self-hosted model menu that looked settled in spring is worth re-checking monthly.

The options at a glance (October 2026)

Which self-hosted route should you pick?

Match the route to the boundary you need and the operations you can afford, not to feature lists:

• One engineer, comfortable with SSH: the plain VM with tmux. Nothing to operate, every CLI works, and you can graduate later without redoing anything.
• You want a harness UI on your own machines and will operate it: OpenHands. MIT-licensed core, Docker deployment, and the only route on this page where the model can also be local with no commercial tier involved.
• Regulated or air-gapped enterprise with a platform team: Coder Agents. The whole platform runs in your VPC or enclave, against any hosted or self-hosted model endpoint.
• Already on Cursor or Warp Enterprise and the requirement is "execution inside our network": their self-hosted workers. Accept that prompts, orchestration, and inference still route through the vendor.
• A team that wants the plain-VM pattern shared and persistent without operating a harness: AQ, covered next.

Whichever route you pick, decide the model question separately: hosted frontier model under your own accounts and keys, or an open-weight model served locally when the policy requires that prompts never leave the network.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ is the plain-VM pattern turned into a team product. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, so sessions survive a closed laptop, and each one is streamed to the browser where teammates can open the same workspace and see and steer the same live session.

Custody follows the same lines as doing it by hand. Each engineer logs into the CLIs with their own Claude or OpenAI account (no inference markup, no shared vendor key), commits and PRs use per-user GitHub auth, and every workspace gets its own isolated git worktree so parallel tasks never collide. Live previews support pinned comments that can be sent straight to the agent, Linear issues flow in via an "ai-task" label, and there is no shared multi-tenant execution tier: your agents run on your VM. The glue is built in: runner health is visible in the product, the installer runs preflight checks, and an aq-runner doctor command diagnoses a broken host.

Pricing is two plans. The Free plan is a personal sandbox for one person, created by AQ with nothing to install. Self-hosting on VMs you bring, exactly what this guide covers, is part of the AQ Pro plan at $50 per user per month early access pricing (standard $200, billed monthly), which also includes a dedicated, always-on AQ-managed option, with your rate locked for your first 12 months.

Plainly: if you are one engineer and comfortable in tmux, the VM pattern above is enough, and you should use it. AQ earns its place when a team wants those same self-hosted sessions shared, persistent, and visible without building the glue.