Infrastructure Tradeoffs Engineers Accept When Self-Hosting Agentic Coding Runtimes

To run Claude Code in the cloud without managing infrastructure, a team can use a managed cloud agent platform. Self-hosting instead transfers responsibility for isolation, credentials, dependencies, observability, and maintenance to the team. The right arrangement depends on which boundaries the team must control and which obligations it can sustain.

What self-hosting an agentic coding runtime actually means in 2026

Self-hosting describes a spectrum of control arrangements. At the fully managed end, the vendor handles isolation, scaling, and updates, while code and prompts leave the team's network. At the pure self-hosted end, the team operates both the control plane and the execution sandboxes. Between those positions, ownership is divided by layer. That division determines what the team must maintain and where its data travels.

Vendor runners put execution on infrastructure the team controls while leaving the agent loop and inference in the vendor's cloud. Cursor self-hosted machines follow this model, with Enterprise required for Team Pools but not My Machines. BYOC is a different arrangement. The vendor's orchestration, monitoring, and update software runs inside the customer's cloud account, where the customer's compute also runs the sandboxes.

Compliance, latency, and the cost of execution push teams to own more of their infrastructure. A requirement that data stay inside a VPC can rule out architectures that send prompts elsewhere. Round-trips to an external sandbox API can also disrupt real-time conversational agents, but running execution on the same network as inference cuts that delay to near-zero. At high monthly execution volumes, managed per-execution premiums can become unsustainable relative to predictable infrastructure-based pricing. Each step toward pure self-hosting adds a different category of work.

Why standard containers are not a sufficient isolation boundary for coding agents

Standard Docker containers share the host kernel, so agent-generated code reaches a boundary also used by the host. A kernel exploit or sufficiently privileged escape can cross that boundary. This changes the threat model substantially. An ordinary containerized application runs code selected by its operator, while a coding agent can generate buggy code or execute instructions influenced by an external prompt. Prompt injection can redirect its actions without the operator's knowledge.

For user-supplied or LLM-generated code, shared-kernel containers generally do not provide sufficient isolation. A VM boundary separates execution in a way that a shared-kernel container cannot. Firecracker microVMs provide a hardware-virtualization boundary and are used in production agentic infrastructure, although startup overhead is higher than for containers. Stronger isolation has an operational price. Choosing Docker first and upgrading later leaves weaker isolation in production during the interval, and retrofitting that boundary becomes harder once agents are in use.

Ramp's engineering team built separate, ephemeral environments for each task performed by its internal background agent. The team used sandboxed VMs running on Modal rather than giving agent tasks access to production systems. Each environment included a full development stack, including Vite, Postgres, and Temporal.

The credential and network boundary problem that most self-hosting plans underestimate

A correctly isolated VM can still expose data if its agent has real credentials and unrestricted network access. Compute isolation does not prevent authorized-looking requests to an external server. When API keys are put into the sandbox environment, code the agent runs can see them, including code produced through prompt injection. Self-hosting therefore requires a separate design for what the agent can reach and which authority it can exercise.

The proxy pattern separates that authority from execution. The sandbox container runs with no direct network access, using network none, while a proxy mounted through a Unix socket mediates egress. The proxy applies domain allowlisting, injects credentials, and audits requests. The agent never receives the real credentials. With all network access mediated through that boundary, even a compromised agent process cannot reach unauthorized servers, and credential rotation is centralized in the proxy.

The credential proxy and egress allowlist need to be treated as first-class design artifacts. Even then, the runner's network boundary is not necessarily the integration boundary. Claude Code connectors such as Slack or Linear are called from Anthropic's side, so their traffic does not originate inside the runner's network. An integration that looks self-hosted can therefore send connector events through vendor infrastructure, which affects compliance and latency beyond the sandbox architecture.

Dependency management and environment parity across ephemeral agent sandboxes

Ephemeral sandboxes reset after each run, but reliable agent work depends on consistent dependencies, tooling, and environment state. That tension creates a recurring engineering obligation. Installing dependencies at runtime adds latency and permits version drift as upstream packages change. Pre-baking them into a base image avoids that installation delay but requires a build-and-publish pipeline synchronized with the repository's dependency graph. Warm pools cut cold-start latency by keeping initialized instances ready, but teams then have another set of environments to keep up to date.

Codex CLI supports parallel agent fleets and isolated worktrees, with repository instructions in AGENTS.md and reusable workflows packaged as skills. The operator still has to set up the self-hosted environment. Claude Code uses CLAUDE.md for project instructions and supports hooks, subagents, and an opt-in sandbox runtime. These facilities describe or constrain agent behavior, but they do not eliminate the need to reproduce the repository's working environment.

