sahil-shubham

Hey, creator of bhatti here, let me know if you any questions.

Author here. Reposting because the first attempt didn't land.

Spent the last few months trying every snapshottable-sandbox product on the market to run my own coding agents. sprites.dev came closest but was unstable enough that I'd wake up to broken sessions. Halfway into building my own, I realised the market is ~ten companies racing to be the managed-Firecracker layer, and a Hetzner auction box is $40/mo. If you're willing to run the orchestrator yourself, you don't need any of them.

I now run my own agents on it, plus the rest of my engineering workflow. It's been the harness-engineering substrate I wanted, and owning the runtime means I own everything I build on top of it too.

Repo: https://github.com/sahil-shubham/bhatti

Nice work on the website!

Building something for the same problem but more so from the perspective of self-hostable stateful sandboxes, and not just the filesystem (see https://bhatti.sh). What sandbox solution are you using here?

I did a "Show HN" post regarding bhatti here - https://news.ycombinator.com/item?id=47996509

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.

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.

Love the website and how you have implemented payments! Also giving each box an email is a nice touch.

Thank you for sharing!

No worries! I too have been using machines/sandboxes/VMs/microVMs very interchangeably these days. Former is understood by a broader group, but latter is more precise. Trying to find a balance.

Thank you for the feedback! I appreciate it, looking forward to you trying it out and logging any issues.

I am aware of the documentation, it’s what I have been focusing on before I can post on HN. I want to make it a delight to read for other people!

As for the design decisions, I have tried keeping all the plans I made in the repo too. I wouldn’t have been able to make bhatti in a month without LLMs.

Thank you :)

Not sure what you mean. I use the above linked personal project, bhatti, which internally uses Firecracker microVMs.

The point about VMs being the wrong shape because they’re tied to CPU/memory resonates hard. The abstraction forces you to pay for time, not work.

I ended up buying a cheap auctioned Hetzner server and using my self-hostable Firecracker orchestrator on top of it (https://github.com/sahil-shubham/bhatti, https://bhatti.sh) specifically because I wanted the thing he’s describing — buy some hardware, carve it into as many VMs as I want, and not think about provisioning or their lifecycle. Idle VMs snapshot to disk and free all RAM automatically. The hardware is mine, the VMs are disposable, and idle costs nothing.

The thing that, although obvious, surprised me most is that once you have memory-state snapshots, everything becomes resumable. I make a browser sandbox, get Chromium to a logged-in state, snapshot it, and resume copies of that session on demand. My agents work inside sandboxes, I run docker compose in them for preview environments, and when nothing’s active the server is basically idle. One $100/month box does all of it.

Yes! Checkout the bhatti volume

They are ext4 blocks which exist independent of sandboxes.

Nice work on Shuru — I remember looking at it when I was researching this space. You went with a Rust wrapper on Apple’s Virtualization framework right?

I have been working on something similar but on top of firecracker, called it bhatti (https://github.com/sahil-shubham/bhatti).

I believe anyone with a spare linux box should be able to carve it into isolated programmable machines, without having to worry about provisioning them or their lifecycle.

The documentation’s still early but I have been using it for orchestrating parallel work (with deploy previews), offloading browser automation for my agents etc. An auction bought heztner server is serving me quite well :)

I've been building an open-source, self-hostable Firecracker orchestrator for the past month: https://github.com/sahil-shubham/bhatti (https://bhatti.sh)

Still WIP, but the core works — three rootfs tiers (minimal Ubuntu, headless Chromium with CDP, Docker-in-VM), OCI image support (pull any Docker image), automatic thermal management (idle VMs pause then snapshot to disk, wake transparently on next API call), per-user bridge networking with L2 isolation, named checkpoints, persistent volumes, and preview URLs with auto-wake.

Fair warning: the website is too technical and the docs are mostly AI-generated, both being actively reworked. But I've been running it daily on a Hetzner server for my AI agents' browser automation, and deploy previews.

I'd love any feedback if you want to go ahead and try it yourself