1/5 people ask, why did you choose to build a microvm runtime first (microsandbox)?
because we build for the future in mind. the pre-existing tech like firecracker, CH, etc are significantly so limiting for the things we see agents want to do both for cloud and local.
you can now return custom HTTP denial messages to your agent or harness when a network or secret policy blocks a request in a microsandbox. 🛡️
tell it what to do next, or disable responses to close the connection without an explanation.
🏖️ How to run your own local sandboxes (give this to your agent):
A spare Linux box can run your coding agent's sandboxes with each one getting its own microVM and private env vars
Mine's running on a Framework, completely replaced Vercel Sandbox for my demos
- @microsandbox runs each sandbox as a VM with its own kernel instead of a container
- the VM gets a placeholder key; the proxy swaps in the real one only on calls to that host and keys expire with the sandbox
- a firewall keeps it off the host's own services, my home network and tailnet; only the public internet
- each one gets 2 CPUs and 4 GB, up to 10 run at once and stops after idle for 30 minutes
prompt in reply
one line install:
curl -fsSL https://t.co/uUwfLtnyGF | sh
any API key your agent can read is one prompt injection away from leaking.
in microsandbox, the key never enters the guest. instead the agent gets a placeholder, and the real key gets swapped in on the way out.
here's what that looks like ↓
the --secret flag:
msb create python --secret [email protected]
GITHUB_TOKEN → read from your env, never stored
https://t.co/MjEf7rwICa → the only host that gets the real key
send the placeholder anywhere else and the request is blocked.
12 people helped ship these releases, including 5 first-time contributors. thank you for building microsandbox with us 💜
full release notes:
https://t.co/S1hlYF4azW
https://t.co/rIL2HIJKUn
microsandbox v0.7.7 + v0.7.8 are out!
⚙️ run commands in the background (jobs)
🔑 choose which headers receive secrets
🌐 use HTTP CONNECT proxies
🧹 inspect and clean up local storage
plus control over clock syncing when restoring snapshots, and more. 🧵
where did the disk space go?
msb df shows local storage usage. msb prune --dry-run previews unused runtime memory files you can remove, without touching saved snapshots or disks.
.@microsandbox now 5th on DAX bench.
we've been investing a lot into performance of our runtime over the past couple months, and it shows. some of those changes got rolled out to the cloud only recently (still private beta).
trailing on TTI bench, with lots of improvements in our backlog. expect to see more of those wins as we roll out more exciting features and improvements.
msb pause freezes a whole microsandbox in ~10 ms: every process, its memory, its progress.
paused, a sandbox that was maxing out a core drops to >1%.
msb resume brings it back in ~10-25 ms and the job carries on from the exact step it stopped at.