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 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.
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?
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.
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.
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.
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.
The 30ms cold start is genuinely impressive for hardware isolated sandboxes. Whoever tuned that cold boot path clearly obsessed over it.
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.
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.
Super useful for a whole host of scenarios!
Curious if you plan to give more integration options for the plug-n-play style agents? Looks like currently we just would connect / control with Telegram?
Spun up a sandbox in around 30ms like they claim, the CLI felt snappy and the SDK examples actually made sense for once.
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.
Spun up a sandbox in about 30 seconds and the hardware isolation gave me real peace of mind for running untrusted agent code. The CLI felt snappy and the SDK examples made it easy to wire into my existing flow without much fuss.
Hardware-isolated sandboxes are a strong direction for agent work. The practical question I always look for is whether the environment makes rollback, artifacts, network access, and final-state evidence obvious enough that a small team can trust the result without babysitting 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?
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.
been using this from last couple of weeks and the best thing about this is that its insanely fast, agents can spin up the sandbox in sub-milliseconds great work by team
Congrats on your product and the launch. This sounds interesting. But how does it compare to Docker or Firecracker?
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?
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.
About CreateOS Sandbox on Product Hunt
“Instant, hardware Isolated Sandboxes for AI agents”
CreateOS Sandbox launched on Product Hunt on July 21st, 2026 and earned 171 upvotes and 50 comments, placing #8 on the daily leaderboard. 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 was featured in SaaS (43.2k followers), Developer Tools (516.1k followers), Artificial Intelligence (474.1k followers) and GitHub (41.3k followers) on Product Hunt. Together, these topics include over 260.3k products, making this a competitive space to launch in.
Who hunted CreateOS Sandbox?
CreateOS Sandbox was hunted by Pratik Balar. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how CreateOS Sandbox stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
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...