CreateOS Sandbox
Instant, hardware Isolated Sandboxes for AI agents
264 followers
Instant, hardware Isolated Sandboxes for AI agents
264 followers
CreateOS Sandbox gives AI agent builders their own fast, secure, hardware isolated, sandbox in ~30ms (p90). We have suit of CLI, SDK, 50+ SDK real world examples, claude plugins, computeSDK integration, and more
Terminal Candy
i run coding agents most of the day and the thing that always makes me nervous is what they can touch. hardware isolation with egress enforced inside the sandbox feels like the right way round. does the 30ms spin up hold once you're pulling real dependencies in, or is that a bare box number?
CreateOS Sandbox
@terminal_candy That is a bare box number. Once you start pulling in dependencies (pip install, npm install, downloading model weights), the total time is dominated by the dependency install, not the VM boot. The 30ms is about how fast you get a shell. What happens inside that shell after creation depends on your workload, same as any VM.
The fork feature becomes relevant here. If you set up a sandbox with all your dependencies once and fork it for each task, you pay the install cost once and every fork inherits the prepared environment.
CreateOS Sandbox
As AI agents become more autonomous, we kept running into the same problem: how do you let them execute arbitrary code without putting the rest of your infrastructure at risk? We built CreateOS Sandbox to answer that. Every agent gets its own isolated environment with a dedicated guest kernel, and network access is enforced externally through eBPF, so the policy still holds even if the code inside the sandbox is fully compromised.
Beyond isolation, we focused on making it practical for real workloads. You can fork running sandboxes in milliseconds, mount your own S3-compatible storage across environments, connect securely through encrypted networking, or even run everything on your own infrastructure if that's what your deployment requires.
CreateOS
@rahilmavani What's actually true: the egress allowlist runs on iptables (kernel, per-VM chain, IP/CIDR/port) plus a transparent proxy reading SNI/Host for domain rules on 80/443 — docs/egress.md. eBPF exists in the stack, but it enforces cross-tenant VM-to-VM isolation on the WireGuard mesh and optional bandwidth metering, a separate subsystem. The "enforced outside the sandbox, holds even if the guest is fully compromised" property is still true. The mechanism named in comment 1 isn't. Your call whether that's worth a follow-up correction on the thread; flagging it since it's a public technical claim under your name.
A native MCP server for the sandbox so agents can spin up isolated environments on the fly without bolting on extra glue code. Would make the CLI and SDK even more plug and play for Claude and other MCP clients.
CreateOS Sandbox
@eminejyic We shipped one. It is in the repo under the MCP examples. You can point any MCP client (Claude Desktop, Claude Code, any MCP host) at it and let agents spin up sandboxes on the fly without glue code.
The example at examples/09-mcp-claude-code shows exactly how it works.
CreateOS
On the product side, the whole bet here was refusing the usual tradeoff.
Every sandbox tool makes you pick: fast provisioning or real isolation. We wanted both ~30ms to spin up, and a real guest kernel per agent with egress locked down in-kernel via eBPF, enforced from outside so a compromised agent can't route around it.
If your infra can't move at the speed your agents think, the agents aren't fast, they're just waiting. That's the problem we set out to kill.
500 free sign-up credits, no card. Genuinely want to hear what breaks against your workloads.
CreateOS
@sid_625 Real bar here: infra that makes agents wait defeats point of having agents. 30ms + eBPF egress was the fun problem, prewarmed snapshots, cgroup tuning, per-VM egress enforced from outside guest kernel so compromised agent can't route around it, only through it. Credits live, no card. Send us workload that breaks it, fastest way we get better.
Congrats on your product and the launch. This sounds interesting. But how does it compare to Docker or Firecracker?
CreateOS
@jn263 Firecracker's not a competitor, it's the engine underneath. CreateOS Sandbox runs on Firecracker microVMs, then adds the control plane around it: scheduling across hosts, an HTTP API, pause/resume with snapshot, per-sandbox networking and egress rules, SSH tunnels, disk mounts. Raw Firecracker gives you the VM primitive. We give you the fleet management layer teams actually need to run agent workloads at scale.
Docker's the real comparison point. Docker containers share the host kernel, isolation runs on namespaces and cgroups. A kernel exploit in one container can reach others on the same host. Each CreateOS sandbox gets its own kernel via KVM hardware virtualization, so the isolation boundary sits at the hypervisor, not the kernel. Boot still lands in the milliseconds, close enough to container speed that most workloads don't feel the difference, but you get VM-grade isolation for untrusted or agent-generated code.Here, what I can see is that the features on top are real enablers, like:
Bring your own S3
Sandbox
Mesh VPN
Editor support
Egress control
Asynchronous file sync
Synchronous file sync
etc.
@pratikbin Thanks for the explanation. So it's advantages of the VM and speed of a container. Sounds very promising.
The 30ms cold start is genuinely impressive for hardware isolation, basically unheard of in that category. Loving that you threw in the Claude plugins and SDK examples right out of the gate too, makes it way less of a chore to actually try it.
CreateOS
@kuzeyvv1l Wanted trying it to be zero-ceremony, not "read docs for an hour first." Glad that came through. Let us know what you build next — always want the second thing you try, not just the first.
CreateOS Sandbox
@kuzeyvv1l Appreciate that. The point of shipping 51 examples was exactly that — we did not want anyone to have to dig through docs to try it. Clone the repo, pick one, run it.
The 30ms cold start is genuinely impressive for hardware isolated sandboxes. Whoever tuned that cold boot path clearly obsessed over it.
CreateOS
@tunahancangelir Correctly clocked. Prewarmed snapshots + a dedicated boot lane so new-VM spawns don't queue behind everything else — took a while to get the tail latency down, not just the median. Good to hear it holds up outside our own benchmarks.
CreateOS Sandbox
@tunahancangelir Credit to the platform team. The hot-path optimization was deliberate, we knew the category competes on speed numbers, and we wanted to remove that objection before building on top of it.