Claude Code Self-Hosted Environments Move Execution, Not Inference

Anthropic's new beta runs agent sessions on machines you own, inside your own network. The prompts, the tool results, and the code Claude reads still leave the building.

The architecture diagram Anthropic published for self-hosted environments is the most honest thing in the announcement. There is a box labeled with your network boundary. Inside it sit a runner, two Claude Code session processes, and your git host. Outside it sits api.anthropic.com, holding the queue, the session stream, and inference. Every arrow points outward. Nothing points in.

That drawing tells you precisely what the feature does and precisely what it does not do, and the distance between those two things is where a lot of compliance reviews are about to go wrong.

Self-hosted environments went to public beta on August 6, on Team and Enterprise plans, off by default. The pitch is simple enough to repeat in a meeting: Claude Code cloud sessions, the ones developers start from claude.ai, the mobile and desktop apps, a scheduled routine, or claude --cloud, now execute on hardware your organization operates instead of on Anthropic's. Read that sentence again and notice which word is carrying the weight. Execute.

What actually moved

The system has three parts, and they map cleanly onto self-hosted CI, which is the mental model to use.

An environment is a named destination your org creates in claude.ai admin settings. A runner is a long-lived process you deploy on a host inside your network, which registers with the environment and polls for work. A session is one Claude Code task, running as a child process the runner spawns.

When a developer starts a cloud session and picks your environment, Anthropic's control plane drops it on that environment's queue. A runner with free capacity claims it, takes a lease, clones the repository into its working directory, and starts a Claude Code process on your machine. The child streams events back over HTTPS while the runner keeps polling, and each poll refreshes the lease and doubles as a heartbeat. Stop polling for about sixty seconds and the server hands the session to another runner.

Two design choices in there are worth pausing on.

First, a runner serves one user at a time. The first session it picks up locks it to that user's account, and it runs only that account's work until it drains. That is the isolation model: checked-out code never mixes between users, and the runner never has to scrub disk state between them. It also means your minimum fleet size is the number of people you expect to be active simultaneously, not the number of sessions.

Second, the default --drain-grace-sec is 0, so a runner exits as soon as its active sessions finish rather than polling for more. Kubernetes restarts it with a fresh disk, ready to serve anybody. The ephemerality is deliberate, and it is the part that makes the one-user lock affordable.

The claim underneath the claim

Anthropic's own documentation says what stays and what goes, in plain terms. Repository checkouts, build artifacts, secrets, and any files a session creates or modifies stay on machines you provision. The conversation, including prompts, responses, and tool results, goes to api.anthropic.com for inference. The launch post is even more direct about the awkward part: tool results "can include code that Claude reads." And the transcript is stored on Anthropic's side so a session can be resumed from another surface.

So here is the position I would take into a review. Self-hosted environments answer three real questions and leave a fourth one untouched.

They answer network access: sessions run next to your internal services, databases, and registries without you exposing any of it to the public internet. They answer tooling: you bake compilers, SDKs, and internal CLIs into the runner image so every session starts ready to build. They answer artifact residency: checkouts and build output live on your disks.

They do not answer "does a model provider see our source code." The answer to that is still yes, by design, and the feature was never built to change it.

There is a sharper version of this that catches the exact teams most likely to want self-hosting. Sessions in a self-hosted environment use the Anthropic API directly. The control plane hands each session an endpoint and a session-scoped OAuth token, and inference cannot be routed through Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, or an LLM gateway. If your org spent the last year putting every model call behind a gateway for logging, budget control, and egress policy, self-hosting takes that away in exchange for moving the compute. Organizations running Zero Data Retention cannot use the beta at all.

That is not a knock on the design. It is a description of a tradeoff that reads backwards from the marketing frame, and it is the kind of thing that gets discovered in week three of a rollout rather than week one.

Putting this into practice

The lowest-friction way to make the right call here costs about ten minutes and no infrastructure.

Write down your actual requirement as a sentence. Not "we need self-hosting." The literal control. If it reads "source code must not be transmitted to third-party model providers," this beta does not satisfy it, and no amount of runner configuration will change that. If it reads "repository checkouts, secrets, and build artifacts must remain on infrastructure we operate" or "agent sessions must be able to reach internal services without those services touching the public internet," this beta satisfies it well.

Check whether you even have the problem. Sessions in a terminal or IDE already run on the developer's own machine. If your team does not use cloud sessions, there is nothing here to configure. If you want one always-on machine you drive from a phone, that is Remote Control, which is a different feature and available on Pro and Max.

Start on-demand, not fixed. The autoscaling orchestrator is a second process you host that starts a runner when a session queues and lets it exit when the work finishes. You get the compliance story without paying for standing capacity while you are still deciding whether this is worth owning.

Size for concurrent humans. The one-user runner lock means fleet math is people, not tasks.

Set the memory limit before you learn why it exists. Version 2.1.233 added opt-in Linux cgroup limits for Bash tool commands through CLAUDE_CODE_TOOL_MEMORY_LIMIT, so a runaway build cannot stall the session. On a shared runner fleet, that is a day-one setting, not a tuning knob.

Pass --retire-at if your hosts die on a schedule. Spot reclamation and sandbox lifetime caps kill machines without a signal, and without that flag the control plane cannot tell the difference between a planned shutdown and a crash. With it, the runner stops taking work, releases active sessions cleanly, and the user's next message resumes on a fresh runner.

Build session-identity checks early. Anthropic ships a page on validating the session token from your own services before granting access. A runner sitting inside your network next to your databases is a new principal in your trust model. Treat it like one on day one rather than after the first incident.

Where this breaks

The exclusions are longer than the announcement suggests, and most of them will matter to somebody.

Zero Data Retention organizations are locked out. Inference cannot go through Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, or an LLM gateway. Claude Tag, Claude Security, and Code Review sessions do not route to self-hosted environments yet. Repository checkouts come from GitHub. Windows is not supported as a runner host, and the quickstart tells Windows fleets to run the runner in a Linux container instead.

Billing does not change. Sessions in your environment consume your organization's Claude Code usage exactly as hosted sessions do, so you are paying for the compute and the usage.

And the operational cost is real enough that Anthropic says it twice. The company recommends its hosted offering for most enterprises and tells you to plan for a platform or developer-productivity team to own the runner image, the fleet, the updates, and the orchestrator. That is a standing headcount commitment attached to a public beta, and public betas move.

There is a smaller failure mode worth knowing: a turn that outlives a host kill is lost. Not corrupted, not resumed, lost. Sizing the shutdown margin is on you.

The part I keep coming back to

Two things happened in the same week. Execution moved onto customer hardware where a vendor's telemetry does not reach, and OpenAI previewed a mode running the same weights at up to 750 output tokens per second on Cerebras hardware. Those are unrelated launches from rival companies, and together they describe the direction: agent work is getting faster and less visible to the people who used to be able to watch it.

Self-hosted environments are a good feature. They solve a category of problem that genuinely blocked teams, and the documentation is unusually candid about the boundary. The risk is not the design. The risk is a security reviewer reading the words "self-hosted" and mentally filing it under air-gapped, then approving a workflow on that basis.

Read the diagram. Every arrow points outward, and none of them stop at your firewall. Decide what you are actually buying, then go buy it on purpose.

Sources: Anthropic, "Run Claude Code sessions on your own compute" (Aug 6, 2026); Claude Code docs, "Self-hosted environments"; Claude Code release v2.1.233; Claude Code changelog.