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 stop vCPU billing with state preserved, and pay no egress fees.
500 free credits to start. Switching from E2B, Daytona or Modal? Compare sandboxesRunning on it today: our own CI, the Claude Code plugin, Langflow, Anchor Browser and the Stripe Projects listing.
const sandbox = await client.createSandbox({
shape: "s-4vcpu-4gb",
rootfs: "devbox:1",
// Egress allowlist: the sandbox reaches PyPI and nothing else.
egress: ["pypi.org:443", "*.pythonhosted.org:443"],
// Idle 5 min → paused, disk + memory preserved.
auto_pause_after_seconds: 300,
});
await sandbox.files.upload("/tmp/script.py", "print(sum(range(10)))\n");
const out = await sandbox.runCommand("python3", ["/tmp/script.py"]);▍→stdout45exit_code0
Faster than the sandboxes you're comparing.
ComputeSDK's open benchmark, run of 23 October 2026. Time to interactive with 100 sandboxes launched at once, and DAX, a real developer workload: clone, install, typecheck.
| Sandbox | Burst TTI score | Median TTI | P95 TTI | DAX workload |
|---|---|---|---|---|
| CreateOS | 94.9 | 0.47s | 0.58s | 50.53s |
| Cloudflare | 92.0 | 0.68s | 0.95s | 149.63s |
| Vercel | 90.2 | 0.72s | 1.33s | 63.78s |
| Modal | 88.7 | 1.07s | 1.20s | Did not finish |
| Daytona | 87.4 | 1.09s | 1.47s | 74.40s |
| E2B | 84.6 | 1.44s | 1.68s | Did not finish |
Burst TTI score is higher-is-better; TTI and DAX times are lower-is-better. Rankings move between runs, so we quote the run date. See the Burst TTI leaderboard, the DAX leaderboard and the raw data.
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 kernelEvery sandbox is a Firecracker micro-VM running its own Linux kernel. There is no shared kernel to escape: each sandbox is VM-isolated, with its own guest kernel.
- Blind to everything elseCode inside one sandbox cannot see the host or any other tenant. Run untrusted or model-generated code without exposing your infrastructure.
- Contained by defaultA 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 stop vCPU billing, resume in place.
A paused sandbox is a Firecracker snapshot on disk: guest memory and device state are frozen, and vCPU billing stops while memory and disk are still billed. 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. vCPU billing stops while it is paused; memory and disk are still billed.
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.
// Snapshot and suspend. vCPU billing stops here; memory and disk are still billed.
await sandbox.pause();
await sandbox.waitUntilPaused();
sandbox.status; // "paused"
// Later: restore that exact machine, not a reboot.
await sandbox.resume();
await sandbox.waitUntilRunning();
// Or let the control plane do it on idle.
await sandbox.setAutoPause(300);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 automaticallyThe ephemeral disk syncs on its own, so a run's output is captured without manual copy steps.
- Mount your own bucketsMount your own Amazon S3, MinIO, or Cloudflare R2 as a filesystem. The data stays in storage you control.
- No egress feesMove data in and out without per-gigabyte egress charges. What you read and write is yours to move freely.
Simple per-second pricing.
Billed per second while a sandbox runs. No egress fees, no minimums, with our cost basis and margin published rather than asserted.
- Per vCPU-hour
- $0.03616363
- Per GiB-RAM-hour
- $0.01159025
- Per GB-hour, storage
- $0.0001584
- Egress, any volume
- $0
Work out what yours would cost.
Pick a shape and a monthly runtime. The rate is the one above, and the published cost basis behind it is the same one the pricing page shows.
Estimated cost
$43.87per month
Compute
720 vCPU-hours × $0.03616363
$26.04
Memory
1,440 GiB-hours × $0.01159025
$16.69
Storage
10 GB × 720 h × $0.0001584
$1.14
Egress
Unmetered, any volume
$0.00
Billed per second while running. Pause to stop paying for idle vCPU; memory and storage are still charged, with your state preserved. USD, no egress fees.
Deploy your sandbox nowGo deeper
The capabilities behind CreateOS Sandbox, each in depth.
- Networking between sandboxesPrivate overlay networks and multi-node clusters inside isolation.
- Egress you can proveKernel-enforced allowlist, no ingress, containment you can demonstrate.
- Run on your own infrastructureEnterprise only: sandboxes on your machines, platform managed by us.
- A safe computer for agentsIsolation, fork, networking, and pause mapped to how agents work.
- Reliability and failure modesWhat happens when untrusted code OOMs, loops, or tries to phone home.
- ExamplesRunnable demos: agent code-exec, fork, multi-node, self-host, and more.
Common 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?
Nothing, unless you turn on auto-pause: set auto_pause_after_seconds and it pauses after that long idle with full state preserved, then resumes in place. A paused sandbox is still charged for memory and storage, but not for vCPU.
What is preinstalled, and where does it run?
The devbox:1 image is Ubuntu 24.04 with Python 3.12 and pandas, numpy, scipy, matplotlib, pyarrow, scikit-learn, openai, anthropic and langchain preinstalled, plus Node.js 24, Bun, Go 1.26, Rust and Docker, in EU or US regions. Bake a pinned set into a template built from a Dockerfile if you need one.
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, MCP, or the REST API from any language, so an agent can provision its own compute through a tool call. There is no Python SDK yet; from Python the integration is two REST calls, create and exec.
How many sandboxes can I run at once, and is there a maximum session length?
Open sandboxes are capped by plan: 1 on Free, 5 on Beginner, 20 on Pro, 30 on Enterprise, with 10 / 50 / 200 / 300 sandboxes created per rolling 24 hours. Paused sandboxes count toward the cap; destroying one frees the slot. GET /v1/whoami returns your running, paused and other counts; ten concurrent runs need Pro. There is no maximum session length: a sandbox runs until you destroy it or pause it, or until it auto-pauses on idle if you turned that on.
What happens on timeout, and how do I clean up?
Nothing is destroyed on a timer. Auto-pause is off by default; set auto_pause_after_seconds (60 to 86,400) to snapshot full state after that long idle, with vCPU billing stopped until you resume; memory and disk are still billed. Cleanup is an explicit destroy call: for one-sandbox-per-run jobs, destroy in a finally block.
Is outbound network access open or closed by default?
Open with no rules, deny-by-default once any rule is set. Pass the allowlist at create time; rules take host, host:port, wildcard subdomains, IPs and CIDRs and are enforced in-kernel on the host, outside the VM. Inbound is closed unless you enable ingress.
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, for enterprise customers only. Our team onboards your own hardware, cloud account, or on-premise machines into the CreateOS data plane, so sandboxes and their compute stay in your environment, while we run the control plane and manage the platform. Onboarding is gated and done with us directly. If you only need data in your own bucket, bring your own S3-compatible storage (S3, R2, Tigris, or MinIO) on the managed service.
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.03616363 per vCPU-hour plus $0.01159025 per GiB-RAM-hour, and $0.0001584 per GB-hour of storage. Networking is unmetered, so egress is $0. Pause a sandbox and you stop paying for vCPU; memory and storage are still charged. New accounts start with 500 free credits.
Is CreateOS Sandbox production-ready?
Yes. CreateOS Sandbox is in production and running real workloads today. Per-VM guest kernel isolation, eBPF-enforced egress, sandbox-to-sandbox networking, and pause and fork are all live. Run it in our EU and US regions. Running sandboxes on your own infrastructure is available to enterprise customers only.
Give your agents a computer of their own.
Deploy your first sandbox with 500 free credits, or book a demo.