Launching today
CreateOS Sandbox
Instant, hardware Isolated Sandboxes for AI agents
205 followers
Instant, hardware Isolated Sandboxes for AI agents
205 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
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 built-in cost dashboard would be super helpful, especially showing compute time per sandbox session and monthly burn. With cold starts at 30ms there's a real risk of accidentally spinning up thousands of sandboxes during testing, and right now there's no easy way to see what's running or set spend alerts.
CreateOS
@yarenaralp Fair, and honestly a real risk we think about too — 30ms cold starts make it trivially easy to fire off way more sandboxes than you meant to. Today you can list running sandboxes and check `/bandwidth` per sandbox, but there's no aggregated spend view or alerting yet. Logging this as a real gap, not just a nice-to-have.
The ~30ms cold start is genuinely impressive, especially for agent loops where latency compounds. One thing that would save me a lot of time: a local dev mode that spins up a fake sandbox emulator so I can iterate on agent logic and exception handling without burning real compute credits during testing.
CreateOS
@feyzaqk5q Real pain point, makes sense especially for exception-path iteration where you don't want real infra in the loop. 500 free credits take some of the sting out short-term, but a proper local emulator is a different, better answer. Adding it to the list.
The 30ms cold start actually held up in my testing, which is wild for hardware isolated sandboxes. The claude plugin integration made spinning up agents feel almost frictionless.
CreateOS
@azadxpsa That was the point of shipping the plugin day one — agent loops shouldn't need a side quest just to get a sandbox. Glad it landed that way for you.
The 30ms cold start actually held up when I spun up a few sandboxes back to back, no weird warm-up lag. Loved having the SDK examples handy instead of digging through docs.
CreateOS
@sultanrdm6 That's deliberate — every shape's pre-warmed so there's no "first one's slow" tax. Glad the SDK examples were there instead of you spelunking through docs mid-test.
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.