firecracker microvms · one go binary · apache‑2.0
docker run for code you don't trust.AI-generated, user-submitted, or just unvetted: crucible runs it in a hardware-isolated microVM that boots in milliseconds, snapshots warm state, and forks it ~100ms at a time. On your own hardware.
$ curl -fsSL https://github.com/gnana997/crucible/releases/latest/download/install.sh | sudo bash -s -- --with-deps --enable
Agents write code. Users upload code. Dependencies ship code nobody read. Something has to run it.
Containers share your kernel. Hosted sandboxes meter your tokens and hold your data.
crucible gives every workload its own virtual machine, on hardware you already own.
isolation
Each sandbox is a real virtual machine with its own kernel, not a namespace sharing yours.
Every workload gets its own Firecracker microVM behind a jailer: separate kernel, private network namespace, default-drop firewall. Root inside a sandbox is still outside your host.
Capture a warm sandbox and fork copies in ~100ms with lazy userfaultfd memory. Guest RAM is served on demand, never byte-copied per fork.
crucible run nginx:alpine -p 8080:80 boots the OCI image you already have. cp pushes files in, shell opens a live session, --rm cleans up.
One command gives Claude Code, Cursor, or any MCP agent 15 sandbox tools, with operator guardrails the agent can't widen.
Durable per-sandbox logs that outlive the VM, a live terminal dashboard (TUI), and Prometheus metrics. Untrusted code, observed.
Hashed API keys with per-token policy: allowed operations, egress allowlists, resource caps, timeout ceilings. Introspectable at /whoami.
snapshot → fork
Install dependencies, warm the cache, load the model, then snapshot. Every fork wakes from that exact state in ~100ms with lazy memory, fresh entropy, and its own network identity.
It's the primitive agent workloads actually want: try eight approaches in parallel, keep the one that passes.
$ crucible snapshot create $SBX |
xargs crucible fork --count 8one api
The CLI, SDKs, MCP server, and TUI are thin clients over the same REST contract: spec-generated, drift-checked, documented byte by byte.
# boot, run, snapshot, fork: from your shell crucible run python:3.12 -- python -c 'print(6*7)' crucible cp ./repo sbx_9f2ac1:/work crucible shell sbx_9f2ac1 crucible snapshot create sbx_9f2ac1 | xargs crucible fork --count 8
trade-offs
Honest trade-offs: crucible is infrastructure, not magic.
| crucible | hosted sandboxes | docker run | |
|---|---|---|---|
| isolation | Hardware VM (Firecracker) | VM, in their cloud | Shared host kernel |
| code runs on | Your hardware | Vendor infrastructure | Your hardware |
| cost | Free, Apache-2.0 | Metered per second | Free |
| snapshot → fork | First-class, ~100ms | Varies by vendor | Not a primitive |
| agent-native (MCP) | Built into the binary | Via integrations | No |
| your data leaves | Never | Every request | Never |
| you bring | A Linux box with KVM | A credit card | Trust in the code |
quickstart
The installer provisions everything (Firecracker, jailer, the guest kernel) and starts the daemon under systemd.
$ curl -fsSL …/install.sh |
sudo bash -s -- --with-deps --enable$ crucible run python:3.12 --
python -c 'print(6*7)'$ crucible shell sbx_9f2ac1A hosted crucible is on the roadmap. Leave an email and you'll hear about it exactly once.
No spam. One email when the hosted version exists.