Give Every Agent Its Own Computer.
CreateOS Sandbox runs each workload in a Firecracker micro-VM with its own kernel. Connect sandboxes over a private network, pause to zero with state preserved, and never pay an egress fee. Drive it from a TypeScript SDK, the CLI, or MCP.
Spin up a Sandbox in Seconds.
Install the SDK, then drive sandboxes from TypeScript, the CLI, or MCP, so an agent can provision its own compute through a tool call. Spawn it, run a command, read the output, tear it down.
npm install @nodeops-createos/sandbox
# or: bun add @nodeops-createos/sandboximport { CreateosSandboxClient } from "@nodeops-createos/sandbox";
// baseUrl from CREATEOS_SANDBOX_BASE_URL, apiKey from CREATEOS_SANDBOX_API_KEY
const client = new CreateosSandboxClient();
const sandbox = await client.createSandbox({
shape: "s-4vcpu-4gb",
rootfs: "devbox:1",
});
try {
const { result } = await sandbox.runCommand("node", ["--version"]);
console.log(result.stdout); // "v20.x.x"
} finally {
// sandboxes bill while running, so always tear down
await sandbox.destroy();
}A Real Machine Boundary, Not a Shared Kernel.
Every sandbox is a Firecracker micro-VM running its own Linux kernel. That is the gating difference: the isolation is at the level of the machine, not a process namespace you hope holds.
Its own kernel
Every sandbox is a Firecracker micro-VM running its own Linux kernel. There is no shared kernel to escape, so the boundary is the hardware-level isolation a real machine gives you.
Blind to everything else
Code inside one sandbox cannot see the host or any other tenant. Run untrusted or model-generated code without exposing your infrastructure.
Contained by default
A guest kernel compromise stays inside that one micro-VM. It does not spread to the host or to the rest of your fleet.
How the Sandbox is Built
Each sandbox runs in a Firecracker micro-VM with its own kernel. Sandboxes connect to each other over a private network. Egress goes outbound only, and the disk syncs to the object storage you control.
Network egress
Pause to Zero, Resume in Place.
A paused sandbox is a Firecracker snapshot on disk: guest memory and device state are frozen, and compute billing stops. Resuming restores that exact state into a new micro-VM instead of cold-booting, so a multi-step agent run survives idle gaps without losing its place.
Pause is a snapshot, not a shutdown
Pausing serializes the full guest state, the RAM, the vCPU registers, and the device state, to a Firecracker snapshot on disk, then stops the VM. Compute billing drops to zero while it is paused.
Resume restores state, not a reboot
Resuming maps the snapshot back into a fresh micro-VM. Processes, open file descriptors, and memory come back exactly as they were, so the agent continues mid-task with no cold boot and no setup to re-run.
Auto-pause on idle
Set an inactivity timeout and the sandbox snapshots itself when no command is running. Idle agents hold their state without holding a compute bill.
Templates are pre-baked rootfs
Save a configured sandbox, its root filesystem and installed dependencies, as a template, then launch identical environments from it in a single call. No reprovisioning per run.
Your Data, in Your Buckets.
Keep a run's output without copy steps, and keep it in storage you own. Moving data costs nothing extra.
Disk syncs automatically
The ephemeral disk syncs on its own, so a run's output is captured without manual copy steps.
Mount your own buckets
Mount your own Amazon S3, MinIO, or Cloudflare R2 as a filesystem. The data stays in storage you control.
No egress fees, ever
Move data in and out without per-gigabyte egress charges. What you read and write is yours to move freely.
Simple per-Second Pricing.
Pay only while a sandbox runs. No egress fees, no minimums. Priced at the E2B and Daytona reference rate, with the comparison published.
Go Deeper
The capabilities that make CreateOS Sandbox the governed sandbox, each in depth.
Networking between sandboxes
Private overlay networks and multi-node clusters inside isolation.
Learn moreEgress you can prove
Kernel-enforced allowlist, no ingress, containment you can demonstrate.
Learn moreSelf-host the whole thing
Run the control plane and storage in your own boundary.
Learn moreA safe computer for agents
Isolation, fork, networking, and pause mapped to how agents work.
Learn moreReliability and failure modes
What happens when untrusted code OOMs, loops, or tries to phone home.
Learn moreExamples
Runnable demos: agent code-exec, fork, multi-node, self-host, and more.
Learn moreCommon Questions
How isolated is each sandbox?
Each sandbox is a Firecracker micro-VM with its own kernel. Code cannot reach the host or other tenants, so you can run untrusted or AI-generated code safely.
Can sandboxes talk to each other?
Yes, over a private network, so you can build multi-agent systems where each agent runs in its own isolated sandbox and communicates directly, with no public exposure.
What happens when a sandbox is idle?
It auto-pauses to zero with full state preserved, and resumes in place. You only pay while it is running.
What is preinstalled, and where does it run?
Ubuntu 26.04 with Node.js, Bun, Python, Go, Rust, and the Pi agent, in EU or US regions. You can also save templates.
Can I use my own storage?
Yes. Mount your own Amazon S3, MinIO, or Cloudflare R2 as a filesystem; the disk syncs automatically.
How do I drive sandboxes?
A TypeScript SDK, the CLI, or MCP, so an agent can provision its own compute through a tool call.
Where can I safely run AI-generated code?
In CreateOS Sandbox. Each run gets its own Firecracker micro-VM with its own guest kernel, an egress allowlist enforced in the kernel via eBPF, and no ingress by default, so untrusted or model-generated code cannot reach your host, your network, or the open internet unless you allow it.
How do I restrict and prove what untrusted code can reach?
Egress is an allowlist with no ingress by default, enforced in the kernel via eBPF outside the VM. Code inside a sandbox cannot rewrite or route around it. You allow specific hosts, everything else is denied, and you can read exactly what was blocked.
Can I self-host the sandbox in my own cloud?
Yes. Run the control plane and storage in your own environment and bring your own object storage (S3, R2, Tigris, or MinIO), so code, snapshots, and data never leave your boundary. During alpha, self-host is the interim control for regulated teams while certifications are on the roadmap.
How do I fork a running sandbox to branch agent state?
Pause the sandbox to snapshot its state, then fork it into as many branches as you want. Each fork carries the full memory and working state of the parent, so you can run parallel rollouts and keep the winner. Pause the branches you are not using to stop paying for them.
How does pricing work, and is egress free?
Per-second billing at $0.0504 per vCPU-hour plus $0.0162 per GiB-RAM-hour. Networking is unmetered, so egress is $0. Pause a sandbox and you stop paying for compute. New accounts start with 500 free credits.
Is CreateOS Sandbox production-ready?
CreateOS Sandbox is in alpha. The architecture is real and working: per-VM guest kernel, eBPF egress, sandbox networking, fork, and self-host. Audit logging, RBAC, and SOC 2, HIPAA, GDPR, and ISO certifications are on the roadmap, not yet held, with self-host as the interim control. We do not publish latency numbers we have not measured.
Give your agents a computer of their own.
Grab 500 free credits and spin up your first sandbox, or book a design-partner call.