Comparison

Containarium vs agent-sandbox

This one isn't either/or. agent-sandbox is the Kubernetes SIG Apps project that defines the Sandbox resource: one stateful pod with stable identity and storage. Containarium's Kubernetes backend creates agent-sandbox Sandbox resources and adds the layer an agent needs on top: SSH access with no cluster credentials, an MCP server, a hostname, and egress policy.

Choose Containarium when…

  • Agents should reach their sandbox over SSH, holding no kube-apiserver token.
  • You want an MCP server in every sandbox, with no client library.
  • You want the same CLI across Kubernetes and plain LXC hosts.
  • You need hostnames, TLS, and egress allowlists out of the box.

Choose agent-sandbox when…

  • You're building your own platform and want the bare Kubernetes primitive.
  • You want warm pools and templates driven directly from Go or Python.
  • Clients already have cluster access and that fits your threat model.
  • You only need the controller, not a product around it.

agent-sandbox is the primitive; Containarium is a runtime built on it.

Side-by-side

Dimension Containarium agent-sandbox
What it is An agent runtime: CLI, daemon, SSH gateway, MCP server, cloud A Kubernetes controller and CRDs (Sandbox, SandboxTemplate, SandboxClaim, SandboxWarmPool)
Relationship The K8s backend creates agent-sandbox Sandbox resources —
How clients connect SSH through the sentinel (sshpiper); no cluster credentials in the agent Go and Python SDKs, a sandbox router, or Kubernetes access
Agent interface MCP server in every box None built in
Isolation Pod under the cluster default runtime, or gVisor via RuntimeClass; LXC on non-K8s hosts Delegates to the runtime (gVisor, Kata Containers)
Networking Hostname + TLS per box; per-tenant eBPF egress allowlists Kubernetes Service; NetworkPolicy
Backends Kubernetes or Incus/LXC behind one CLI Kubernetes
License Apache 2.0 Apache 2.0

agent-sandbox details checked against its public docs and pricing pages in September 2026. Check agent-sandbox's own docs for current specifics.

Why we built on it

agent-sandbox gives Kubernetes the right shape for an agent: a singleton, stateful pod with stable identity that survives restarts. Rather than reinvent that, Containarium's Kubernetes backend creates a Sandbox resource per box and lets the agent-sandbox controller own the pod. We benchmarked the two side by side: 373 vs. 373 sandboxes per node, after fixing a bug the benchmark exposed on our side.

What sits on top

The part agent-sandbox deliberately leaves out is how an untrusted agent gets in. Reaching a pod through the Kubernetes API means handing the agent credentials to your control plane. Containarium's agents hold an SSH key scoped to one box; the sentinel routes it to the pod. We wrote up one consequence of that choice in gVisor breaks kubectl, not SSH.

FAQ

Does Containarium use kubernetes-sigs/agent-sandbox?

Yes. Containarium's Kubernetes backend creates agent-sandbox Sandbox resources for each box and lets the agent-sandbox controller manage the pod. Containarium adds SSH access, an MCP server, hostnames and egress policy on top.

Do agents need Kubernetes credentials to use Containarium?

No. Agents connect over SSH through Containarium's sentinel and hold a key scoped to their own box, with no path to the kube-apiserver.

Should I use agent-sandbox directly?

Use agent-sandbox directly if you are building your own platform on Kubernetes and want the bare primitive. Use Containarium if you want a finished agent runtime on top of it, or the same experience on non-Kubernetes LXC hosts.

The agent runtime on top of the Kubernetes primitive.

Start free on the hosted cloud, or self-host the open source on your own VM.

Try Containarium Cloud How the agent sandbox works

Also comparing? vs E2B · vs Modal · vs Daytona · vs Runloop · vs Morph Cloud · vs Sprites · vs Docker Sandboxes · vs GitHub Codespaces · vs AWS Lambda · vs Cloudflare Containers