Bhatti spins up Linux VMs on any box with KVM — Pi 5, Hetzner AX, cloud VM with nested virt.
- Each VM has its own kernel, filesystem, and IP
- Idle VMs pause their CPUs and snapshot themselves to disk; the next request wakes them in 3.7ms warm or 360ms cold (p50, Hetzner AX102)
- Publish any port → public URL with auto-wake on first hit
- Pull any OCI/Docker image as a rootfs, or save a running sandbox as one
- Multi-tenant from day one — per-user bridges, encrypted secrets, rate limits
- Single Go binary, Apache 2.0
The decisions page is the most fun read on the site: vsock state
after restore, why all snapshots are Full, the systemctl shim, the
ARP retransmit trick.
curl -fsSL bhatti.sh/install | sudo bash
(sudo because the daemon needs /dev/kvm and sets up the Firecracker
jailer + a bridge; the CLI-only install — pipe to plain `bash` —
needs no root)
I have a materials engineering degree but knew halfway through that I liked computers more. Software ever since, mostly self-taught — bhatti was partly a project to teach myself low-level Linux properly.
I started by trying every snapshottable-sandbox product on the market for running my own coding agents. sprites.dev came closest but was unstable enough that I'd wake up to broken sessions. Halfway into building bhatti, I realised the market is ten companies racing to be the managed-Firecracker layer, and a Hetzner box is $100/mo — if you're willing to run the orchestrator yourself, you don't need any of them. I now run bhatti for my own agents (some need a browser, some need a full desktop, most just need plain Linux) and the rest of my engineering workflow on top.
If you try it and something breaks, please open an issue. The early adopters who did that have shaped bhatti more than any single design call I made.
On the AI question: a lot of bhatti's code came out of an LLM. The discipline I held onto was the boring kind — long planning docs before each chunk, integration tests against a real Pi cluster at home (no mocks for the VM path), atomic ship/test cycles. Every plan and every experiment is in docs/archive on the repo, both as a credibility receipt and so anyone who wants to fork can see how it was actually planned.
- Each VM has its own kernel, filesystem, and IP
- Idle VMs pause their CPUs and snapshot themselves to disk; the next request wakes them in 3.7ms warm or 360ms cold (p50, Hetzner AX102)
- Publish any port → public URL with auto-wake on first hit
- Pull any OCI/Docker image as a rootfs, or save a running sandbox as one
- Multi-tenant from day one — per-user bridges, encrypted secrets, rate limits
- Single Go binary, Apache 2.0
The decisions page is the most fun read on the site: vsock state after restore, why all snapshots are Full, the systemctl shim, the ARP retransmit trick.
curl -fsSL bhatti.sh/install | sudo bash
(sudo because the daemon needs /dev/kvm and sets up the Firecracker jailer + a bridge; the CLI-only install — pipe to plain `bash` — needs no root)
Site: https://bhatti.sh
Repo: https://github.com/sahil-shubham/bhatti
Decisions & learnings: https://bhatti.sh/docs/under-the-hood/decisions/
A bit more context on why I built this:
I have a materials engineering degree but knew halfway through that I liked computers more. Software ever since, mostly self-taught — bhatti was partly a project to teach myself low-level Linux properly.
I started by trying every snapshottable-sandbox product on the market for running my own coding agents. sprites.dev came closest but was unstable enough that I'd wake up to broken sessions. Halfway into building bhatti, I realised the market is ten companies racing to be the managed-Firecracker layer, and a Hetzner box is $100/mo — if you're willing to run the orchestrator yourself, you don't need any of them. I now run bhatti for my own agents (some need a browser, some need a full desktop, most just need plain Linux) and the rest of my engineering workflow on top.
If you try it and something breaks, please open an issue. The early adopters who did that have shaped bhatti more than any single design call I made.
On the AI question: a lot of bhatti's code came out of an LLM. The discipline I held onto was the boring kind — long planning docs before each chunk, integration tests against a real Pi cluster at home (no mocks for the VM path), atomic ship/test cycles. Every plan and every experiment is in docs/archive on the repo, both as a credibility receipt and so anyone who wants to fork can see how it was actually planned.
Excited to see this launch, have been using bhatti for some time now!
Bhatti is easy to use, so powerful, and handy! Thank you for being so fast at fixing issues, and keeping up with bhatti’s development.