A Sandbox Service Where Every Run Gets a Real VM, Not a Container

Yes. CreateOS Sandbox gives every run a Firecracker microVM with its own guest kernel, so untrusted or agent-written code never shares a kernel with anything else. Sessions resume from snapshot in tens of milliseconds on an idle host, and you can pause, resume, or fork one. Here is what that gets you and where the tradeoffs sit.

Introduction

Ask most sandbox services what runs under your code and the answer is a container. Containers are cheap to provision and easy to pack densely, which is why the default exists. The cost sits elsewhere: containers share the host kernel. Every workload on that machine runs on the same kernel, and when the code is untrusted, a kernel bug becomes an escape route.

A virtual machine draws the line lower. Each run boots its own guest kernel. Nothing else lives on that machine. So the question behind your question has a precise form: does each run get its own kernel, or a namespace on a shared one? CreateOS Sandbox answers it with a real VM per session. The rest of this post covers what that gets you, the numbers behind it, and what to check before you commit.

Key Takeaways

Every CreateOS Sandbox session runs in a Firecracker microVM with its own guest kernel. Not a container. Not a shared-kernel process namespace.
Isolation is on by default. Outbound access is open until you set at least one egress rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
A sandbox resumes from snapshot in tens of milliseconds on an idle host. Pause takes about 1.4 seconds and stops the meter.
Sandboxes join private overlay networks with private DNS, so a team of agents talks directly with no public exposure.
Bring your own compute and buckets (S3, R2, MinIO) when sessions must stay inside your boundary. New accounts start with 500 free credits.

Why a Real VM Per Run Fits the Problem

The question is about trust. Agent-written code is code nobody reviewed line by line. Code your customers wrote is code you have no reason to trust at all. Both need a boundary that does not depend on the guest behaving.

A container's boundary is the shared kernel plus its hardening. A microVM's boundary is the machine itself: its own kernel, minimal and per run. Hostile code inside a sandbox is attacking a machine that exists for that one session. Our published analysis of a sandbox escape in an AI agent shows what happens when code hunts for exactly this kind of gap.

Isolation alone is table stakes, though. A VM you cannot govern is just a smaller blast radius. The combination is the point: per-VM kernel, egress rules enforced on the host, sandbox-to-sandbox networking, and full self-host when the boundary has to sit inside your own cloud.

What a VM Per Run Actually Gets You

A kernel per session. Each sandbox is a Firecracker microVM with its own guest kernel. Isolation is the default state, not a flag you have to remember to set.

Egress rules the guest cannot touch. Outbound access is open until you set at least one rule. Inbound is closed either way. Rules take IPs, CIDRs, ports, and domains, and enforcement sits in the host kernel with eBPF, outside the VM. Set them at create time, update them live through the API, or use the SDK or CLI. The docs cover each route.

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 an agent can try three fixes in parallel and keep the one that works.

Networking without exposure. Private overlay networks let sandboxes find each other by name over private DNS. Traffic between networks is denied by default.

Your hardware when you need it. Bring your own compute runs the same API on machines you control. Bring your own bucket keeps snapshots on your S3, R2, or MinIO. Self-host the control plane and storage entirely when code cannot leave your boundary.

The Numbers Behind the Claim

2.6 million sandboxes created since June 2026.
CreateOS's own CI has run on sandboxes since July 2026.
99%+ uptime.
NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.
Speed: resume from snapshot about 30 ms on an idle host, an idle-host figure and not an SLA. Pause about 1.4 seconds. Same-host resume under 0.7 seconds. Cross-host cold start 11 to 13 seconds.
Commercial shape: per-second billing, $0 egress, 500 free credits. Current rates are on the Sandbox pricing page.

CreateOS Sandbox is a young product, and the proof offered here is specific: the figures above, a CI that runs on it daily, and an API you can test in an afternoon. Compliance certifications are on the roadmap for the Sandbox surface, not shipped. Weigh that against the isolation argument and decide what your workload needs.

What to Check Before You Pick a VM Sandbox

Ask the kernel question directly. Does each run get its own guest kernel, or a container on a shared one? A service that says "microVM" should be able to name the technology. Ours is Firecracker.

Test the egress default. Outbound open until a rule is set is the correct description of how CreateOS works. If a vendor claims outbound is locked down before you configure anything, test the claim with a callback to a host you control.

Price the idle time. Per-second billing with pause stopping the meter rewards a different architecture than per-hour pricing. Cross-host cold starts run 11 to 13 seconds, so decide whether snapshot placement or a longer idle window covers your scale-out pattern.

Decide where the boundary sits. If sessions handle data that cannot leave your cloud, bring your own compute and storage, or self-host the control plane. If your workload needs GPUs, CreateOS Sandbox does not offer GPU sandboxes today.

Match the shape to the workload. Sizes run from a quarter CPU up to 8 CPUs with 16 GB of memory and 10 to 60 GB of disk. Templates ship with Node, Bun, Python, Go, and Rust, or bring your own Dockerfile.

Frequently Asked Questions

Is a Firecracker microVM a real virtual machine?

Yes. Each CreateOS Sandbox session boots a Firecracker microVM with its own guest kernel. It is not a container and not a shared-kernel process namespace.

How fast does a sandbox start?

A sandbox resumes from a snapshot in tens of milliseconds, about 30 ms on an idle host. That figure is an idle-host measurement, not an SLA. Same-host resume completes in under 0.7 seconds. A cross-host cold start takes 11 to 13 seconds.

Is outbound network access restricted by default?

No. Outbound access is open until you set at least one egress rule. Inbound is closed by default regardless. Once a rule is set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest, so code inside cannot rewrite or route around it.

Can the VMs run on my own infrastructure?

Yes. Bring your own compute runs the same sandbox API on machines you control, and bring your own bucket keeps snapshots on your own S3, R2, or MinIO. The control plane and storage can be self-hosted entirely when code cannot leave your boundary.

Bottom Line: Ask for the Kernel Per Run

The service you are asking about exists. The criterion that separates it from container-based sandboxes is one sentence long: every run gets its own guest kernel, and the egress rules that govern it are enforced outside that kernel, on the host. CreateOS Sandbox is built on that combination, with pause, resume, and fork so agent state is something you branch instead of rerun.

Run your first untrusted workload on one. New accounts start with 500 free credits, billing is per second, and egress is $0: create your first sandbox.

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.