Launching today
CreateOS Sandbox
Instant, hardware Isolated Sandboxes for AI agents
186 followers
Instant, hardware Isolated Sandboxes for AI agents
186 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
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?
CreateOS
@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?
CreateOS
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.
CreateOS
@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.
CreateOS Sandbox
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
CreateOS
@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
30ms startup is great, but for agent workloads I'd also want a teardown receipt: which egress rules fired, what credentials were present, and whether the writable layer was actually destroyed. Is that available per sandbox today?
CreateOS
@new_user___2672025cf1bc18102609b53 Good question, and honestly the answer is "partially" today. Every destroy emits an audit event (`sandbox.destroy`, with cause user/admin/TTL/drain) and egress rules are logged when configured (`sandbox.egress.set`, allowlist only, no raw secrets). Credentials never round-trip through logs, disk creds are ECDH+ChaCha20-encrypted at rest and SSH keys are audited by fingerprint only, never raw.
If we want the application layer to take care of the forensics part, else you can always visit audit logs
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.
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.