On this page
- The Blast Radius Problem: Per-VM Kernel vs Shared Kernel
- Egress You Can Prove, Enforced Where the Code Cannot Reach It
- Networking: The Part Almost Nobody Else Does
- Standing up a Cluster, Inside Isolation
- Self-Host, for the Buyers Who Cannot Send Code Elsewhere
- What Ships Today, and the Current Limits
- Two Ways In
Agents write code now. They write it, and then they run it. Nobody reviewed it first.
That is the new normal, and most sandboxes were not built for it. They were built to run a snippet. A function. A single cell of a notebook. One process, one box, no neighbors, no network it can reach on purpose. That model holds right up until the code your agent generated wants to talk to another service, stand up a worker, or behave like the small distributed system it actually is.
CreateOS Sandbox starts from a different premise. The unit of isolation is the sandbox. And a sandbox is a real computer, with its own kernel, that can be networked to other sandboxes under rules you can prove. This post is about why that combination matters, and what it lets you build.
One deployment note up front. Teams with strict sovereignty requirements can self-host the control plane and storage so code, snapshots, and data stay inside their own boundary. Evaluate the deployment against your organization's required controls and certifications before using it for regulated workloads.
The blast radius problem: per-VM kernel vs shared kernel
Most container-based sandboxes share one host kernel across every tenant. The container is a namespace and a cgroup. It is a software boundary drawn inside a kernel that all the other code on that host is also using. When the boundary is a software promise, a kernel bug is a shared fate. One escape reaches the host, and the host is the neighborhood.
CreateOS Sandbox runs each sandbox as a Firecracker micro-VM with its own guest kernel. Not a shared kernel with namespaces drawn on top. A separate kernel, behind a hardware virtualization boundary. The blast radius of code inside a sandbox is that sandbox.
This is not a novel claim in the category. E2B runs Firecracker. Declaw runs micro-VMs with guardrails. Isolation by itself is table stakes now, and saying otherwise would be dishonest. The interesting question is no longer "is it isolated." It is "what can it do while it stays isolated." That is where the rest of this matters.
Egress you can prove, enforced where the code cannot reach it
Isolation stops code from escaping the box. It does not, by itself, stop code from phoning home. Untrusted code that can reach the open internet is a data-exfiltration path wearing a sandbox costume.
CreateOS Sandbox governs egress with an allowlist, enforced with eBPF at the host, outside the VM.
The model is deliberately blunt. An empty allowlist allows all, which is the convenient default for a throwaway. The moment you add your first rule, everything else is locked down. Allow-all becomes deny-by-default with one entry. There is no ingress unless you explicitly turn it on. Each sandbox also carries a bandwidth quota, accounted in the kernel and rechargeable when a workload needs more.
The part that earns the word "prove" is where the enforcement sits. The rules live on the host side, in eBPF, on the other side of the VM boundary. Code inside the sandbox cannot see them, edit them, or route around them. A compromised process that gains root inside its own guest kernel still cannot rewrite a rule that does not exist inside its kernel.
import { CreateosSandboxClient } from "@nodeops-createos/sandbox";
// reads CREATEOS_SANDBOX_API_KEY + CREATEOS_SANDBOX_BASE_URL
const client = new CreateosSandboxClient();
// lock this sandbox to a single API endpoint, nothing else, and no ingress
const sandbox = await client.createSandbox({
shape: "s-1vcpu-1gb",
rootfs: "devbox:1",
egress: ["api.internal.example.com:443"],
ingress_enabled: false,
});
Contrast this with a proxy-based egress filter, which is where some younger entrants in the category sit today. A proxy controls traffic that politely goes through the proxy. Enforcement at the host controls traffic whether the code cooperates or not. The honest difference is "filtered if it complies" versus "filtered regardless." For untrusted code, regardless is the only version that counts.
Networking: the part almost nobody else does
Here is the limitation that defines "snippets, not systems." Most sandbox platforms give you an isolated box and stop. There is no supported way for one sandbox to talk to another. E2B, as strong as it is on adoption, does not offer inter-sandbox networking. Neither does Declaw. Daytona has no multi-node networking story either.
So if your agent's workload is actually three services that need to find each other, you are stuck stuffing them into one box or wiring something brittle yourself.
CreateOS Sandbox gives sandboxes a real network. Private overlay networks span hosts, and between networks the default is deny. Within a network, each sandbox gets its own address on the overlay, and the others reach it there while nothing off the network can reach in. The part you work with is simple: create a network, put sandboxes on it, look up a peer's address, and talk to it.
// one private overlay network, two sandboxes joined to it
const net = await client.networks.create({ name: "team-eval" });
const api = await client.createSandbox({
shape: "s-1vcpu-1gb",
rootfs: "devbox:1",
networks: [{ id: net.id }],
});
const worker = await client.createSandbox({
shape: "s-1vcpu-1gb",
rootfs: "devbox:1",
networks: [{ id: net.id }],
});
// look up the worker's address on the overlay, then reach it from `api`
const { members } = await client.networks.get(net.id);
const workerIp = members?.find((m) => m.sandbox_id === worker.id)?.ip;
await api.runCommand("curl", [`http://${workerIp}:8080/health`]);
This is the wedge. Not isolation alone, which is table stakes. Not networking alone. The combination: per-VM kernel isolation by default, real networking between sandboxes, kernel-level egress governance, and self-host. No competitor matches the full set today.
Standing up a cluster, inside isolation
Once sandboxes share a private overlay network, they stop being boxes and start being nodes. You can stand up a multi-node k3s or Nomad cluster across several sandboxes, each one its own micro-VM with its own kernel, all on a default-deny private network, all under an eBPF egress allowlist.
That is a genuinely different shape of thing. It is a real distributed system that an agent can spin up, exercise, and tear down, with the isolation boundary drawn around the whole cluster and between every node in it. You get to test the system, not a snippet that pretends to be one.
A few honest constraints so this lands as engineering and not a pitch. Shapes are fixed at create: s-1vcpu-256mb, s-1vcpu-1gb, s-2vcpu-2gb, s-4vcpu-4gb, with a disk size you set up front. There is no live resize, so size the node for the job at create time. The devbox image is Ubuntu with Node 22 LTS, Bun, Python 3.12 with uv, Go, and Rust. There is no GPU.
Self-host, for the buyers who cannot send code elsewhere
For a regulated, security-first team, the honest blocker is rarely the isolation model. It is the sentence "our security team will not let us send code to someone else's cloud."
So the answer we actually have is better for sovereignty anyway: run the control plane and the storage yourself. Storage is BYOS3, so S3, R2, Tigris, or MinIO, with FUSE mounts, live attach and detach, and local to remote sync. Self-host the control plane and point it at your own buckets, and the code, the snapshots, and the data never leave your boundary. That is real data residency, not a residency label on someone else's region.
Self-hosting gives those teams a deployment path with direct control over data residency. It is not a substitute for evaluating the controls and certifications their workloads require.
What ships today, and the current limits
Candor is the differentiator in this category, so here is the line drawn straight.
Shipping today: per-VM guest kernel isolation, eBPF egress allowlist with no-ingress default and bandwidth quotas, overlay networks, the create / pause / resume / fork / destroy lifecycle, BYOS3 storage, and full self-host of control plane and storage.
Shapes are fixed at create, so size them for the workload before launch. We are not going to publish a CreateOS Sandbox cold-start number we have not measured. The category competes on published latency, and we would rather show you a multi-node cluster nobody else can stand up than quote a figure we cannot yet back. Sandboxes start in seconds via snapshot restore. When we have measured numbers, you will get them with the methodology attached.
Two ways in
If you are building an agent or a code-gen platform and you want to run untrusted code that behaves like a system, grab 500 free credits and spin up your first networked sandbox. Two boxes on one network, talking on the overlay, in a few minutes. For the isolation boundary underneath it, see Firecracker sandboxes for AI agents.
If you are a security or platform team that cannot send code to someone else's cloud, book a design-partner call. We will walk the self-host topology with you and map the available controls to your requirements.
CreateOS Sandbox is one product under the unified execution layer for AI. The premise is the same all the way down: run code you cannot trust, as systems, not snippets.
