Kubernetes Gets Its Own Agent Sandbox: What the Sandbox CRD Means for a Self-Hosted PaaS

In less than five months, the number of agent sandboxes running on Google Kubernetes Engine grew 16x. LangChain and Lovable are deploying millions of agents into production. And in March 2026, Kubernetes SIG Apps gave every cluster operator the primitive behind that surge: a declarative Sandbox CRD for running untrusted AI-agent code as isolated, stateful, singleton workloads — no bespoke sandbox service required.

Here is the verdict up front for teams running a self-hosted PaaS: if you already operate a Kubernetes fleet, the upstream Sandbox CRD is now the default starting point for your agent-execution roadmap, not a build-it-yourself sandbox control plane. You still need to choose your isolation runtime, size a warm pool, and accept that the API is mid-migration.

But the days of hand-rolling pod-per-agent orchestration with shell scripts and crossed fingers are over. This post walks through what the primitive actually is, how it compares to building your own or buying E2B-style capacity, and the gaps you should track before betting the roadmap on it.

What the Sandbox CRD actually is​

The kubernetes-sigs/agent-sandbox project, developed under SIG Apps, describes its goal plainly: a declarative, standardized API for workloads that behave like a lightweight, single-container VM on Kubernetes. An agent runtime is long-running, stateful, a singleton (exactly one active instance per agent), and needs a stable identity other agents can reach. Pods can approximate that shape, but only with a pile of bespoke controller logic for lifecycle, snapshotting, and warm provisioning. The Sandbox API makes it a first-class object.

Four custom resources do the work:

• Sandbox — the core object: one isolated, stateful agent runtime with a stable hostname for multi-agent discovery, scale-to-zero suspend, and resume exactly where the agent left off.
• SandboxTemplate — the blueprint: image, isolation runtime, resource envelope, and network policy, versioned once and reused everywhere.
• SandboxWarmPool — the latency killer: a set of pre-booted sandboxes claimed in milliseconds instead of cold-started in seconds.
• SandboxClaim — the checkout ticket: an agent (or harness) claims a warm sandbox from a pool, or cold-starts from a template when the pool is empty.

A typical claim is a few lines of YAML against a pool your platform team manages:

apiVersion: agents.x-k8s.io/v1beta1
kind: SandboxClaim
metadata:
  name: agent-task-1
  namespace: tenant-acme
spec:
  warmpoolRef:
    name: python-warm-pool

Isolation is pluggable through the standard RuntimeClass mechanism, with gVisor as the native default plus default-deny Kubernetes network policy. Kata Containers slots in through the same interface when you need hardware-virtualized boundaries.

The tradeoff is well measured. gVisor's syscall interception adds roughly 10–30ms of overhead with about 40 MiB of memory and no KVM dependency, while Kata's lightweight-VM-per-pod model costs roughly 100–300ms and 128 MiB per sandbox and needs virt-capable nodes. Pick gVisor for density on general nodes; pick Kata when tenants are mutually untrusted and you can afford the per-sandbox VM tax.

The performance numbers that matter most are the pool and suspend figures Google published alongside GKE Agent Sandbox's GA in May 2026: 300 sandbox allocations per second per cluster at sub-second latency, with 90 percent completing in 200 milliseconds, plus Pod Snapshot suspend/resume that parks idle agents in seconds instead of burning compute through their idle periods. Suspended-VM standby buffers act as a cheap cold pool that refills the warm pool for a fraction of the cost of keeping everything hot. For a PaaS, that combination — millisecond claim, second-scale resume, near-zero idle cost — is the entire economic argument in one paragraph.

Adopt vs build vs buy: the decision table​

The honest question is not whether agent sandboxes are good, but which of three paths a self-hosted platform should take. Anchored on a typical workload — bursty coding agents that run for minutes, idle for hours, and must never see each other's filesystem or credentials — the comparison looks like this:

Two rows deserve emphasis. First, the self-host fit row is where the upstream CRD wins outright: if your platform already reconciles Cluster API machines and ships tenant apps as pods, agent runtimes become just another reconciled object on the same fleet — the same Prometheus, the same GitOps repo, the same node pool, with RuntimeClass as the only new node-level concern. Second, the maturity row is where the vendor wins outright: E2B, Daytona, and Modal are done, documented, and supported today, while the upstream project is still migrating its API surface from v1alpha1 to v1beta1 and cutting breaking releases like v0.5.0's warmpoolRef change.

The bespoke middle column is the one to be skeptical of. Every bespoke sandbox service eventually re-implements warm pools, snapshot/resume, per-tenant quotas, and a claim API — the exact four things the upstream CRD now standardizes. Unless you have a genuinely exotic requirement (custom hypervisor, air-gapped snapshot store), building a third sandbox control plane next to the two that already exist is engineering vanity.

