The most common objection to autonomous coding agents isn't capability — it's custody. "The agent is fine; sending our monorepo to someone else's cloud is not." Self-hosting answers that objection, and the good news is that it's less exotic than it sounds: our own production fleet is ten agent workers on a $22/month Hetzner box. This post covers why teams self-host, what the hardware and setup really require, how bring-your-own API keys change the economics against subscription seats, and the two failure modes that will bite you if you skip the guardrails.
Why teams self-host a coding agent
Three reasons come up in nearly every conversation we have with teams that rule out cloud-hosted agents, and they're all boring in the best way.
Custody. On a self-hosted agent, your code is cloned onto a machine you control, the diff is produced on that machine, and the PR is pushed from it. The only thing that leaves your infrastructure is the context sent to the LLM API — prompts and file excerpts — and if even that's unacceptable, an open-source stack pointed at a local model keeps the loop entirely on your metal.
Compliance. If you're under SOC 2, HIPAA, or a customer contract that names where source code may reside, "our vendor's multi-tenant sandbox" is a data-processing conversation you'd rather not have. "A VM in our own VPC" usually isn't a conversation at all — it's the same posture as your CI runners, which your auditors already signed off on.
Cost control. A self-hosted agent has two cost lines: a server you can price to the cent, and LLM API usage you can cap at the provider. No per-seat multiplication, no metered "agent compute units", no overage clause. We've written before about why a hard cost ceiling is the feature that lets finance approve an agent; self-hosting gives you that ceiling by construction.
The trade is operational: you own upgrades, monitoring, and the 2 a.m. disk-full alert. The rest of this post is about how small that trade has become.
The real requirements: our production setup
Here's the field report. Codowave's production workers — the fleet that
turns tracker issues into PRs for our customers — run on a single
Hetzner dedicated vCPU box that costs about $22 a month. That machine
runs 10 concurrent agent workers under docker-compose, each worker a
container that clones a repo, works the issue, runs the tests, and
pushes a branch.
The reason the requirements are modest is worth understanding, because
it kills the most common sizing mistake. An agent worker is not a
GPU workload. Inference happens at the LLM provider; the worker itself
is doing what your CI runner does — git operations, file I/O, and test
runs — plus long stretches of waiting on API responses. Sizing an agent
box like an ML box is how you end up paying for an A100 to run
git clone and pytest.
What a worker actually needs:
- 1–2 vCPUs and 1–2 GB RAM per concurrent worker, dominated by whatever your test suite needs.
- Disk for repo clones and Docker layers — 20 GB per worker is a comfortable floor, SSD strongly preferred for install steps.
- Outbound HTTPS to your git host and your LLM provider. No inbound ports; the agent polls and pushes.
- Docker, since every serious agent stack sandboxes execution in containers.
That's the whole list. The setup itself, for Codowave's self-hosted
option, is a docker-compose up with your git token and LLM key in an
env file — the same shape as self-hosting a GitLab runner. Open-source
stacks land in the same place:
OpenHands (formerly
OpenDevin, MIT-licensed core) runs its agent runtime as a Docker
sandbox on any machine you own and takes any LLM backend, and
Aider is a pip install that works your local
git repo directly and can point at
any OpenAI-compatible endpoint,
including a local model via Ollama if the code truly cannot leave the
building.
The honest caveat on sizing: the ten-worker figure is for backlog work — scoped issues with test suites that run in minutes. If your test suite takes 40 minutes and 8 GB of RAM, your worker density drops accordingly. Benchmark with your own repo before you commit to a number.
API key economics vs subscription seats
Self-hosting usually means bring-your-own-key, and BYOK changes the shape of the bill, not just the size.
A seat-based cloud agent prices per human: $20–40 per developer per month, usage metered on top for the heavier products — we've run the math on Devin's ACU model elsewhere. Ten developers is ten seats whether they delegate two issues a month or two hundred.
A self-hosted BYOK stack prices per work done. The server is fixed — our $22 box — and the API line scales with issues attempted, not heads. A scoped bug fix on a current frontier model typically costs tens of cents to low single-digit dollars in tokens; a multi-file feature runs a few dollars. Run 150 issues in a month at an average of $1.50 in tokens and the entire stack — server included — lands under $250 for the whole team, with per-PR economics you can read straight off the provider's usage dashboard.
The crossover logic is simple. Seats win when usage per developer is high and headcount is low. BYOK wins when the team is large relative to its delegated volume, or when volume is spiky — nobody refunds a seat for a quiet sprint. And BYOK has a property seats can't offer: the provider-side spend cap. Set a monthly limit on the API key and the worst-case month is a number you chose, not a number you discover.
The cost that doesn't show up on either invoice is your time. Budget a day for initial setup and something like an hour a month for upgrades and disk hygiene. If an engineer-hour costs your company $100, that overhead is real money at small scale — a solo developer paying $20 for a managed seat may be making the right call. The math flips somewhere around the point where the seat line items outgrow one engineer-day a month.
Failure modes: runaway loops and token burn
Every team that self-hosts an agent eventually meets the same two incidents. Both are cheap to prevent and expensive to discover.
The runaway loop. An agent hits a failing test it can't fix, and retries — edit, run, fail, edit — for hours. Each iteration re-sends a growing context window, so cost accelerates rather than accumulates. The fix is boring: a wall-clock timeout per issue, an iteration cap per session, and a rule that a stuck issue gets parked for a human instead of retried. Codowave ships with per-issue iteration limits for exactly this reason — not because loops are rare, but because they're certain.
Token burn without a meter. On a subscription, a bad week costs you the subscription. On BYOK, a bad week costs whatever you let it. Three guardrails, in priority order:
- A hard spend cap at the LLM provider — the one limit that holds even when your own code has the bug.
- Per-issue token budgets in the agent, so one pathological ticket can't eat the month.
- A daily spend alert at a threshold that would make you look, set before the first incident rather than after.
There's a second guardrail category that has nothing to do with money:
an agent on your server holds a git token and executes code it wrote
itself. Scope the token to the repos it works, keep execution inside
the container sandbox, and never let the agent's branch reach main
without a human review. We've published a full
security checklist for AI coding agents
— threat model, token scopes, prompt-injection via issue text — and
every item in it applies double when the agent runs on your own box,
because there's no vendor between the agent and your network.
Self-hosting doesn't remove the failure modes of an autonomous agent. It moves them onto hardware where you can see them — which is the point.
Deciding whether to self-host comes down to one comparison: a day of setup plus an hour a month of upkeep, against whichever of custody, compliance, or cost control is blocking you today. For our part, the production numbers have stayed dull for months — ten workers, one $22 box, and an API bill that ends the month at the cap we set. Dull is what you're buying.