🏖️ 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 install.microsandbox.dev | 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
api.github.com → the only host that gets the real key
send the placeholder anywhere else and the request is blocked.
walk through it yourself in a minute:
github.com/superradcompany/m…
what should we explain next?
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.
12 people helped ship these releases, including 5 first-time contributors. thank you for building microsandbox with us 💜
full release notes:
docs.microsandbox.dev/change…
docs.microsandbox.dev/change…
microsandbox retweeted
.@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.
introducing msb in 90s, a new series.
episode 1: pause and resume
pause a running computer.
resume it right where it left off.
walk through it yourself in a minute:
github.com/superradcompany/m…
that's episode 1 of msb in 90s.
what should we explain next?
microsandbox retweeted
if you want this too but don't have lovable-level time and money, @microsandbox is the open-source alternative that gives you this and more.
O_DIRECT is shipped for disk and memory is next.
you can now snapshot and branch a running computer.
memory snapshots are live in microsandbox, on macos, linux and windows.
a full snapshot captures the whole sandbox: disk, memory, every running process.
snapshots take ~30ms (~40ms at 4 GiB) after the first one. branching into a new running sandbox takes ~100ms.
so you can:
- set up an environment once, reuse it already warm
- branch one moment and try different approaches
- snapshot before a risky change, come back anytime
available now in v0.7.4 (arm64 and x86-64). cloud support coming soon.
docs.microsandbox.dev/sandbo…








