Anthropic just opened public beta for self-hosted environments in Claude Code, available to Team and Enterprise plans. The pitch is straightforward: instead of Claude Code sessions running on Anthropic-managed compute, they run on infrastructure you control — with access to your internal network, your private registries, your databases.

I read the announcement the way I read every “run it on your own infra” pitch from a vendor: as two separate claims bundled into one marketing sentence. One claim is about where compute happens. The other is about where data goes. Vendors love it when you conflate them, because the second claim is usually the one you actually care about, and it’s the one that doesn’t hold up here.

What you actually get

Self-hosting Claude Code buys you three real things:

  1. Network reach. Sessions run inside your VPC and can hit internal services, staging databases, and private package registries without punching holes in your firewall or exposing anything to the public internet.
  2. Pre-baked tooling. You control the runner image — compilers, SDKs, internal CLIs, whatever your build needs — so every session starts ready instead of burning turns installing dependencies.
  3. Artifact locality. Repo checkouts and build outputs stay on infrastructure you own, instead of transiting through Anthropic-managed storage.

For a team gated on “the agent can’t reach our internal Jira/Confluence/build system,” this alone is worth the setup cost. I’ve had Claude Code sessions stall out on exactly this — no route to an internal artifact repo, so every dependency install fell back to a public mirror that didn’t have our private packages.

What you don’t get

Here’s the part that matters more than the announcement post leads with: prompts, model responses, tool results, and full session transcripts still travel to Anthropic for inference, and Anthropic retains those transcripts. Self-hosting moves the execution environment, not the data path. The model still lives in Anthropic’s cloud — it has to, that’s where the weights are — so every message you send and every file content you paste into context makes the same round trip it always did.

The tell is in the fine print: self-hosted environments are explicitly not available for organizations on Zero Data Retention (ZDR). If self-hosting actually kept your data local, ZDR customers would be the first ones offered it, not the ones excluded from it. The exclusion confirms what the architecture implies — this is a network and tooling isolation feature, not a data isolation feature.

If your compliance requirement is “code never crosses our network boundary,” self-hosted Claude Code does not satisfy it. If your requirement is “the agent can only reach systems we explicitly allow, and can’t be used to exfiltrate through an open internet connection,” it does.

Rollout playbook

If you’re evaluating this for your org, here’s the sequence I’d run:

1. Classify your actual requirement first. Sit down with security/compliance and write down, in one sentence, what “self-hosted” needs to mean for your org. Network isolation? Data residency? Audit trail? These have different owners and different features solve them. Don’t let the vendor’s naming decide your requirement for you.

2. Turn it on scoped, not org-wide. It’s off by default — an Owner or admin has to enable “Allow self-hosted environments” on the Cloud environments admin page, and it requires Claude Code on the web to already be enabled. Start with one team, one repo class (say, internal tooling, not anything touching regulated data), and watch what actually crosses the wire.

3. Build the runner image like you’d build a CI image. Pre-install your compiler toolchain, internal CLIs, and any auth helpers your build needs. Treat it as versioned infrastructure — Dockerfile in a repo, rebuilt on a schedule, not a snowflake VM someone SSHed into once.

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y \
    build-essential curl git \
    internal-cli-tools  # your private apt mirror
COPY .netrc /root/.netrc  # scoped read tokens for internal registries only
ENV CLAUDE_CODE_RUNNER=self-hosted

4. Route through the Compliance API if you’re on Enterprise. Coverage now extends to Claude Code in the CLI and desktop app (beta, Enterprise only), which means your security team can pull session content and metadata programmatically instead of trusting screenshots. Wire this up before you scale usage, not after an incident makes you wish you had.

5. Decide fixed vs. on-demand runners based on cost, not fear. Fixed runners sit warm and ready; on-demand spin up per session and cost less when idle. For spiky usage (a few devs, occasional sessions) on-demand wins. For a team running agent sessions most of the working day, fixed runners amortize better — the startup latency on-demand adds up fast when someone’s iterating.

The takeaway

This is a genuinely useful feature for the narrow problem it solves — get the agent inside your network so it can actually be useful against your real systems — and a non-solution for the broader trust problem people will assume it solves. When someone on your team says “we’re fine now, it’s self-hosted,” ask them to point at the specific compliance requirement it satisfies. Half the time the honest answer is “network access,” and that’s a fine answer — as long as it’s the one you actually needed.

Export for reading

Comments