Claude Code's @anthropic-ai/sandbox-runtime package wraps the entire process, including file tools, MCP servers, and hooks, using Seatbelt on macOS or bubblewrap on Linux. Its configuration lives in ~/.srt-settings.json. The runtime is not enabled by default and does not substitute for VM-level isolation in multi-tenant environments. OpenCode offers provider flexibility but leaves more environment assembly to the operator, while its /init command generates an AGENTS.md and its configuration schemas require tracking. With any of these choices, teams need to rebuild and test dependency images when the repository's tooling changes, a harness releases a new version, or a model update changes how tools are used. Those are three independent maintenance clocks.

Observability gaps that appear when agents run in isolated environments

Ephemeral execution removes the persistent history teams often rely on to diagnose ordinary services. Unless logs leave the sandbox before teardown, the run history disappears with it. Silent failures require an explicit health-check mechanism because a run can produce no output, no pull request, and no visible error. Without signals to replace that history, teams cannot reliably tell which work finished, which failed, and which never produced a result someone could review.

A merged pull request might contain work from a human, several agents, several models, or a combination. Without instrumentation, the team cannot distinguish those sources or allocate model token consumption across runs. The cost becomes visible in review queues. When teams adopt agents, they can get far more pull requests, and agent-generated pull requests tend to be larger, wait longer for review, and leave a sizable share of work unmerged. Missing attribution prevents reviewers from triaging that load and obscures which agent workflows create it.

The useful measures are therefore not simply pull requests opened, but 30-day merge rate, median time-to-first-review split by agent authorship, and reviewer-hours per merged pull request. These measures require per-PR attribution. A mature analytics layer also allows comparisons across harnesses and models on the same tasks and codebase, and identifies task types that consistently stall in review. To support those decisions, each run needs a metadata envelope containing its source trigger, harness, model, credential, and timestamps, attached before execution begins. That envelope and the run's logs must reach a durable store before the sandbox terminates, with health checks providing an explicit signal for otherwise silent failures.

The ongoing maintenance surface that self-hosting creates and managed services absorb

Isolation technology, credential proxies, dependency images, and observability pipelines each need an owner after deployment. None becomes a permanently solved problem when its first version works. Harness releases make that especially clear. Their pace follows model releases rather than operator convenience, and an environment configured correctly for one version may behave differently or break under the next.

Claude Code, Codex, Cursor, and OpenCode have different release cadences and project-instruction mechanisms. Cursor uses .cursor/rules as .mdc files, adding another format to the instruction files already required by the other harnesses. Tracking these differences across a fleet is continuing work. OpenCode's provider-agnostic design also leaves provider privacy terms, retention, quotas, and costs with the operator. Flexibility expands the set of choices the team must govern as well as the configurations it must maintain.

A harness vendor can change ownership, pricing, or its model pool while a self-hosted team still depends on that vendor for the agent loop or inference. Staying harness-agnostic provides a hedge against those changes. It also means the team must be able to route work among harnesses while keeping the security and visibility it has built around them. The team must assign indefinite ownership of container and VM isolation, secrets management, log shipping, and harness behavior, a combination that does not map cleanly onto existing DevOps or platform engineering roles.

Managed and BYOC services take on some layers of this work, and leave others with the team. The allocation depends on the architecture. Vendor runners such as Cursor self-hosted machines and Devin Outposts run execution on the customer's infrastructure and leave the agent loop with the vendor. That creates a narrower maintenance burden, but also a narrower control boundary. A useful comparison therefore identifies which layer each party operates, rather than treating “self-hosted” and “managed” as complete descriptions of responsibility.

How should a team run Claude Code in the cloud, through self-hosting, a hybrid, or a managed platform?

The first decision criterion is whether a compliance rule specifically requires code, prompts, and execution logs never to leave the team's network. If it does, the viable paths are pure self-hosting or BYOC with in-VPC data residency. A self-hosted runner is not enough. Any arrangement that routes protected prompts through vendor infrastructure fails that particular requirement, regardless of where commands execute. Without such a rule, teams have no compliance reason to self-host on those grounds, so they can choose based on what it takes to run each setup.

The second criterion is permanent platform engineering capacity. A team choosing pure self-hosting must be able to own isolation, credential proxies, dependency image pipelines, and observability indefinitely. This work competes with product engineering. Where that capacity is absent, BYOC can offload control-plane responsibilities, while a managed platform can offload the full runtime stack. The choice should reflect what the team can sustain beyond the initial build.

The third criterion is whether the team needs multiple harnesses or expects to switch as models improve. A stack built around one harness can create infrastructure-level lock-in. To switch, the team may need new environment images, proxy configuration, and observability instrumentation that work with another configuration format. Platforms designed to run Claude Code, Codex, Cursor, and OpenCode in isolated VMs with shared observability and integration layers offer a different allocation of that work. They let the team use different harnesses without having to own every layer that supports them.

Data residency, egress boundaries, and credential handling have direct compliance and security consequences, while tooling, model choice, and workflow preferences may be satisfied through platform configuration. The decision rule is to self-host when compliance demands it and platform capacity exists, choose BYOC when residency is required but maintenance capacity is limited, and choose a managed cloud agent platform when harness flexibility, integrated observability, and workflow integration take priority over owning execution.