What still doesn't work​

Adopting early means tracking real gaps, not marketing ones. Here is the checklist, with status:

• API churn (active). The v1alpha1-to-v1beta1 migration is underway, with conversion webhooks and manifest rewrites landing across 2026 releases. Pin your version, read the release notes before every upgrade, and keep templates in Git so a rename is a search-and-replace, not an archaeology project.
• GPU scheduling (partial). Agent sandboxes that need inference or training muscle depend on Dynamic Resource Allocation and the device-plugin ecosystem maturing around fractional GPU sharing and topology-aware placement. CPU-only sandboxes are ready; GPU-backed pools are still a design project.
• Quota and fairness (you build it). The CRD gives you objects, not policy: per-tenant pool quotas, fair-share across competing claims, and cost attribution still need your own admission control and metering. Kubernetes ResourceQuota covers the basics; noisy-neighbor fairness across a shared warm pool does not come free.
• Control-plane scale (known ceiling). Standard Kubernetes is tuned for thousands of long-running services, not millions of sub-second tool calls. Google's answer is telling: it open-sourced Agent Substrate precisely to bypass that chatter, targeting 10x density over standard runtimes with sub-500ms resumes at over 500 suspend/resume operations per second. Below that ultra-scale tier the CRD is fine; past it, budget for a second control-plane story.
• Firecracker-class isolation (adjacent). The upstream default is gVisor with Kata as the VM-grade option, including Kata's Firecracker backend. If your threat model demands Firecracker microVMs orchestrated Kubernetes-natively with checkpoint/restore semantics the upstream project does not yet own, adjacent projects like Setec show the shape — but that is a second adoption bet, not part of this one.

None of these gaps is a veto for a typical PaaS cohort: CPU-backed coding agents, bursty usage, tens to thousands of concurrent sandboxes. They are vetoes only at the extremes — GPU-heavy inference fleets and million-sandbox control planes — where you should be piloting, not committing.

What it means for a self-hosted PaaS roadmap​

Concretely, here is the adoption sequence for a platform that already runs a Cluster API fleet:

1. Install the controller and RuntimeClasses on the existing fleet. No new cluster, no new control plane — the sandbox controller is one more reconciler next to the ones you already run. Stand up gVisor and kata RuntimeClasses and verify them with an untrusted smoke workload before any tenant traffic.
2. Write one template per tenant tier. A free-tier template (gVisor, tight CPU/memory envelope, default-deny egress) and a paid-tier template (Kata option, larger envelope, snapshot-enabled) cover most cohorts. Templates are versioned YAML, so tier changes ride your normal GitOps flow.
3. Size one warm pool and measure the claim rate. Start from the reference numbers — sub-second claim, p90 at 200ms — and size the pool against your peak agent-spawn rate, not your average. Let the suspended-VM cold pool absorb the troughs.
4. Add quota and metering before opening the floodgates. Per-namespace quotas on claims, per-tenant pool slices, and suspend-on-idle defaults are the three policies that separate a demo from a service.
5. Revisit the build-vs-adopt call at GPU time. The day your roadmap needs GPU-backed sandboxes, re-run the decision table: DRA maturity, device-plugin coverage for your node hardware, and whether the upstream project's GPU story has caught up to your timeline.

The strategic payoff is architectural uniformity. Tenant web services, workers, and now agent runtimes all become reconciled objects on one fleet, described in one repo, observed by one stack. That is a materially smaller operational surface than running a PaaS plus a separate E2B-style Nomad/Consul sidecar fleet — which is exactly what E2B's own self-hosted Terraform deploys — just to execute agent code.

The sandbox becomes infrastructure​

Every platform shift eventually turns its hardest bespoke component into boring infrastructure. Container orchestration did it to schedulers; GitOps did it to deploy scripts. The Sandbox CRD is doing it to agent execution: warm pools, snapshot resume, and pluggable isolation are becoming cluster features you configure, not services you build.

The timing favors early adoption with pinned versions. The API is stabilizing, not stable — but the direction is unambiguous, the reference implementation is GA on GKE with production customers, and the ecosystem (PyPI SDK, warm-pool pre-provisioning, multi-runtime support) is growing around the standard shape. A self-hosted PaaS that adopts the CRD now buys itself the standard interface at the cost of tracking a migration; one that builds bespoke buys itself a permanent maintenance burden at the cost of never quite matching the upstream feature velocity.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents as first-class operators. Star the repo on GitHub or deploy your first app today.