What a Client Is Actually Asking For
When a client says they want Claude Code self-hosted, they're asking you to run the software that executes Claude Code's cloud sessions on infrastructure they control instead of on Anthropic's. That's a real, separate system: a runner process that lives on hosts inside their network, registered against an environment their organization sets up in admin settings. It is not a checkbox on your side, and it's not something you can quote at your normal build rate.
The distinction matters because the phrase self-hosted gets used loosely. Some clients mean this specific feature. Others mean I don't want you sending our code to a chatbot, which is a much smaller ask you can usually answer without touching infrastructure at all, see [is Claude Code safe for client work](/blog/is-claude-code-safe-for-client-work) for how I handle that version of the question. Find out which one you're actually being asked before you price anything.
What Actually Changes vs. a Normal Build
Anthropic-hosted vs self-hosted, on the client's side
| Anthropic-hosted (default) | Self-hosted environment | |
|---|---|---|
| Who runs the infrastructure | Nobody, it just works | The client's org (or you, if you're the one setting it up) |
| What's needed | Nothing extra | A runner fleet: hosts, a runner image, network egress rules, ongoing operation |
| What stays on their infrastructure | Nothing, everything runs on Anthropic's side | Repository checkouts, build artifacts, and secrets |
| What still leaves their network | Everything | The conversation itself - prompts, responses, tool results - still goes to Anthropic's API for the model to run |
| Billing | Standard Claude Code usage | Same standard Claude Code usage, plus the infrastructure cost |
That last row is the one clients miss, and it's the one you need to say out loud before you quote anything. Self-hosting doesn't remove Anthropic from the picture. The model still runs on Anthropic's API, so the actual conversation, meaning the prompts and responses, still leaves their network for inference. What self-hosting buys them is that the code itself, the checkouts and build artifacts and secrets, never leaves infrastructure they control. If a client is picturing something fully air-gapped, correct that before you scope the work, not after you deliver it.
Why a Client Would Actually Need This
There are legitimate reasons to ask for it, and knowing them is how you tell a real requirement from a client who just heard the phrase somewhere and liked the sound of it.
- Their sessions need to reach internal services, databases, or private registries without exposing them to the public internet.
- They want compilers, internal CLIs, or proprietary SDKs pre-installed so every session starts ready to build against their own stack.
- A compliance or security policy specifically requires that repository checkouts and build artifacts stay on infrastructure they control.
If none of those apply, don't sell it. Even Anthropic's own guidance is blunt about this: most teams are better served by the hosted default, which needs no infrastructure to run or maintain. Talking a client into paying for infrastructure they don't need is the kind of sale that comes back to bite you in month three, when nobody on their side wants to own the runner fleet you built.
The Infra Line: How I Split the Quote
This is the rule I use inside the club, and it's simple: the build is one line item, and where it runs is a separate one. I call it the Infra Line, the point in a proposal where what I'm building stops and what it takes to run this on your infrastructure starts. Everything on the build side of that line is priced the way I'd price any other project. Everything on the infrastructure side gets its own number, because it's a different kind of work with a different kind of risk.
Concretely, standing up a self-hosted environment means someone builds and maintains a runner image, decides how the fleet scales, configures network egress and git credentials, and keeps it running as Claude Code's own requirements change. That's DevOps work. If you're the one doing it, price it as DevOps work, not as a few extra hours tacked onto a build estimate.
- Quote the build normally, on whatever pricing model you already use for the actual application work.
- Quote the infrastructure separately, either as a fixed setup fee for standing up the runner and environment, or an hourly DevOps rate if the client's network is complicated enough that you can't scope it tightly up front.
- Add an ongoing line if you're the one keeping it running. A self-hosted environment isn't set up once and forget it, runner images need updates, capacity needs adjusting as usage grows, and someone has to be the person who gets paged when a runner stops picking up sessions.
What I Actually Say When a Client Asks For This
I don't lead with a price. I lead with the question that tells me whether they need it at all: what's the specific reason you need this self-hosted, versus the standard setup? If they have a real answer, network access, internal tooling, or a compliance requirement, I scope the infrastructure work properly and quote it as its own line. If the answer is vague, general unease about AI tools, or something they read once, I walk them through what self-hosting actually changes and let them decide with the full picture instead of the buzzword.
Put This in the Contract, Not Just the Quote
Whatever you agree, write it down as its own scope item, separate from the build. Name who owns ongoing maintenance of the runner fleet once the project ships, because that's the question that causes friction later if it's left implicit. See [what to put in an AI project contract](/blog/what-to-put-in-an-ai-project-contract) for the rest of what belongs in there alongside it.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
What does self-hosted Claude Code actually mean?
It means the client's organization runs the runner process that executes Claude Code's cloud sessions on their own infrastructure, instead of those sessions running on Anthropic's infrastructure by default. It's a public beta available on Team and Enterprise plans, off by default, and setting it up means building and maintaining a runner fleet, not flipping a toggle.
Does self-hosting stop code from ever leaving the client's network?
No, and this is the correction to make before you quote anything. Repository checkouts, build artifacts, and secrets stay on the client's infrastructure, but the conversation itself, the prompts and responses, still goes to Anthropic's API because that's where the model runs. If a client is picturing something fully air-gapped, self-hosting doesn't get them there on its own.
How should I price a self-hosted setup for a client?
Separate it from the build entirely, what I call the Infra Line. Quote the application build the way you normally would, then price the infrastructure work, the runner image, network configuration, and ongoing maintenance, as its own line, either a fixed setup fee or a DevOps hourly rate. Don't fold it into your standard build estimate.
Should every security-conscious client get a self-hosted setup?
No. Anthropic's own guidance is that most teams are better served by the standard hosted setup, which needs no infrastructure to run. Ask what the specific reason is before you scope anything, real network access needs, internal tooling requirements, or a compliance policy are legitimate reasons. General unease about AI tools usually isn't, and it's a smaller conversation you can answer without touching infrastructure at all.
Last reviewed by Duncan Rogoff on August 23, 2026
