CLAUDE CODE SELF-HOSTED ENVIRONMENT VS CLOUD
How Should Enterprise Teams Choose in 2026?

As of September 25, 2026, Claude Code self-hosted environments are in public beta for Team and Enterprise organizations, are off by default, and are unavailable to organizations using ZDR, according to the official announcement. That limited availability is a reason to verify eligibility—not a reason to buy Mac hardware by default.

Symptom → fastest fix: cloud meets your network and governance requirements → stay with cloud and avoid adding Runner operations. A verified need for internal execution, controlled tools, or a specific compliance boundary → assess self-hosting; for Xcode work, confirm macOS support before provisioning a real Mac.

Who should read this: Enterprise IT owners evaluating network boundaries, data handling, and operational responsibility. Platform engineering leads deciding between cloud execution and a team-managed Runner. Apple platform leads separating Claude Code tasks from Xcode, signing, and Mac CI requirements.

Last updated September 25, 2026. Availability and eligibility were checked against the Claude Code announcement and self-hosted documentation. Recheck these sources before procurement; beta status, plan eligibility, and platform support can change.

Start with the Claude Code self-hosted environment selection gate

Do not treat “self-hosted” as shorthand for “runs on a Mac” or “all model data stays inside our network.” Those are separate claims that require separate evidence. The key distinction is where the coding session executes, who operates that environment, and what information still travels to the model service.

<

Option	Where the session runs	Who owns environment operations	What to verify before choosing
Cloud	In the provider-managed environment	The service provider operates the execution environment; your team manages access, policy, and workflow configuration	Whether network access, data handling, and organization controls meet your requirements
Self-hosted environment	On compute your organization manages	Your team owns the execution infrastructure and its operational controls; confirm the exact split in the current deployment documentation	Supported operating systems, launch model, Runner lifecycle, capacity, orchestration, and data flows
Remote Control	On the machine that owns the active session, with remote interaction from another device	The owner of that machine remains responsible for its availability, access, and local state	Session identity, machine availability, access controls, and whether this is appropriate for an individual workflow rather than shared CI

