sahil-shubham
Joined 4 years ago
Karma
37
Submissions
18
Member since
Feb 11
Recent submissions
Comment · 3 months ago
Hey, creator of bhatti here, let me know if you any questions.
Comment · 6 months ago
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.
Comment · 6 months ago
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?
Comment · 6 months ago
I did a "Show HN" post regarding bhatti here - https://news.ycombinator.com/item?id=47996509
Comment · 6 months ago
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.
Comment · 6 months ago
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.
Comment · 6 months ago
Love the website and how you have implemented payments! Also giving each box an email is a nice touch.
Thank you for sharing!
Comment · 6 months ago
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.
Comment · 6 months ago
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.
Comment · 6 months ago
Thank you :)
Comment · 6 months ago
Not sure what you mean. I use the above linked personal project, bhatti, which internally uses Firecracker microVMs.
Comment · 6 months ago
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.