Claude Code Runs on Your Own Server Now, Here’s What It Means

Anthropic shipped Claude Code version 2.1.224 on August 7, 2026. This release lets customers run the tool’s cloud sessions on their own infrastructure instead of Anthropic’s

The feature, called a self-hosted runner, is available now to Team and Enterprise customers in public beta.

It exists to solve one specific problem. Some organizations with strict data or compliance rules couldn’t use Claude Code’s background cloud sessions before this, because that work ran exclusively on Anthropic’s managed servers. Their code, secrets and build artifacts weren’t allowed to leave the company network.

The new feature changes where that work happens. It does not change what Claude Code itself does.

What you get with a self-hosted runner?

Before the mechanics, here is what the feature delivers in practice. Four changes matter to the people using it day to day, plus one boundary that shapes how far the self-hosting actually goes.

• Sessions keep running after you close the laptop. Cloud sessions already did that. What changes is that the machine doing the work is yours, a persistent server or container in your own environment.
• Your code never leaves. Checkouts, secrets, files and build artifacts all stay inside your infrastructure. That’s what makes the feature usable under compliance, internal network policy or data-residency rules.
• Access stays the same. Developers start and rejoin sessions from Claude Code’s web, desktop and mobile apps, and pick the self-hosted environment from the same list as Anthropic’s default.
• No special hardware. A standard Linux server or a Docker container is enough.

Only the execution environment moves. Inference still runs through Anthropic over HTTPS on every session, so a self-hosted runner is neither fully self-hosted nor fully isolated. That boundary shapes everything below.

Let’s start by digging into what’s actually new in the Claude Code changelog

What’s new in the Claude Code changelog?

One new command changes where a Claude Code session actually runs. Here’s what it does, and what it takes to turn it on.

1. How the runner command works

The feature is built around a single command, claude self-hosted-runner.

Setting one up works one of two ways. A guided interactive setup walks an admin through creating the destination and starting the process. A manual path is also available, and requires an environment secret file and a base directory.

2. The three pieces: Environments, runners, sessions

Three terms do most of the work here.

An environment is the destination an admin creates inside Claude’s admin console, a named place sessions can be sent.

A runner is the long-lived process installed on the customer’s own machine or container. It registers itself with an environment, then sits and polls for work. Developers who’ve set up a GitHub Actions self-hosted runner will recognize the pattern. It is the same idea applied to Claude Code. Instead of CI jobs, this is just for AI coding sessions  

A session is a single Claude Code task, the actual thing a developer asked Claude to do. The runner picks up each session and executes it as a child process.

3. How do you know it’s live?

The admin console shows a runner’s status move from “No runners deployed” to “Healthy” once it’s registered. After that, a developer starting a new session from Claude Code’s web, mobile or desktop apps will see the self-hosted environment listed as a selectable option, alongside Anthropic’s own default.

4. Where it runs, and where it doesn’t

One hard platform limit is worth flagging. Windows isn’t supported as a runner host. The process needs to run on Linux, either directly or inside a Docker container, so teams running Windows fleets have to route through a container to use this.

The feature also sits behind a plan wall. It’s Team and Enterprise only, it’s in public beta and it’s off by default until an admin turns it on.

One more detail shapes how teams will actually use this. A runner locks to a single user’s account the first time it picks up a session. That keeps different developers’ checked-out code from ending up mixed together on the same disk. It also means a runner isn’t a shared pool by default, so teams with multiple developers will need to think about how many runners they provision, not just whether they have one.

Knowing what shipped explains only half the story. The more useful question is why Anthropic built this in the first place, and that starts with a security problem self-hosted runners were built to solve.

What Claude Code security problem does the self-hosted runner solve?

For plenty of engineering teams, Claude Code’s capability was never the obstacle, where the work happened was. This feature closes that gap by letting execution run inside infrastructure the customer controls, while model inference still goes through Anthropic’s API. Here’s the exact boundary between what moves and what doesn’t.

1. Where cloud sessions ran before this fix

Before this release, every Claude Code cloud session ran on Anthropic’s managed infrastructure by default. For a lot of teams, that setup was fine.

For teams operating under compliance rules, data residency requirements or internal network security policies, it was a hard blocker. Repository checkouts, secrets and build artifacts simply weren’t permitted to leave the organization’s own network, so those cloud features were off the table entirely.

2. What moves to your infrastructure, and what doesn’t

The self-hosted runner is a direct answer to that blocker, and it’s worth being precise about what actually changes.

The execution environment moves. Files get read and written on the customer’s disk, and shell commands run on the customer’s host.

Model inference does not. The reasoning calls behind every session still go out over HTTPS to Anthropic’s API, carrying the prompts, file contents and code the model works on. Self-hosting the runner is not self-hosting the model.