Claude’s [self-hosted environment documentation](https://code.claude.com/docs/en/self-hosted-environments) describes the self-managed execution model. The [identity and session documentation](https://code.claude.com/docs/en/self-hosted-environments-identity) distinguishes session ownership and execution location. Remote Control is not a shared Runner: connecting to a session on a person’s machine does not create a team-owned, schedulable build worker.

For most teams, cloud is the lower-operations starting point if it passes the organization’s network and governance checks. Self-hosting becomes a candidate only when a documented requirement cannot be met by the cloud setup. A Mac is a further decision: it is relevant only if the Runner’s supported platform and your workload both require macOS.

Rate each option against your actual constraints

Use this scoring pass before a technical demo. Give each option a score from one to five for each criterion, where one means “fails our requirement” and five means “meets it with little extra work.” This is an internal comparison tool, not a product benchmark; write down the evidence behind every score.

• Network fit: Can the execution environment reach required internal services without weakening network controls?
• Governance fit: Can you enforce the policies, identity rules, and data-retention controls your organization requires?
• Platform fit: Does the documented Runner support the operating system and tools the workflow needs?
• Operational fit: Can your team own image maintenance, updates, monitoring, scheduling, and incident response?
• Capacity fit: Can the option handle expected work without leaving costly idle capacity or creating queue delays?

A high average score is not enough if a hard requirement fails. Treat a failed network, security, or platform requirement as a veto, not as a weakness that can be offset by convenience elsewhere.

Platform engineering: verify Runner support and operating ownership

The phrase “self-hosted environment” establishes an execution model, not a guarantee that your target operating system is supported. Before piloting, use the current Runner and deployment documentation to verify the supported operating systems, how Runners are launched, and the required deployment components. Do not infer macOS support from a product announcement or from a successful session on another platform.

Ask the platform owner to produce a short evidence record covering these items:

• Supported platform: Record the exact supported operating systems and any relevant version or image constraints from the current documentation. If macOS is not explicitly listed, mark Mac execution as unverified.
• Execution mode: Confirm whether the workflow uses a persistent Runner, on-demand capacity, or another documented mode. The mode affects startup behavior, scheduling, cleanup, and the way you isolate jobs.
• Lifecycle ownership: Identify who prepares and patches the base image, updates Runner components, rotates credentials, and removes abandoned resources.
• Orchestration: Confirm which team provisions capacity, dispatches work, manages queues, and handles failures. Do not assume that the service supplies an orchestrator unless the documentation says so.
• Support boundary: Capture what the service operates and what remains your team’s responsibility. Include a named owner for each operational task.

A demo that proves a login works does not establish production readiness. Your pilot should exercise the exact supported launch path, a clean job, a failed job, cleanup, and the recovery procedure. The [production deployment guidance](https://code.claude.com/docs/en/self-hosted-environments-deploy) should be treated as the source for the deployment requirements; keep a dated copy or review record so that a later documentation change does not silently invalidate your design.

**Operational warning:** If a workflow depends on a platform that the current Runner documentation does not confirm, stop the procurement decision at “unverified.” Do not fill that evidence gap with a Mac purchase.

Security and compliance: map data before approving self-hosting

Self-hosting can move execution onto infrastructure your team controls. It does not, by itself, prove that every prompt, model response, or tool result stays within that infrastructure. Build the data-flow map before security review, and separate local artifacts from information sent for inference.

Developer or CI job
        |
        v
Self-managed execution environment
  |-- repository working copy
  |-- local tools and build outputs
  |-- credentials available to the job
  |
  |-- prompts, responses, and tool results used for inference
        |
        v
Model service

This is a review diagram, not a claim that every deployment sends identical data. Confirm the actual flow against the self-hosted environment documentation, your organization’s configuration, and the applicable service terms. Repository copies, generated artifacts, and secrets may remain on infrastructure you manage, but prompts, responses, and tool results used for model inference must be assessed as a separate data path.

Have security and platform owners answer these questions together:

• Which repository content, file excerpts, command output, and test results can enter prompts or tool results?
• Which secrets are available to the job, and can the workflow prevent them from being printed or transmitted?
• Where are session records stored, who can access them, and which organization policies apply?
• What retention controls apply to this plan and product? The enterprise retention control documentation is the reference for supported controls; verify the settings available to your organization rather than assuming self-hosting changes them.
• Does your organization use a ZDR agreement, and does that agreement cover the product and feature under review? Check the current ZDR product applicability guidance and the self-hosted eligibility notice. The announcement says organizations using ZDR cannot use this beta; confirm that status directly before planning a trial.

Classify each data type as **stays on managed infrastructure**, **sent for inference**, or **not yet verified**. Do not approve production use while a material data flow remains in the last category. Self-managed compute changes the execution boundary; it does not automatically change the inference boundary, contractual terms, or retention behavior.

Apple platform leads: does a self-hosted Runner support macOS?

That question has a direct answer only when current Runner documentation explicitly confirms macOS support for the deployment mode you intend to use. If it does not, treat the platform as unverified and do not describe the environment as a supported Mac Runner. A product announcement that describes self-hosting is not proof of macOS compatibility.

Now separate coding work from Apple-native build work. Claude Code may assist with code analysis, edits, and tasks that do not require Apple’s native build environment. A job that invokes Xcode, an iOS Simulator, code signing, or other macOS-specific tooling has a different execution requirement. The fact that the agent can interact with Xcode is also a separate fact: Apple’s documentation for giving external agents access to Xcode describes that integration. It does not establish that a particular Claude Code self-hosted Runner supports macOS.

For a Mac CI design, verify these boundaries independently:

• Agent boundary: Which repository operations and tools can the coding session invoke?
• Build boundary: Which jobs require macOS, Xcode, or a simulator, and which can run elsewhere?
• Signing boundary: Where do signing identities and provisioning materials reside, and which job identities can use them?
• Runner boundary: Does the documented self-hosted mode support the required Mac environment, and can you isolate jobs that access signing assets?
• Evidence boundary: Has a real end-to-end workflow produced the expected build artifact and passed the team’s signing and release checks?

A sensible architecture may keep code assistance separate from the build and signing stage. That separation limits the credentials available to an agent session and makes it easier to review which system produced each artifact. But the architecture must be validated against your actual tooling and service support; do not present it as a guaranteed feature.

IT and FinOps: compare full operating cost, not just compute

There is no responsible savings percentage to quote without your organization’s usage, prices, capacity pattern, and staffing costs. Compare the full cost over the same planning period, then test the result against both normal demand and idle periods.

For cloud, collect the applicable service charges and any internal costs for access controls, policy review, and integration. For a self-hosted design, include compute or hardware, image preparation, patching, Runner updates, orchestration, monitoring, storage, network, security review, idle capacity, and failure response. If a Mac is required and supported, include the actual Mac acquisition or rental cost, its operating model, and the work needed to keep it available. Do not substitute a generic public price for a quote or rate that has not been verified.

Use a worksheet with organization-specific values:

Cloud total =
  metered service charges
  + integration and governance work
  + internal incident and support effort

Self-hosted total =
  compute or Mac capacity
  + image and Runner maintenance
  + orchestration and monitoring
  + storage and network
  + security and compliance work
  + idle capacity
  + failure and recovery effort

Cost per successful job =
  total cost for the review period
  / successful jobs completed in that period

Keep labor visible. A platform that appears cheaper on infrastructure alone may require recurring engineering time for updates, incident handling, and capacity planning. Conversely, self-hosting can be justified when a control requirement cannot be met by cloud, even if it costs more; that is a risk decision, not a cost-saving claim.

If verified macOS execution is required but buying and maintaining a permanent Mac is not justified by your utilization, compare it with a temporary or remote Mac capacity option. You can review MACGPU’s Mac options as one input to that comparison. Do not treat the availability of a Mac as proof that the Claude Code Runner supports it: platform support and service suitability remain separate checks.

Procurement and pilot owners: apply conditional exit gates

Use these branches to turn the assessment into a decision. Record the evidence and the person accountable for each gate.

• If cloud satisfies network, governance, and workflow requirements, choose cloud for the initial rollout. Do not add Runner infrastructure solely to satisfy a general preference for self-hosting.
• If a documented internal-network, controlled-toolchain, or compliance requirement cannot be met in cloud, evaluate self-hosting. Continue only after confirming that the current Runner documentation supports the intended platform and launch mode.
• If the workload includes Xcode or other macOS-native tasks, require explicit platform confirmation and a real end-to-end build test before assigning those jobs to the Runner. If either is missing, keep the Apple build stage on a separately verified environment.
• If self-hosting passes functional tests but lacks an owner for patches, monitoring, capacity, credentials, or recovery, do not approve production use. A working demo is not an operations plan.
• If retention or data-flow review fails, stop the pilot or redesign its inputs. Do not assume that self-hosting alone resolves data residency, ZDR eligibility, or policy requirements.

Set exit conditions before the pilot begins. A useful acceptance record names the platform owner, security approver, Apple build owner, and procurement decision-maker. It also states which workloads were tested, what evidence constitutes a pass, what blocks rollout, and which changes trigger a new review. Reopen the decision if the official support matrix changes, beta eligibility changes, your ZDR status changes, a new Xcode requirement appears, or the data classifications change.

For a Mac-specific design, continue with an infrastructure review only after the platform gate passes. The MACGPU Mac ordering page can help you assess a real Mac capacity option; validate its current configurations and commercial terms directly rather than treating them as assumed inputs in the TCO worksheet.

The trade-off is operational, not simply “cloud versus Mac.” A cloud-first approach can leave internal-network access unmet, provide less control over the execution image, or fail a workload’s verified platform requirement. A permanent self-managed Mac can add idle capacity, maintenance work, and hardware lifecycle responsibility. If you need a real Mac only for a temporary pilot or intermittent Xcode validation, renting through MACGPU may be a better fit than buying an underused machine; if your team needs sustained, predictable heavy use or direct physical interfaces, evaluate owned hardware instead. First confirm Runner support, signing isolation, and the complete build path—then size the Mac capacity around evidence, not assumptions.