🌏 中文版
What This Post Is
This post is the "self-hosted" post (order 17) of the Sandbox Series. It doesn't compare single managed providers (in order 7–16), but focuses on enterprise self-hosted sandboxing:
- Kata Containers — OCI-compliant lightweight VM containers
- Kubernetes-sigs/agent-sandbox — Kubernetes-native sandbox controller
- BYOC (Bring Your Own Cloud) — Deploy sandbox control plane on own cloud
- Build vs. buy decision framework — When to self-build vs. use managed
- Migration strategy — From managed to self-hosted, or vice versa
Kata Containers
What is Kata Containers
Kata Containers is an OCI (Open Container Initiative) compliant lightweight VM container. Each Pod is a micro VM, each workload has its own minimal kernel, they don't share the kernel.
Architecture
┌─────────────────────────────────────┐
│ Kubernetes │
│ - Kata RuntimeClass │
│ - Pod scheduling │
└─────────────────────────────────────┘
│
┌─────────────────────────────────────┐
│ Kata Runtime │
│ - One micro VM per Pod │
│ - Independent kernel │
└─────────────────────────────────────┘Integration with Docker / containerd
Kata Containers can integrate with containerd as a RuntimeClass in Kubernetes:
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: kata
handler: kata
---
apiVersion: v1
kind: Pod
metadata:
name: untrusted-agent
spec:
runtimeClassName: kata
containers:
- name: agent
image: agent-image:latestPros and Cons
| Pros | Cons |
|---|---|
| Hardware-level isolation (one VM per Pod) | Slower startup (~200ms) |
| Native Kubernetes integration | Higher memory overhead |
| OCI compliant | Requires KVM support |
| GPU passthrough | Higher operational complexity |
Kubernetes agent-sandbox
What is agent-sandbox
kubernetes-sigs/agent-sandbox is the Kubernetes community's official sandbox controller, designed specifically for AI agent execution environments. It decouples workload lifecycle management from isolation backend selection.
Core Features
1. Lifecycle Management
The agent-sandbox controller handles the full sandbox lifecycle: creation, scheduled deletion, pause (hibernation), auto-resume (on network connection).
apiVersion: agent.sigs.k8s.io/v1alpha1
kind: Sandbox
metadata:
name: agent-sandbox-01
spec:
runtimeClass: kata
hibernation:
enabled: true
idleTimeout: 300s
persistentStorage:
size: 10Gi2. Pluggable Isolation Backend
Supports standard containers, gVisor, Kata Containers, and other OCI-compliant runtimes.
3. Python and Go SDK
Provides high-level client libraries for programmatic sandbox management.
Guest Agent
agent-sandbox is developing a "Guest Agent" — a lightweight daemon running inside each sandbox Pod, providing lifecycle hooks (freeze, fsfreeze, collapse, init), ensuring snapshot state consistency and optimizing resume latency.
BYOC (Bring Your Own Cloud) Model
What is BYOC
BYOC means enterprises deploy sandbox control plane on their own cloud (AWS, GCP, Azure, or on-premises), rather than using managed provider cloud services.
Why Choose BYOC
| Reason | Description |
|---|---|
| Data sovereignty | Data must stay in specific region or self-owned infrastructure |
| Compliance requirements | Strict compliance for finance/healthcare |
| Existing infrastructure | Enterprise already has Kubernetes cluster, no extra cost |
| Network control | Full control over network policy and firewall |
Implementation Options
- OpenSandbox BYOC: Alibaba Cloud OpenSandbox supports deploying control plane on AWS, GCP, Azure
- Kata + Kubernetes self-hosted: Build with Kata Containers + Kubernetes agent-sandbox
- E2B Embed: E2B provides self-hosted version (E2B Embed), runnable on own cloud
Build vs. Buy Decision Framework
| Decision Factor | Choose Managed Sandbox | Choose Self-Build |
|---|---|---|
| Scale | < 10K executions/month | > 1M executions/month |
| Engineering team | No dedicated infra team | Has platform engineering team |
| Compliance requirements | General compliance | Strict compliance (finance/healthcare) |
| Data sovereignty | Data can cross borders | Data must stay within borders |
| Time to market | Need to launch immediately | Can spend months building |
| Cost sensitivity | Willing to pay premium for convenience | Want to reduce long-term unit cost |
Total Cost of Ownership (TCO) Comparison
| Cost Item | Managed Sandbox | Self-Hosted Sandbox |
|---|---|---|
| Compute resources | Pay-per-use | Self-owned infrastructure amortized |
| Engineering labor | Minimal | Requires dedicated team |
| Operational overhead | Provider responsible | Self-responsible |
| Upgrades and maintenance | Provider responsible | Self-responsible |
| Compliance certifications | Provider provided | Self-obtained |
Rule of thumb: If monthly sandbox executions < 10K, managed sandbox TCO is usually lower; if > 1M/month, self-build may be more economical but requires dedicated team.
Migration Strategy
From Managed to Self-Build
- Abstract sandbox interface: Build abstract interface at application layer, wrap specific provider SDKs
- Standardize images: Use OCI container images for easier migration across environments
- Externalize state: Store sandbox state in external storage services, not inside sandbox
- Gradual migration: First migrate non-critical workloads, verify, then migrate critical workloads
From Self-Build to Managed
- Evaluate managed providers: Compare E2B, Daytona, Modal, Bedrock AgentCore, etc.
- Export images and state: Export self-hosted sandbox images and state
- Test and verify: Test agent workflows in managed environment
- Switch traffic: Gradually switch traffic to managed sandbox
What You Should Understand After Reading
- Kata Containers architecture and Kubernetes integration.
- agent-sandbox core features and Guest Agent role.
- BYOC model definition and applicable scenarios.
- Build vs. buy decision framework and TCO comparison.
- Migration strategy: from managed to self-hosted, or from self-hosted to managed.