bhatti v2: a self-owned VMM (krucible), and a rethink of what bhatti is

[sahil-shubham]

bhatti has always been about one thing: running lots of sandboxes cheaply — real VMs you can create in seconds, pause for free, and wake in microseconds, so the only real limit is how many are active at once. That's what makes it a good home for AI coding agents.

We started on Firecracker because it was the most battle-tested microVM around, and keeping the engine swappable was an early goal (the very first prototype actually ran on Docker before we moved to real VMs). Firecracker got us a long way — the v1 line (currently v1.11.12) is stable, documented, and stays available.

What's changing

Going forward, bhatti runs on its own VMM: a fork of libkrun we maintain as libkrucible. Internally this is "v2 / krucible," and it's now what main tracks.

Why own the VMM

• Portability. libkrun runs on macOS (Apple Silicon) via HVF as well as Linux/KVM. That drastically lowers the friction to try bhatti — create a real VM on your laptop, no Linux box required. (v2 macOS binaries are Developer-ID signed + notarized, so they just run.)
• Flexibility. Owning the VMM lets us revisit decisions the Firecracker design fixed in place — networking (moving to in-VMM TSI, no host iptables/bridges), the snapshot/fork primitives, the isolation model — and build things we couldn't bolt onto FC.

What this means practically

• v1 (Firecracker) stays on the firecracker branch, frozen at v1.11.12. It isn't going anywhere; it's just not where new work happens, and we're not splitting energy maintaining two engines.
• v2 (krucible) is main, and pre-release today. Moving from v1 is a deliberate cutover (different VMM; snapshots don't port), not an in-place bump.
• Already working: the engine on Linux and macOS/HVF, warm/cold thermal tiers, snapshot/fork, a lean guest kernel, and a signed + notarized multi-platform release pipeline.

Where I'd love your input

• If you run bhatti today, what would make the v2 cutover worth it for you?
• The networking rethink (host-owned TSI/egress vs the old per-user bridges + L2 tricks) is the biggest behavioral change — does anything you rely on depend on the old model?
• What did the Firecracker design make hard that you wish were a first-class primitive?

This is a genuine change in what bhatti is built on — and some of the principles that come with it. I'll keep this thread updated as v2 firms up.

— Sahil

[MeenachiSundaram]

I was looking for an alternative to slicervm.com
And found bhatti and also I found another one called smolvm

but Bhatti seems more interesting and more like slicerVM with client-server concept.

And while looking into the code I got a question our testing to understand, What’s the reason behind krucible — your own fork of libkrun, libkrucible — as the VM engine. Instead of using the libkrun.

I see creating a fork of libkrun adds additional overhead to maintain the fork.