Claude Code now runs cloud sessions inside your own network — but your prompts still go to Anthropic, and that distinction is the whole story
TL;DR: On 13 August 2026 Anthropic opened a public beta of self-hosted environments for Claude Code, letting Team and Enterprise organizations run cloud agent sessions on infrastructure they operate instead of Anthropic’s. What stays in your network: repository checkouts, build artifacts, secrets, any files a session touches, and agent access to internal services, databases and registries without exposing them to the public internet. What still leaves: the conversation itself — prompts, responses and tool results go to api.anthropic.com for inference, and Anthropic stores the session transcript. Crucially, inference cannot be routed through Amazon Bedrock, Google’s Agent Platform, Microsoft Foundry or an LLM gateway here — so this is not a data-residency tool. It relocates execution, not inference. You run “runners” (like self-hosted CI runners) in fixed or on-demand autoscaling mode; Anthropic never connects into your network (all outbound HTTPS). Limits: off by default, GitHub repos only, Zero Data Retention orgs excluded, and Claude Tag / Security / Code Review sessions don’t route yet. You pay normal Claude Code usage plus the compute and the engineering to run it. The one thing to get right: if your compliance need is “the agent must reach our internal systems,” this fits. If it’s “our prompts must never leave our control,” it does not — use Bedrock or Vertex instead.
What Anthropic actually launched
On 13 August 2026, Anthropic put self-hosted environments for Claude Code into public beta. The one-line version — “run Claude Code sessions on your own compute” — is accurate but easy to over-read, so it is worth being precise about the scope.
This applies only to cloud sessions: Claude Code tasks started from claude.ai, the mobile and desktop apps, a scheduled routine, or the terminal with claude --cloud. Those are the sessions that, by default, execute on Anthropic’s infrastructure. Ordinary sessions you run in your terminal or IDE already run on your own machine — there was never anything to move there. Self-hosted environments take that one category of Anthropic-hosted execution and let a Team or Enterprise organization run it inside its own network instead.
The architecture is deliberately familiar to anyone who has run CI:
- An environment is a named destination that appears in the session picker, grouping a set of runners.
- A runner is a long-lived process you deploy on your hosts. It registers with the environment, polls Anthropic’s control plane for queued work, claims a session, clones the chosen repository, and spawns a child Claude Code process to do the task. Anthropic describes it as “the same idea as a self-hosted CI runner.”
- A session is one Claude Code task, running as a child process the runner spawns.
You can operate a fixed fleet of always-on runners, or run the on-demand autoscaling orchestrator, a second process you host that starts runners as sessions queue and lets each exit when its work is done. Either way you configure the environment once and it shows up on every supported surface. A runner locks to one user’s account when it claims its first session, so checked-out code never mixes between users — a neat isolation property for shared infrastructure.
One reassuring design fact: Anthropic never connects into your network. Every path — control-plane polling, the session event stream, git, and inference — is outbound HTTPS from your hosts to api.anthropic.com. There is no inbound hole to open. Corporate egress proxies and mTLS are supported.
The distinction that decides everything
Here is the line that matters more than any feature in the announcement, quoted from Anthropic’s own documentation:
Repository checkouts, build artifacts, secrets, and any files a session creates or modifies stay on the machines you provision. The conversation itself, including prompts, responses, and tool results, goes to
api.anthropic.comfor model inference, and Anthropic stores the session transcript so you can resume the session from another supported surface.
Read that twice. Self-hosting moves execution into your network. It does not move inference. Your code’s contents, the model’s outputs, and every tool result still travel to Anthropic to be processed, and the transcript is retained. The control plane — queueing, orchestration, the claude.ai interface — also stays Anthropic-hosted.
And the beta closes the obvious escape hatch on purpose. In a self-hosted environment, sessions authenticate with an Anthropic-issued, session-scoped token, and inference “can’t be routed through Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, or an LLM gateway.” If your reason for wanting “self-hosted” was to keep inference in your own cloud tenancy or a specific region, this feature is the wrong instrument — that is precisely what the Bedrock and Vertex routes exist for, with IAM-scoped, in-account, in-region inference. Self-hosted environments and cloud-provider routing solve two different compliance questions, and some organizations will need both.
What self-hosting is genuinely good for
Set aside the privacy misread and the feature is a real answer to a real, common enterprise blocker. Anthropic frames the payoff as three things, and each is concrete:
- Network access. Sessions run inside your network and can reach internal services, databases, package registries and staging environments “without exposing them to the public internet.” For a lot of teams this is the actual reason cloud agents were a non-starter — the agent could not see the systems it needed to work against. This removes that wall.
- Custom tooling. You bake compilers, SDKs and internal CLIs into your runner image, so every session starts ready to build against your stack rather than a generic sandbox.
- Execution compliance. Repository checkouts, secrets and build artifacts stay on infrastructure you control and govern, satisfying policies that forbid source and artifacts leaving your environment — even though the prompt content still transits for inference.
That combination — an autonomous agent that can touch your internal infrastructure while keeping code and artifacts on your machines — is the genuine unlock, and it is why this is aimed squarely at regulated and security-conscious engineering orgs rather than individual developers.
Why this matters
1. It reframes what “self-hosted AI” means. The phrase implies air-gapped privacy to most buyers. Anthropic’s version is narrower and more honest: local execution, remote inference. That is a meaningful capability, but the gap between what the phrase suggests and what it delivers is exactly where a compliance sign-off goes wrong. Anyone evaluating this should map their requirement to the right layer before they build.
2. It is a direct answer to the enterprise objection to agents. As Claude Code’s default posture grows more autonomous, the blocker for large organizations was never only “will it run something dangerous” — it was “can it even reach our systems, and does our code leave the building.” Self-hosted environments answer the second half and part of the first, which is what it takes to get agents past a security review at a bank or a hospital.
3. The operational cost is the real price. There is no surcharge for the feature — sessions consume your normal Claude Code usage — but Anthropic is unusually blunt that “most teams are better served by Anthropic-hosted environments.” You own the runner image, the fleet, the orchestrator and the network. That is standing engineering headcount, and it is only worth it when a specific requirement forces your hand.
4. It slots into a broader data-governance story. Teams already wary after the Claude Code China-routing telemetry episode and working through EU AI Act obligations will read this as a governance lever — a useful one, provided they understand it governs execution and artifacts, not inference.
Honest caveats
- This is not private inference. The single most important limitation: prompts, responses and tool results go to
api.anthropic.com, and transcripts are stored. For inference-locality or data-residency requirements, use Bedrock, Vertex or Foundry, which self-hosted environments explicitly do not support. - It is a beta with real gaps. Team and Enterprise only, off by default, requires Claude Code on the web enabled, Zero Data Retention orgs are excluded, repositories must be on GitHub, and Claude Tag, Claude Security and Code Review sessions do not route to self-hosted environments yet.
- You are taking on infrastructure. Building and maintaining runner images, operating the fleet, and running the autoscaling orchestrator is ongoing platform work. Anthropic itself recommends the hosted option for most teams.
- The control plane stays Anthropic-hosted. Session orchestration, queueing and the interface remain on Anthropic’s side; you are not running an isolated system, only relocating execution.
The verdict
Self-hosted environments are a serious, well-scoped feature — one of the more meaningful moves toward making autonomous coding agents deployable inside regulated organizations. The recommendation is simple: adopt it when your blocker is that the agent must run next to internal systems and your source and artifacts must not leave your machines. Do not adopt it expecting your prompts to stay private — that is a different layer, served by Bedrock or Vertex. For most individuals and small teams, Anthropic’s hosted environments remain the right default; see the full Claude Code review and the best AI harnesses roundup for where it sits against Cursor and the rest of the field. Match the tool to the layer your compliance team actually cares about, and this is a strong addition to the enterprise toolkit.
Frequently asked questions
What are self-hosted Claude Code environments, and who can use them?
They are a public-beta feature, launched 13 August 2026, that lets a Team or Enterprise organization run Claude Code cloud sessions on infrastructure it operates instead of on Anthropic's servers. A 'cloud session' is any Claude Code task started from claude.ai, the mobile or desktop app, a scheduled routine, or the terminal with 'claude --cloud' — the ones that normally run on Anthropic's compute. It is off by default; an Owner or admin must enable it, and it requires Claude Code on the web to be turned on for the org. Ordinary terminal and IDE sessions already run on the developer's own machine, so if your team doesn't use cloud sessions there is nothing here to configure.
Does self-hosting mean my code and prompts stay private and never leave my network?
No — and this is the most important thing to understand. What stays on your infrastructure is session execution: repository checkouts, build artifacts, secrets, and any files a session creates or modifies. What still leaves is the conversation itself — prompts, responses and tool results all go to api.anthropic.com for model inference, and Anthropic stores the session transcript so you can resume from another surface. Self-hosting relocates where the agent runs and what it can reach, not where inference happens. If your requirement is that prompt and code content never leave your control, this feature does not deliver that on its own.
How is this different from running Claude Code through Amazon Bedrock or Google Vertex?
It solves a different problem. Bedrock, Google Cloud's Agent Platform and Microsoft Foundry give you in-account, in-region inference under your own cloud IAM and billing — that is the route for data-residency requirements. Self-hosted environments deliberately do not support those backends: inference uses the Anthropic API with a session-scoped token and 'can't be routed through Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, or an LLM gateway.' So if you need inference to stay in a specific region under your account, choose a cloud route. If you need the agent to run next to internal services it must reach, choose self-hosting. Some organizations will need both, for different reasons.
What does it take to set up, and what are the limitations?
You run 'runners' — long-lived processes on your hosts, conceptually like self-hosted CI runners — grouped into a named 'environment' that appears in the session picker. You can keep a fixed fleet running or use the autoscaling orchestrator that spins runners up on demand and shuts them down when work finishes. Anthropic never connects into your network; all traffic is outbound HTTPS. You own building and maintaining the runner image, operating the fleet and controlling its network. Limits in beta: Team and Enterprise only, off by default, Zero Data Retention orgs are excluded, repositories must be on GitHub, and Claude Tag, Claude Security and Code Review sessions don't route to self-hosted environments yet.
Does it cost extra?
There is no separate charge for the feature itself, but you pay twice in a different sense: sessions in a self-hosted environment consume your organization's normal Claude Code usage exactly as Anthropic-hosted sessions do, and on top of that you carry the full operational cost of the compute you provision plus the engineering time to build, secure and maintain the runner fleet and orchestrator. Anthropic is explicit that most teams are better served by its hosted environments; self-hosting is worth it only when a real network, tooling or compliance requirement justifies owning that infrastructure.
Sources
- Anthropic / Claude — Self-hosted environments for Claude Code (claude.com/blog)
- Claude Code Docs — Self-hosted environments
- Unite.AI — Claude Code sessions can now run on infrastructure your team controls
- EdTech Innovation Hub — Anthropic opens self-hosted Claude Code beta to Team and Enterprise customers
- Enterprise DNA — Claude Code can now run on your own infrastructure
Related tool reviews
Questions or corrections? Email Pick Right. Want the full list? See all news.