3. What running inside your own network gives you

Moving execution onto your own hardware also moves it inside your own security controls. That is where most of the practical benefit sits for the teams that were blocked before.

• It sits behind your existing perimeter: The runner can live in a private network or a VPC with no public ingress. Your firewalls, identity controls, permissions and network segmentation apply to Claude Code sessions the same way they apply to anything else running there.
• Internal systems become reachable without being exposed: Private repositories, internal APIs and development tooling are available to a session because the session is already inside the perimeter where they live. None of them need a public endpoint.
• Traffic only goes outward: As covered above, the runner registers with an environment and then polls for work. So, it opens outbound connections rather than accepting inbound ones. No ports to open, no endpoint to publish.
• Your logging and policies apply: Session activity happens on hosts already covered by whatever logging, monitoring and policy enforcement the organization runs. The execution itself, along with the secrets and artifacts it produces, never lands in a third-party environment where visibility stops at the provider’s boundary.

All of that applies to execution. It does not apply to the API calls described above, which leave the network on every session. The distinction matters most for teams measuring this against a policy written to forbid outbound data flow outright, because a self-hosted runner will not satisfy one.

What this beta still won’t let you do

A few constraints come with the beta as it stands today.

Organizations using a Zero Data Retention agreement with Anthropic can’t use this feature. Inference also can’t currently be routed through Bedrock, Google Cloud or Microsoft Foundry when a session is running on a self-hosted runner.

None of this requires exotic hardware, though. Early testers have already stood up runners on ordinary cloud servers. It’s the same kind of general-purpose Linux instance most infrastructure teams already know how to provision.

That fix for a fairly narrow compliance problem points at something bigger about where Anthropic is steering the product, and that’s worth examining on its own.

What this means for Claude Code Enterprise teams

A fix built for one compliance requirement rarely stays that narrow. Here’s the larger shift it points to, and the new responsibility it hands to the teams who adopt it.

A different kind of competition

Some engineers writing about the release have read it as a signal about where Anthropic is positioning Claude Code. Not as a smarter coding assistant, but as something closer to enterprise infrastructure, a system teams deploy and administer rather than a tool they simply subscribe to.

That’s a different competitive angle than tools like GitHub Copilot, Cursor or Windsurf, which mostly compete on model quality and editor integration. A self-hosting option competes on deployment control instead.

The infrastructure underneath matters more now

There’s a wider reading of that shift. Agents write code unattended now. They work at volumes no one reviews line by line. Every session needs a host to run on. That host is load-bearing. If it goes down, queued work stops. If it is poorly secured, a long-lived process sits inside the network holding checked-out code and live credentials. The more software agents write, the more output rests on infrastructure that has to stay up and stay locked down.

Who this opens the door for

The practical effect is that it opens Claude Code’s background-session features to teams that were shut out before. That includes regulated industries and government-adjacent work, anywhere code and data aren’t allowed to leave a private network.

The trade-off teams now face

It also hands those teams a new, concrete responsibility.

Someone now has to provision, secure and keep running a persistent Linux server or container just to host the runner process. That’s an actual infrastructure commitment, not a settings toggle.

It’s a decision that didn’t exist for these teams a month ago. That commitment doesn’t end at setup. Securing the host, patching it and monitoring the runner process are all the organization’s job now, for as long as the runner is in use.

What Anthropic’s updates suggest happens next

Because this is public beta, the current restrictions are worth watching rather than treating as permanent.

That pattern holds across Anthropic’s updates generally: features at this stage tend to expand in plan availability and loosen in scope as adoption grows. The Zero Data Retention exclusion and the limited inference routing are reasonable candidates for that kind of change, though neither has been announced.

Whether those restrictions actually loosen is itself one of the open questions worth tracking as this feature matures.

What to watch in the next Claude updates

Beta features come with an asterisk. Here’s what would confirm this one is built to last.

The open questions from here are straightforward. Will self-hosted runners expand beyond Team and Enterprise plans? Will the Zero Data Retention and cloud-routing restrictions get lifted? Will competing agentic coding tools respond with self-hosting options of their own?

How many teams actually provision a runner in the first few months is worth watching too. That adoption curve will say more about real demand for this kind of control than the announcement itself does.

Anyone tracking the technical detail should treat Anthropic’s own Claude Code release notes as the primary source, since beta features like this one tend to change quickly.

How this piece was reported: The technical details are drawn directly from Anthropic’s official Claude Code changelog and documentation, cross-checked against early hands-on accounts from developers who installed the feature the week it shipped. The interpretation section is clearly marked as analysis, not confirmed fact, and reflects outside commentary rather than Anthropic’s own statements.