Self-Hosted AI Coding Agents: Your Options in 2026

Published July 18, 2026 · by the AQ team

Self-hosting an AI coding agent means running the agent's execution environment (the machine where it reads your code, runs commands, and holds your credentials) on infrastructure you control. As of July 2026 there are four practical routes: run agent CLIs like Claude Code and Codex directly on a VM you own, deploy an open-source harness like OpenHands, 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.

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.
• 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 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, tmux sessions are in-memory so a reboot clears them, and nobody sees what agents are doing without logging in.

Option 2: OpenHands, the open-source harness

OpenHands is the most established fully self-hostable harness. As of July 2026 it is open source and typically run via Docker: the app serves a web UI and spawns sandboxed runtime containers where the agent edits files and runs commands. Kubernetes and a CLI launcher are also documented, and it can drive third-party agents such as Claude Code and Codex alongside its own.

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. That makes OpenHands one of the few options where every piece (harness, execution, even the model) can run inside your network.

The tradeoff: you operate it. The app needs Docker socket access to spawn sandbox containers (fiddly on locked-down hosts), and upgrades, persistence, and access control are your job.

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 announced self-hosted cloud agents in March 2026: worker processes on your own infrastructure, connecting outbound over HTTPS with no inbound ports, with a Helm chart and Kubernetes operator for large fleets. Cursor states that your codebase, tool execution, and build artifacts never leave your environment. The nuance: planning and model inference happen in Cursor's cloud, so the repository clone stays local but the context the model reads is processed on Cursor's side, as of July 2026.

Warp's Oz platform offers self-hosting on its Enterprise plan in two shapes as of July 2026: a managed worker daemon that connects out to Oz and executes tasks in Docker, Kubernetes, or directly on hosts, or an unmanaged mode where your own CI or scripts invoke the agent command. Repository clones, source files, build artifacts, and runtime secrets stay on your infrastructure. Warp's documentation is direct about the boundary: session transcripts, including code context in prompts, and LLM inference route through Warp's hosted service under Zero Data Retention agreements.

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 July 2026, Ollama and vLLM can serve models like the Qwen3-Coder family on your own GPUs, and both now speak an Anthropic-compatible API, so even Claude Code can point its base URL at a local endpoint, and nothing leaves your network at all. 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, and cover the prompt flow with the provider's enterprise data terms.

The options at a glance

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 matches the two ways teams own infrastructure. The Free plan is the full product where you bring your own VM and pay only your cloud provider. The Team plan is $100 per user per month (promotional; standard $200) and includes a dedicated, always-on VM managed by AQ in its own isolated network, 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.