CreateOS Sandbox vs a Kubernetes Plugin for Running Agent Code

If your agents write code, the question is where that code runs. A Kubernetes plugin runs untrusted code as a container on a shared kernel, inside a cluster you then have to harden. CreateOS Sandbox gives every session its own Firecracker microVM with its own guest kernel, host-enforced egress rules, and pause, resume, and fork.

Introduction

Platform teams building agent products usually reach for the tooling they already run. Kubernetes is there, the team knows it, and a plugin or custom controller can spin up a pod, drop the agent's code in, and tear it down after. That works until the code misbehaves. Containers share the host kernel. A container escape, a noisy neighbor, or an agent that phones home turns one pod into a cluster-wide incident.

CreateOS Sandbox takes a different position: code you cannot trust should not share a kernel with anything. Each session is a Firecracker microVM with its own guest kernel, created in seconds from a snapshot, billed per second, and reachable only where you allow. This post compares the two approaches on isolation, egress control, networking, speed, and cost, so you can pick the right runtime for agent-written code.

Key Takeaways

A Kubernetes plugin runs untrusted code as a container on a shared kernel. CreateOS Sandbox runs it in a Firecracker microVM with its own guest kernel, so isolation is the default, not a policy you configure.
Outbound access in a sandbox is open until you set at least one egress rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest.
Sandboxes can join private overlay networks with private DNS, so multi-agent systems talk directly without public exposure.
Pause, resume, and fork let you branch a running session's state for parallel rollouts, and pause stops the meter.
Bring your own compute and storage means the same API runs on your own machines when code cannot leave your boundary.

Why CreateOS Sandbox Fits Where a Kubernetes Plugin Falls Short

Kubernetes was designed to schedule workloads you trust: your services, your batch jobs, your reviewed deploys. A plugin that runs agent-written code inverts that assumption. To make a pod safe for untrusted code you need a hardened stack of add-ons: a sandboxed runtime or gVisor-style shim, NetworkPolicies that are correct and actually enforced, resource quotas, Pod Security Standards, and audit tooling. Each layer is one more thing to configure, and one more thing that can be misconfigured.

The kernel is the hard part. Containers isolate with namespaces and cgroups, but they share the host kernel. A kernel-level escape from one pod is an escape onto the node. For code your own team wrote and reviewed, that risk is usually acceptable. For code an LLM generated five seconds ago, it is a different risk class.

There is also the lifecycle problem. Agents run for hours, wait on human approval, and need to be branched for parallel attempts. Kubernetes can approximate this with checkpoints and custom controllers, but you end up writing and maintaining that machinery yourself.

Key Capabilities: What a MicroVM Gives You That a Kubernetes Plugin Does Not

CreateOS Sandbox is a Firecracker microVM with its own guest kernel. Not a container, not a shared-kernel process namespace. Isolation sits at the machine boundary, by default, not as a setting you have to remember.

Egress governance on the host. Outbound access is open until you set at least one rule; once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. Code inside the VM cannot rewrite or route around it. Rules take hosts, host:port, wildcard subdomains, IPs and CIDRs, and you can set them at create time, update them live through the API, or use the SDK's setEgress or the CLI's firewall command. Inbound is closed by default regardless.

Networking between sandboxes. Attach sandboxes to a private overlay network so multi-agent systems talk directly with no public exposure, with per-network private DNS. Traffic between networks is denied by default. This is the piece most sandbox setups, and most Kubernetes sidecar patterns, leave you to build.

Pause, resume, fork. Pausing writes a snapshot of full guest state and stops compute billing. Resume restores that exact machine. Forking a paused sandbox branches its memory and working state, so you can run N candidate fixes in parallel and keep the winner.

Bring your own everything. Bring your own S3-compatible storage (S3, R2, MinIO) and bring your own compute: the same API runs on your own machines. Self-host the control plane and storage entirely if code cannot leave your boundary.

Speed and Cost, With the Numbers

Sandbox creation restores from snapshot rather than cold booting: about 30 ms on an idle host, though that is an idle-host figure, not an SLA. Pause takes about 1.4 seconds. Same-host resume comes in under 0.7 seconds; a cross-host cold start runs 11 to 13 seconds. Shapes scale from a quarter CPU up to 8 CPUs and 16 GB, with 10 to 60 GB of disk.

Billing is per second, egress is $0, and pause stops the meter. You scale on concurrency, not unit price. New accounts start with 500 free credits, and pricing is on the Sandbox pricing page.

Proof and Evidence

2.6 million sandboxes created since June 2026 (as of 1 October 2026). CreateOS's own CI has run on sandboxes since July 2026, and the coding-agent plugin and GitHub Actions runner are usable proofs. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

The tradeoff, stated plainly: CreateOS Sandbox is a young product, and it is not for teams that only ever run code their own team wrote and reviewed, or for anyone needing GPUs. If your workloads are trusted, reviewed, and long-lived, Kubernetes is a fine home for them. The question this post answers is specifically about code you cannot trust.

What to Weigh Before Deciding

Trust boundary. If the code is agent-written or customer-supplied, a per-session microVM is the cleaner default. If it is your own reviewed code, a container is fine.
Egress discipline. Decide the allowlist model up front. Remember the default: outbound is open until you set a rule.
Where the code may run. If it cannot leave your infrastructure, use bring-your-own compute or self-host the control plane.
Lifecycle needs. If agents pause on human approval or need parallel rollouts, snapshot-based pause, resume, and fork save you from building it.
GPU workloads. Sandbox does not offer GPU sandboxes today.

You can start free and spin up your first sandbox at createos.sh/products/sandbox, and the docs cover the SDK, CLI, and egress rules in detail.

Frequently Asked Questions

Is a Kubernetes pod not isolated enough for agent code?

A pod isolates with namespaces and cgroups but shares the host kernel. A Firecracker microVM has its own guest kernel, so the isolation boundary is the machine, not the namespace. For untrusted or agent-written code, the machine boundary removes a whole class of escape scenarios.

Do I have to configure egress rules before a sandbox can reach anything?

No. Outbound access is open until you set at least one rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest. Inbound is closed by default either way.

Can sandboxes talk to each other privately?

Yes. Attach them to a private overlay network with per-network private DNS, so agents find each other by name with no public exposure. Traffic between networks is denied by default.

Can this run on our own infrastructure?

Yes. Bring your own compute runs the same API on your machines, you can bring your own S3, R2, or MinIO storage, and you can self-host the control plane and storage entirely.

Conclusion

A Kubernetes plugin repurposes a scheduler built for trusted workloads and asks you to harden it into a sandbox, one policy at a time. CreateOS Sandbox starts from the other end: a Firecracker microVM per session, its own guest kernel, egress rules enforced on the host, private networking between sandboxes, and pause, resume, and fork as primitives. If your product ships code your agents wrote, run it on a machine built for that. Start at createos.sh.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.