Blog

Run Claude Code on Your Own Infrastructure: What AU Compliance Teams Need to Know

August 2026 · 4 min read · Technical

Line illustration of a filing cabinet beside a terracotta shield with a checkmark, representing compliance-controlled infrastructure
← Back to all posts

Anthropic has moved self-hosted environments for Claude Code into public beta: organisations can now run Claude Code sessions on their own infrastructure instead of Anthropic-hosted compute. A session started from web, mobile, or desktop, or triggered on a routine schedule, executes inside the customer's own network, next to their internal services, toolchains, and security controls. For AU compliance teams watching where agent execution actually happens, this is a genuine and useful option, provided the details of what stays local and what does not are understood precisely.

What actually moves on-premises, and what still leaves

This is the part worth reading carefully rather than assuming. Repository checkouts, build artifacts, secrets, and any files the session creates stay on infrastructure the customer provisions and controls. That is a real and meaningful boundary for a business worried about source code or build outputs sitting on someone else's servers.

What does not stay local is the conversation itself. Prompts, model responses, and tool results, including code Claude reads as part of doing the work, are still sent to Anthropic for inference, because that is where the model runs. The session transcript is also stored so a session can resume from any surface. Self-hosting moves execution and artifacts onto a customer's own infrastructure. It does not make the underlying model call itself local, and it is not an Australian data-residency feature or a specific compliance certification, regardless of how the marketing around "self-hosted" might be read at a glance.

Why teams actually choose to self-host

Anthropic itself still recommends the hosted offering for most enterprises, since there is no infrastructure to run or maintain. Self-hosting is aimed at teams whose network, tooling, or compliance requirements specifically demand controlling where agent execution happens, and it comes with a real cost: an engineering team has to own the setup and ongoing maintenance of the runners that pick up and execute sessions.

  • Network access to internal services, databases, and package registries without exposing them publicly, the reason most often cited in Anthropic's preview program.

  • Customisability, pre-installed compilers, SDKs, and internal CLIs that a hosted environment would not have configured.

  • Compliance, source code and build artifacts staying on infrastructure the organisation directly controls, which is the detail that actually matters for an audit.

Mechanically, a customer deploys long-lived runner processes that pick up queued sessions and start a Claude Code process per session, either a fixed static pool or an on-demand orchestrator that scales with queue depth. It is currently available in public beta to Claude Team and Enterprise plans.

What this means for an AU compliance posture

For a business operating under the Privacy Act or APRA's CPS 230 operational resilience standard, self-hosted execution is genuinely on-wedge: keeping agent execution and build artifacts inside a network the compliance team already controls answers a real question a security review is likely to ask. What it does not answer, and what a compliance team should not accept a vendor implying, is any claim about where the inference call itself is processed, or that self-hosting alone satisfies a specific certification. The accurate framing is narrower and still useful: execution and artifacts under your control, inference still handled by Anthropic.

That distinction should shape how a compliance team documents the decision. The risk register entry for a self-hosted Claude Code deployment should describe exactly what stays on customer infrastructure, list the conversation and transcript data that still leaves the network for inference, and avoid claiming a residency guarantee the architecture does not actually provide.

A worked example of the accurate framing

Consider a Melbourne-based fintech running Claude Code against a codebase that touches customer financial data. Self-hosting means their build pipeline, secrets, and generated artifacts never leave infrastructure their own security team manages, which is a real and defensible control. It does not mean the prompts describing what the agent should do, or the code snippets it reads to do the work, stay off Anthropic's servers, because the model itself still runs there. A compliance write-up that says "agent execution is fully on-premises" without that second half is technically wrong in a way an auditor or a regulator could reasonably flag, and it is the kind of overclaim that damages trust faster than the underlying architecture gap ever would.

The Automata AI take

Self-hosted environments are a real option for AU businesses with genuine network-isolation or compliance requirements, not a checkbox every team should tick by default. The engineering overhead of running your own runners is worth it when the network requirement is real, and unnecessary complexity when it is not. A scoping call to work out which side of that line your business sits on typically takes under an hour, and an implementation, where warranted, runs A$8,000 to A$18,000 depending on runner architecture and how many environments are in scope.

Book a brainstorm and we will help you work out whether self-hosting is actually solving a problem you have.

Ready to move from AI pilot to production?

We help mid-market Australian businesses deploy AI automations that actually reach production and deliver measurable ROI.