Self-hosted AI coding agents (2026): OpenHands, Centaur, Cyrus
Self-hosted coding agents that turn tickets into PRs: OpenHands, Centaur, Cyrus, Claude Code on your own runners, and what running one actually costs you.
A self-hosted AI coding agent runs the ticket-to-pull-request loop on infrastructure you control, and in 2026 the real options are OpenHands, Centaur, Cyrus, Claude Code on your own runners, and Tembo's packaged build. Most coding agents run your repository on somebody else's machine, and for a lot of teams that is fine. For some it is a non-starter: a compliance rule, a customer contract, a preference for owning the tools the company depends on, or a bill that would look different if the machines were already paid for. If you are in the second group, the list is short, and it gets shorter once you separate "the source is open" from "the loop runs where I say." This post goes through what each option self-hosts and what it does not, and the operational cost you take on when you run any of them.
Checked in early September 2026 against each project's README, docs, and license file, linked throughout.
Sinatra is our product and it is hosted only: there is no self-managed build, and this post will not pretend otherwise. It is the post we would have wanted to read before deciding that, and it ends with when we think paying a vendor to operate the agent is the right call and when it is not.
What "self-hosted" means for an agent
An agent has three parts that can each live in a different place. The loop, meaning the harness that reads the ticket, edits files, and runs commands. The inference, meaning the model the loop calls. And the trigger, meaning the tracker or chat surface that hands work over.
Most products self-host one of these and market it as the whole thing. Claude Code lets you route inference through your own AWS or Google account while the trigger stays on GitHub. Tembo will put the loop in your VPC while you still buy the product. Only a couple of the projects below put all three where you control them, and even they depend on a model provider unless you run a local model, which for agentic coding is still a compromise.
Keep those three layers in mind and the marketing gets easier to read.
OpenHands: the full open-source platform
OpenHands is the reference answer. MIT licensed, more than 80,000 stars, and a real agent platform rather than a demo: a web UI, a CLI, an SDK, and editor integrations over ACP for Zed, JetBrains, and VS Code.
Running it yourself is a one-liner per the local setup docs: uv tool install openhands --python 3.12 and then openhands serve, or a docker run against the published image. The docs recommend a machine with at least 4 GB of RAM and Docker for the sandbox. On first launch you pick an LLM provider and paste a key, and the provider list is the widest in this category because OpenHands goes through LiteLLM: Anthropic, OpenAI, OpenRouter, Bedrock, Azure, Google, Groq, a LiteLLM proxy, or a local model.
Read the pricing page before you commit, because it splits the product in two. The free open-source build is, in the project's own words on its pricing page, "designed for a single user." The team-scale deployment with the openhands label on a GitHub issue as a trigger is OpenHands Enterprise, which installs with a Helm chart on Kubernetes and requires a commercial license; the install docs describe a 30-day trial and note that Kubernetes installation is available to select customers on request. So the loop and the inference self-host for free, and the tracker trigger at team scale is a paid product that also self-hosts. That is a reasonable split, and you should know which half you are looking at.
If someone on your team wants to own the agent, this is the project, and we wrote a longer OpenHands review separately.
Centaur: Slack-first agents on your Kubernetes
Centaur, from Paradigm, is newer and shaped differently. The README's one line is "Shared AI agents for teams. Talk to an agent in Slack, give it your tools, and let it run real work in a sandbox." It is dual licensed Apache-2.0 or MIT, created in May 2026, active daily, and past a thousand stars within its first few months.
Production Centaur is a Kubernetes deployment installed with Helm, with Postgres for state and one sandbox pod per conversation. Locally, the docs say a k3s cluster on a small VPS or a Mac Mini is enough. The harness inside the sandbox is pluggable, and the quickstart lists Codex as the default with flags for Amp, Claude Code, and Pi. The security design is the part worth studying even if you never run it: all sandbox egress goes through a per-sandbox proxy, the Helm chart applies a default-deny network policy to every pod, and per the architecture docs, "sandboxes only ever see placeholder strings for upstream credentials," with the real values swapped in by the proxy for specific hosts. That is the same shape as the credential boundary in our own sandboxes, and it is good to see it in an open codebase.
Centaur is not a ticket-to-PR agent, though. The trigger is a Slack mention, with optional Microsoft Teams and an HTTP API. The README does not mention GitHub issues or Linear at all, and a pull request is one thing the agent might produce rather than the artifact the product is built around. There is no hosted tier and no pricing. If your team's work starts in Slack threads and you want an open, self-hosted agent that can run real tools from there, it is the closest thing to that. For a tracker-driven backlog it is a different job.
Cyrus: Linear assignment, Claude Code, your server
Cyrus is the project for the reader who searched for this post because their backlog is in Linear. Its README describes it as "the Claude Code background agent for Linear, Slack, Github, GitLab etc. you deploy anywhere," and the mechanics are exactly the ones a Linear team wants: it monitors issues assigned to it, creates an isolated git worktree per issue, runs a session in Claude Code, Codex, Cursor, Gemini, or Opencode, and streams activity back to the ticket. It is Apache 2.0 and bring-your-own-key for tokens, subscriptions included.
The pricing is honest about what hosting means. The Community tier is free and self-hosted, and the pricing page is explicit that it requires your own Linear OAuth app, GitHub App, and Slack app, configured from the CLI. Pro at $50 a month "runs on your own server" with a managed Linear app and up to five Linear members, and Team at $120 raises the caps. So the loop is always yours to run; what you pay for is not having to register the apps.
It is a smaller project than the two above, a few hundred stars rather than tens of thousands, which is a reasonable thing to weigh for something your tracker will depend on. It is also the only thing on this page that does the Linear-assignment-to-pull-request loop on hardware you control, and that counts for a lot.
Claude Code on your runners and your cloud account
Anthropic's Claude Code is closed source, and its GitHub Action is the delegation path most teams already have installed, so it belongs here as a partial answer.
The inference layer self-hosts cleanly. The GitHub Action docs describe routing inference through your own Amazon Bedrock, Google Cloud, or Microsoft Foundry account with a single input, and the CLI has the same switches, so tokens are billed by your cloud provider under your existing agreement rather than by Anthropic. The loop is more mixed. The Action is an ordinary GitHub Actions workflow, and the Action's own README says it "executes entirely on your own GitHub runner," while Anthropic's docs describe GitHub-hosted runners and the Actions minutes they consume. For GitHub Enterprise Server, Anthropic documents the Action as supported with manual workflow setup. There is also a newer, separate beta for Team and Enterprise customers called self-hosted environments, which runs Claude Code's cloud sessions on a runner inside your network, with the caveat in its docs that inference on that path goes to the Anthropic API only.
The trigger stays on GitHub either way. There is no Linear assignment, which we covered in how to use Claude Code with Linear.
Tembo's self-hosted build
Tembo is a hosted agent product first, and its self-hosted overview describes a packaged release that runs "inside infrastructure you control," as a single instance on AWS, with Kubernetes and GCP support in early access and an Azure deploy page as well. The docs are clear about the division of labor: "You manage the infrastructure, networking, secrets, backups, and day-to-day operations of the environment," and Tembo supplies the release and support for upgrades. Which plan includes it is not stated; the page routes to a discovery call.
Tembo's hosted plans, for reference, are a free tier with a $10 one-time allowance for up to three users, Pro at $60 a month for up to five, and Max at $200 for up to ten, with bring-your-own-key and ChatGPT subscriptions accepted on every tier including free. It can run Claude Code, Codex, Cursor, Opencode, Amp, and Pi as the harness. If you want a commercial product with a Linear assignment trigger that can be deployed into your VPC, this is that.
What about SWE-agent and the research projects?
SWE-agent is MIT licensed and "takes a GitHub issue and tries to automatically fix it," from the command line, with a flag to open a pull request when it succeeds. It is a research system, its README says most development has moved to a successor, and there is no tracker trigger, sandbox management, or team story. Aider and Goose are excellent open-source agents for a terminal or a desktop and have no tracker trigger either. They are worth knowing about; they are not what this post is about.
What you take on when you host
Every one of the projects above hands you the same list, and it is longer than the install command suggests.
Sandbox isolation is yours. An agent runs untrusted code on the machine you give it, on purpose, and the ticket text it reads can be written by anyone who can file an issue. Someone has to decide whether each task gets a fresh container or a fresh pod, what it can reach on the network, and what happens to it afterward. Centaur's default-deny network policy is the right instinct and it is also the kind of thing that breaks a legitimate package install at 2am.
Credentials are yours. The sandbox needs a token that can push a branch, a model key, and whatever your test suite needs. Where those live, how they are scoped, and whether the agent process can read them in plaintext are decisions each project makes differently, and the careful ones, like Centaur's placeholder scheme, add operational complexity to get it right.
Upgrades and paging are yours. Model providers change APIs, harnesses ship weekly, and the agent that worked on Friday can stop on Monday. If the person who set it up leaves, the tracker integration they registered leaves with them.
And the merge gate is yours regardless. None of these agents should merge its own work, and the review load of agent-written pull requests does not shrink because the agent is on your hardware. We wrote about reviewing AI-generated PRs for exactly that reason.
When to self-host, and when to pay someone to operate it
Self-host when a rule requires it, when you have a platform engineer who wants to own it, or when the loop is central enough to your business that depending on a vendor for it is the bigger risk. OpenHands is the mature choice, Cyrus the Linear-shaped one, and Centaur the one to watch if Slack is where work starts.
Pay a vendor when nobody on the team wants the pager. That is the entire case for hosted agents, ours included. Sinatra's $20 per workspace member buys the sandboxes, the egress proxy with host-bound credentials, the tracker integrations, and the upgrades, and it deliberately buys nothing else: the model bill is your provider's or your subscription's, at their rate, with nothing added. We put the self-hosting row on our comparison hub as a plain no, next to the rows where the self-hosted projects win, because a matrix with no losses in it is an advertisement.
Common questions
Is there an open-source Devin?
OpenHands is the closest thing: an MIT-licensed agent platform with a web UI, a CLI, sandboxed execution, and a hosted cloud. It is single-user in its free build and a licensed Enterprise product at team scale. Nothing open source matches Devin's breadth of surfaces, and nothing needs to for the ticket-to-PR loop.
Can I self-host Sinatra?
No. There is no self-managed build and we do not describe one as coming. If self-hosting is a requirement, OpenHands, Cyrus, or Centaur are the projects to evaluate.
Which self-hosted agent works with Linear?
Cyrus, natively: it watches issues assigned to it and runs Claude Code or another harness per issue. OpenHands documents a Linear integration through webhooks on its cloud and Enterprise tiers. Centaur and SWE-agent have no Linear trigger.
Does self-hosting save money?
On tokens, no: every project here still calls a model provider, so the inference bill is the same whether the loop runs in your cluster or a vendor's. You save the seat and spend engineering time instead, on isolation, credentials, and upgrades. For a team already running Kubernetes with a platform engineer on staff, that trade is often worth it. For a ten-person startup, it usually is not, and we say so in what an agent costs a small team.
If you decide hosted is the right call and want the agent to start from a Linear assignment or a Sinatra label on a GitHub issue, running on your own key or subscription, you can start free and read how we sandbox coding agents for the boundaries we operate on your behalf.