Anthropic opened a public beta on August 6, 2026 that changes where Claude Code agent sessions actually run. Until now, every Claude Code cloud session executed on Anthropic-hosted compute. Starting this week, organizations on Team and Enterprise plans can route those sessions through their own servers — inside their own network, next to their internal tooling, under their own compliance posture. It is not for everyone. But for the teams it is built for, it removes the biggest blocker to enterprise Claude Code adoption.
How Self-Hosted Environments Work #
The architecture maps cleanly to something most DevOps engineers already understand: self-hosted CI runners. Three components do the work.
An environment is a named destination you create in your claude.ai admin settings. It groups a set of runners. A runner is a long-lived process you deploy on hosts inside your network — it picks up sessions and starts a Claude Code process for each one. A session is a single Claude Code task a developer initiates, running in isolation with its own checkout so work does not bleed between users.
Runners come in two modes. Fixed mode keeps a set number of runners always running; sessions distribute across whichever runner is available. On-demand mode adds an autoscaling orchestrator — a second process you host — that starts runners as sessions queue and stops them when work finishes. Fixed mode is operationally simpler. On-demand mode requires running two processes instead of one, but capacity tracks demand automatically.
Critically: model inference still goes to Anthropic API. You are not running Claude on your own hardware. What stays on your machines is the execution context — repo checkouts, build artifacts, secrets, and the files a session creates or modifies.
Who Actually Needs This #
Anthropic is direct about this in its own documentation: most teams are better served by Anthropic-hosted environments, which require no infrastructure to run or maintain. Self-hosted is the exception, not the default.
The teams with a genuine case for it are specific. Organizations with compliance mandates that require code to never leave their infrastructure — SOC 2 audit requirements, HIPAA controls, or procurement contracts with “our vendor does not touch our source code” language — have a real use case. Teams where Claude Code needs to reach internal services that are not accessible from Anthropic cloud (private package registries, air-gapped databases, internal APIs behind a VPN) have another.
If you are not in one of those buckets, the cloud environment is almost certainly the right call.
The ZDR Problem Nobody Is Covering #
Here is the detail most coverage has missed: organizations that use Zero Data Retention (ZDR) cannot use self-hosted environments. The two are mutually exclusive.
ZDR is Anthropic compliance-oriented option where prompts and responses are processed in real time and not stored after the response returns. It is available to qualified Enterprise accounts and requires separate enablement by Anthropic account team. Many compliance-focused enterprises that wanted data control went the ZDR route.
Those organizations cannot also use self-hosted environments. The feature most likely to appeal to compliance teams is blocked for the compliance teams that moved earliest. If your organization enabled ZDR to satisfy a compliance requirement, you need to evaluate whether self-hosted environments could replace ZDR as your compliance mechanism — or whether the two requirements are actually different enough that you need both, which you cannot have.
The Operational Overhead Is Real #
Anthropic announcement post is explicit about something that usually gets buried in press releases: self-hosted environments require a platform, developer experience, or developer productivity team to own setup and ongoing operation. This includes building and maintaining the runner image, updating runners when dependencies change, and running the orchestrator if you are using on-demand mode.
That is a non-trivial operational commitment. Runner images need security patching. The orchestrator needs uptime monitoring. Fleet capacity needs planning. If your organization does not have a team that can absorb this work, the operational cost will outweigh the compliance benefit.
Self-hosted CI runners are the right mental model here. Teams that have never run self-hosted GitHub Actions runners should be honest about whether they have the capacity to operate a Claude Code runner fleet before enabling this.
Setting It Up #
If you have assessed the above and self-hosted environments are the right fit, the path is straightforward. An Owner or admin enables Allow self-hosted environments in the Cloud environments section of claude.ai admin settings. Note that Claude Code on the web must already be enabled for the organization. From there, you create a named environment, install Claude Code on your runner hosts, and start runners using the claude self-hosted-runner
command.
claude self-hosted-runner
The official quickstart walks through each step. For a fuller picture of what you are signing up for operationally, the self-hosted environments documentation covers runner modes, network configuration, and availability limitations in detail.
The Bigger Picture #
Self-hosted environments fit a pattern visible across the agentic AI space in 2026. Cloudflare launched compute primitives for agent execution. GitHub shipped agentic workflow infrastructure. Anthropic is now adding runner infrastructure to Claude Code. The common thread: every major AI platform that started with cloud-only execution is building self-hosted options because enterprise procurement demands it.
That is the real news here. Not just that Claude Code can run on your hardware — but that Anthropic is investing in the enterprise infrastructure layer required for large organizations to adopt agentic AI without handing over their code to a cloud they do not control.