Claude Code Can Now Run Inside Your Own Infrastructure
Self-hosted runners keep source code, secrets and build artifacts on machines the client controls.
On 6 August 2026 Anthropic opened a public beta of self-hosted environments for Claude Code. Until then, a cloud session — one started from a browser, a phone or a scheduled routine rather than from a developer's own laptop — ran on Anthropic's machines. With the beta, an organisation can send those sessions to runners it operates itself, on hosts inside its own network.
The mechanics will be familiar to anyone who has ever configured a self-hosted CI runner. You create a named environment in the Claude admin settings, install the Claude Code binary on a Linux or macOS host, and start a runner process with the environment's secret. The runner polls Anthropic's control plane over outbound HTTPS, claims queued sessions, clones the repository and spawns a Claude Code process locally. Nothing connects inward — Anthropic never opens a connection into your network.
Runners come in two shapes. You can keep a fixed number of them running, or deploy an orchestrator that starts a runner when a session appears in the queue and lets it exit once the work is finished, so capacity follows demand. Either way, a runner locks onto the first user whose session it claims and serves only that account until it exits. That is the mechanism that keeps one person's checkout from ever landing beside another's.
The objection this answers
Every agency that works with banks, clinics, insurers or public institutions has had the same conversation. The client is interested, the tool is interesting, and then someone from the security side asks where the code goes. For cloud sessions the honest answer used to be "onto the vendor's infrastructure", and in a fair number of procurement processes that ended the discussion on the spot.
Self-hosted environments change the answer, though not entirely. Repository checkouts, build artifacts, secrets and any file a session writes stay on machines you provisioned. Because the session runs inside the network, it can also reach an internal database, a private package registry or a staging service without any of them being exposed to the public internet. You can bake compilers, SDKs and internal command-line tools into the runner image so every session starts ready to build.
What does not change is the conversation itself. Prompts, responses and tool results still travel to Anthropic's API for model inference, and the session transcript is stored there so the session can be picked up from another device. Inference cannot be routed through a cloud provider's model service or an internal gateway. Anyone who sells this internally as "nothing leaves the building" will be corrected by the first security review, so it is better to describe it accurately from the start: the code stays, the conversation does not.
What this means if you are building something
It is not a checkbox. The beta is open to organisations on the Claude Team and Enterprise plans, it is off by default, and an owner or admin has to switch it on. After that, somebody has to own the runner image, keep it updated, run the fleet under an orchestrator that restarts runners, and control what they are allowed to reach. Anthropic's own documentation says plainly that most teams are better served by the hosted environments, which need no infrastructure at all. That is unusually honest advice from a vendor, and it is correct.
Zero Data Retention rules it out. Organisations that have Zero Data Retention enabled cannot use self-hosted environments. Worth checking before the idea reaches a slide, because ZDR is exactly the setting the most security-conscious clients tend to have turned on already.
It is a beta, with edges. Sessions check out repositories from GitHub, and several surfaces do not route to self-hosted environments yet. A first deployment belongs on one host and a small internal repository, not on the system the client's business runs on.
Our reading: this is worth proposing when a client has already refused a cloud tool on network grounds and has a platform team that already runs its own CI. Then the objection is real, the answer is real too, and the maintenance is work that team is doing anyway. When a client simply wants a website built well, this is an interesting note and nothing more.
Sources
