What Is CreateOS Sandbox?

CreateOS Sandbox is a runtime for code your agents write. Every session runs in a Firecracker microVM with its own guest kernel, not a shared-kernel container. You can pause, resume, and fork a running machine, govern outbound access with an allowlist enforced on the host, and run the same API on your own infrastructure when code cannot leave your boundary.

Why Untrusted Code Needs Its Own Machine

Your agents write code all day. Almost none of it is reviewed line by line. Yet that code runs somewhere, often close to credentials, network routes, and your data. A container keeps the code in a namespace. It does not keep it off your kernel.

CreateOS Sandbox is the machine boundary for that code. Each session gets a Firecracker microVM with its own guest kernel, and the controls around it are enforced on the host where the code cannot reach them. It is self-serve: an SDK, a CLI, an MCP server, and a documented API, with no sales call in the way. You bring the code. The sandbox is the computer that contains it.

The Five Facts That Matter

Every sandbox is a Firecracker microVM with its own guest kernel. The isolation boundary is a machine, not a namespace.
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. Inbound is closed by default either way.
Pause, resume, and fork are built in. Pausing takes about 1.4 seconds and stops the meter. Same-host resume returns in under 0.7 seconds.
Sandboxes can join private overlay networks with per-network private DNS, so a team of agents finds each other by name with no public exposure.
It is metered per second with $0 egress, new accounts start with 500 free credits, and bring-your-own compute and storage keep sessions on your infrastructure when required.

Why CreateOS Sandbox Fits the Job

The test is simple: what happens when the code misbehaves?

On a shared-kernel container, a kernel-level escape in untrusted code touches a host other workloads share. On a CreateOS Sandbox, the same escape lands inside a machine built to be thrown away, with nothing else on it. Isolation is the default state, not a setting someone has to remember.

Egress is the second half. An allowlist configured inside the guest can be disabled inside the guest. CreateOS enforces egress rules in the host kernel with eBPF, so they hold even against a full guest compromise. Code inside the VM cannot rewrite or route around them.

The combination is the actual product. Isolation alone is table stakes; every vendor claims a VM. Sandbox-to-sandbox networking, host-enforced egress, and full self-hosting together are what most teams otherwise stitch by hand. The fit shows in the work: a coding tool previewing what the model wrote, an agent that pauses for a human decision and resumes exactly where it stopped, customer-written code in a multi-tenant app where one customer cannot see another's machine.

Two cases where it does not fit: teams that only ever run code their own team wrote and reviewed, and workloads that need GPUs. GPU sandboxes are not offered.

What CreateOS Sandbox Does

Creates machines in tens of milliseconds. A new session starts from snapshot restore, about 30 ms on an idle host. That figure is a measured idle number, not an SLA. Shapes run from a quarter CPU up to 8 CPU with 16 GB of memory and 10 to 60 GB of disk, so the machine matches the workload.

Governs outbound access from the host. Set rules through the egress field at create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or createos sandbox firewall set on the CLI. Rules accept hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. The docs cover each route.

Pauses, resumes, and forks state. Pausing writes a snapshot of full guest state and stops compute billing, in about 1.4 seconds. Same-host resume restores the exact machine in under 0.7 seconds. A cross-host cold start runs 11 to 13 seconds. Forking a paused sandbox branches its memory and disk, so an agent can build several candidate fixes in parallel and you keep the one that behaves.

Networks sandboxes privately. Attach sandboxes to a private overlay network with per-network private DNS. Traffic between networks is denied by default.

Runs where you need it. Bring your own bucket (S3, R2, MinIO) and bring your own compute: the same API on customer machines, with the control plane and storage self-hostable when code cannot leave your boundary.

Reports what happened. Interactive shell and SSH forwarding get you inside the machine. Traces and usage dashboards are live, so you see what the code did and what it cost, per run.

The Numbers Behind It

Adoption first: 2.6 million sandboxes created since June 2026. CreateOS has run its own CI on sandboxes since July 2026, and its GitHub Actions runner and coding-agent plugin are working code, not roadmap items.

Uptime runs at 99% or better. The infrastructure underneath is operated by NodeOps, the infrastructure company behind CreateOS, operating production infrastructure since December 2023.

One caveat, stated plainly: this is a young product moving fast. Its own CI and plugins are the usable proofs. Formal compliance certifications are on the roadmap, not shipped, for the Sandbox surface. Judge it on the architecture and the numbers above.

What to Weigh Before You Commit

The egress default is open outbound. Outbound access stays open until you set at least one rule. If your threat model assumes deny-by-default networking, set the rule in the same create call. Inbound is closed regardless.

Cold starts across hosts cost seconds. Same-host resume is under 0.7 seconds. A cross-host cold start runs 11 to 13 seconds. Placement matters for latency-sensitive loops.

No GPUs. Workloads that need them need another home.

Certifications are not shipped here. If procurement needs a certification report for this surface today, raise it before you commit rather than after.

Self-host is the escape hatch. If code cannot leave your boundary, the same API runs on your machines with your own S3, R2, or MinIO bucket underneath.

Frequently Asked Questions

Is CreateOS Sandbox a container?

No. Each sandbox is a Firecracker microVM with its own guest kernel. A container isolates with namespaces on a shared kernel. The sandbox boundary is a machine, which is the difference that matters when the code is untrusted.

Is outbound network access blocked by default?

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

How fast is CreateOS Sandbox?

Creation from snapshot restore lands in tens of milliseconds, about 30 ms on an idle host, a measured figure rather than an SLA. Pause takes about 1.4 seconds. Same-host resume is under 0.7 seconds. A cross-host cold start runs 11 to 13 seconds.

What does it cost to try?

New accounts start with 500 free credits. Billing is per second, egress bills at $0, and pausing stops the meter. The Sandbox pricing page publishes the current rates.

The Bottom Line

If your product makes agents write code, that code needs a machine that assumes the worst: its own kernel, its own egress rules enforced from outside, a lifecycle that ends. CreateOS Sandbox is that machine, self-serve with an SDK, a CLI, and no sales call. Start free with 500 credits on the CreateOS Sandbox product page, or read the docs and make the first call yourself.

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.