CreateOS Sandbox
Instant, hardware Isolated Sandboxes for AI agents
266 followers
Instant, hardware Isolated Sandboxes for AI agents
266 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
Free Options
Launch Team / Built With
Render: Get up to $100K in startup creditsThe fastest way to launch and scale your startup in the cloud
Promoted
Hey Product Hunt 👋
I'm Pratik, CTO and co-founder at CreateOS.
CreateOS Sandbox gives every AI agent its own isolated environment with its own guest kernel. Egress is enforced in-kernel via eBPF, from outside the sandbox. Code running inside cannot route around the policy, even when fully compromised.
What's in it:
eBPF egress control — allowlist by host, IP, or CIDR, enforced in kernel
Fork — snapshot a running sandbox, clone it in milliseconds
Encrypted p2p mesh networking, plus VPN back to your local machine
BYO-S3 — mount any S3 service as a shared disk across sandboxes
CLI integration — `stripe projects add createos/project` provisions a project with credentials already in your .env
BYO-Infra — run sandboxes on your own hardware
We shipped 51 real-world examples: Claude-managed agents, multi-node clusters, batch inference, ffmpeg transcoding, and more.
We also shipped a Sandbox plugin for Claude this week. Claude can run untrusted code in a box that self-destructs when idle.
Get started:
CLI: `createos sandbox create`
Dashboard: https://createos.sh/app/sandbox
Quickstart: https://nodeops.network/createos/docs/Sandbox/Quickstart
500 free alpha credits, no card.
One thing I'd like feedback on: which of your production egress rules would this sandbox break? That tells us more than a star rating.
Links:
Docs: https://nodeops.network/createos/docs
Dashboard: https://createos.sh/app/sandbox
CLI: https://github.com/nodeOps-app/c...
SDK: https://github.com/NodeOps-app/c...
SDK examples: https://github.com/NodeOps-app/c...
Claude plugin: https://github.com/NodeOps-app/c...
Sandbox as self-hosted GitHub Actions: https://github.com/NodeOps-app/c...
The in-kernel eBPF egress enforced from outside the sandbox is what makes this actually trustworthy to me — most sandboxes run policy in a userspace proxy that compromised code can just route around. Since eBPF sees packets at L3/L4, how does the host allowlist resolve names: is DNS resolved outside the box and the resulting IPs pinned to the rule, or can a compromised process inside do its own resolution and point an allowlisted hostname at an attacker-controlled IP? And on Fork, does the clone inherit the parent egress policy the instant it snapshots, or is there a window before the eBPF rules attach to the new sandbox?
@hi_i_am_mimo Good catch, worth being precise here. The egress allowlist itself isn't eBPF, it's a hybrid of kernel iptables (IP/CIDR/port rules, per-VM chain, DROP-by-default) and a transparent proxy that reads SNI or Host header for domain rules on ports 80/443. eBPF in our stack does a different job: cross-tenant VM-to-VM isolation on the WireGuard mesh, and optionally bandwidth metering. Both run outside the guest, so the "compromised code can't route around it" property still holds. The enforcement layer just isn't eBPF for this specific path. Appreciate you pushing on the exact mechanism instead of letting the buzzword slide.
On DNS: resolution happens inside the guest, against resolvers we auto-allow (1.1.1.1, 8.8.8.8) the moment a domain rule exists. The proxy doesn't do its own lookup. It intercepts the connection via `SO_ORIGINAL_DST`, so it sees whatever IP the guest's own resolution already picked, then checks the SNI or Host string against your allowlist. That asymmetry matters:
- HTTPS: safe. A compromised process can point `pypi.org` at an attacker IP, the proxy allows the connection, but the TLS handshake fails, the attacker can't present a cert for `pypi.org`. The wire-level identity check saves you, not the proxy.
- Plain HTTP: not safe. without https, sails through, no protocol-level identity check exists on HTTP. Documented gap, not a hidden one. If HTTP matters for your threat model, use IP/CIDR rules instead of domain rules, or stay HTTPS-only.
On fork: the new row copies the source sandbox's full egress list at fork time, so policy inherits by default unless you pass an explicit egress override in the fork request. At resume, the host installs the iptables chain and proxy rule before the resume call waits for the guest agent to answer, and before the sandbox gets marked reachable. No window where a fork you can already reach is missing its policy. Same timing model as a cold create, not a weaker one.
That HTTP versus HTTPS split is the right way to document it. One push on the HTTPS case though: the TLS handshake only fails if the client validates the cert, and a compromised process is exactly the one that will not. It can set SNI to an allowlisted host, connect to an attacker IP, and accept a self-signed cert, and since the proxy only reads the SNI string the rule passes and no wire-level identity check ever happens. So domain rules look like protection against hijacked DNS with an honest client rather than against a malicious one. Is IP/CIDR the only real answer there today, or is cert pinning at the proxy on the roadmap?
The 30ms cold start is genuinely impressive, especially the p90 timing. One thing that would help me as a builder is a built-in state diff or snapshot viewer in the CLI. Being able to compare filesystem and env changes between two sandbox runs without having to write custom diff scripts would make iterating on agent behavior much faster. Maybe something like `sandbox diff run-123 run-124` that outputs a clean summary.
@cihanomakgzs0 Good ask, love the specificity. Nothing built into the CLI for that today — closest workaround is pulling files via the file API before/after and diffing yourself, which is exactly the friction you're describing. `sandbox diff run-123 run-124` is a clean shape for it. Noting this one, thanks for the concrete syntax idea.
@cihanomakgzs0 Interesting suggestion. The SDK exposes snapshot and fork primitives, so you could script a diff workflow yourself, pause two sandboxes, compare their filesystems, discard. But a built-in sandbox diff CLI command that surfaces filesystem and env changes between two runs cleanly is not something we have today. That is a thoughtful feature request.
30ms p90 for hardware-isolated spin-up is a serious number — most sandbox stacks I've tried are an order of magnitude slower, and it changes what you can do per-task vs per-session. Curious about the lifecycle model: when an agent needs state to persist across runs (a working directory it comes back to tomorrow), do you snapshot/restore, or is the intended pattern ephemeral-always with external storage? Building long-running agents, that's the decision that shapes everything downstream.
@nitish_garg4 Both patterns work and we designed for both. The SDK gives you pause and resume primitives — you can snapshot a sandbox to durable storage and restore it later with its full filesystem state. That is the path for agents that need a working directory to persist across runs.
That said, the intended default is ephemeral. The recommendation is to treat state as external (S3 disks, databases, object storage) and use sandboxes as stateless compute. This keeps the lifecycle simple: spin up, do work, destroy. If your agent needs a persistent workspace across sessions, pause/resume handles it without external storage.
the 30ms p90 spin-up claim is what stands out to me here, and also what I'd want to poke at first. a full guest kernel per sandbox usually means real VM boot overhead, so is the speed coming from keeping a pool of pre-booted kernels warm and just attaching workloads to them, or is there something about the fork/snapshot approach that makes cold starts basically free? and if it's the snapshot route, does a forked sandbox inherit the parent's eBPF egress rules automatically or do you have to reapply the policy each time?
@omri_ben_shoham1 Great question. The speed comes from two things working together. First, the control plane keeps a warm pool of micro-VMs with their kernels already booted, so creating a sandbox is basically attaching a workload to a ready kernel rather than booting one from scratch. Second, fork takes this further, when you fork a running sandbox, you are cloning an already-warm VM with its state intact, not booting a new one. That means forked sandboxes are even faster than the initial create.
Yes, a forked sandbox inherits the parent's eBPF egress rules automatically. The entire egress policy is part of the sandbox configuration that gets cloned on fork. You do not need to reapply anything.
Been using CreateOS Sandbox, some of the things that stood out to me
1. Seamless integration with my existing managed agents to have an isolated execution environment
2. I can run these sandboxes on my own Cloud, existing compute layer
3. The examples repository is really good with variety of use-cases -> https://github.com/NodeOps-app/createos-sandbox-sdk/tree/main/examples
Great work by Pratik & team.
@naman_nodeops Thanks for the detailed writeup. Glad the BYOC story and the managed-agent integration path are landing the way we hoped, that's the gap we built this to close. Appreciate the shoutout on the examples repo too. The team put real effort into covering varied use-cases there, beyond a single hello-world. Thanks for using it and writing this up.
Been on the infra side of this build, and it's honestly wild how much our CI pipelines sped up once we moved ephemeral test runners over to these sandboxes. The self hosted GitHub Actions integration saved us a decent chunk on runner costs, and not having to hand write egress rules anymore because eBPF handles it at the kernel level has been a relief for our on call rotation. Curious to see how the BYO infra option holds up once more teams start running their own hardware behind it, that was one of the more requested features from folks on our side
@ashw6q It’s a different approach that we went with utilizing sandboxes with github actions, and it turned out to be a game changer, especially for ops. glad that you like it