Claudebecause the existing options didn't fit my workflow, and while it's been a hit on GitHub, I hit a wall with my own tool.
The problem is simple: persistence. If you trigger a massive refactor that touches forty files or a long test suite, the logical move is to step away from the desk. But if you close your laptop, the process dies. Even if you tweak your sleep settings, the work only exists on the hardware in your bag. You can't just start a heavy agent task and check the results from your phone an hour later.
I noticed some users were already hacking around this by deploying HolyClaude on shared VPS setups using Tailscale for access control and separate volumes per dev. That works, but someone still has to manage the patches, backups, and disk space. I realized the real value wasn't just the software, but the infrastructure that keeps it alive 24/7.
The architecture of the hosted version #
Instead of a shared environment, I'm moving toward a model where every user gets their own dedicated Linux box. Here is the technical breakdown of the setup:
Infrastructure: Each user gets one Firecracker VM and one persistent volume running on Fly.io.Pre-installed Tooling: To avoid an afternoon ofapt-get
installs, every box comes pre-loaded with six agent CLIs (includingClaude Code, Codex, OpenCode, Gemini, Cursor, and Pi) and about 60 general dev tools.Access: Root access, SSH, and a browser-based terminal. This allows you to start a session on a desktop and pick it up exactly where you left off on a mobile device.Privacy: You use your own API key. Since I don't proxy the calls or mark up the tokens, I have zero visibility into your data.
One major architectural shift was the UI. HolyClaude originally packaged
cloudcli
, but since I don't own that codebase, adding multi-user login would have required maintaining a permanent fork. The hosted version uses a UI I wrote from scratch with SSO integrated, which is why some features land there first.## Hard lessons in infra deployment
Transitioning from an MIT-licensed project to a hosted service taught me that selling infrastructure is completely different from selling software.
First, there's no "free tier" growth hack when every user is a real VM costing ~$13/month regardless of activity. Second, the cost model is volatile. You have the fixed cost of the VM, the variable cost of model tokens, and the "hidden" cost of retries. An agent caught in an infinite loop overnight can easily burn through more money than the machine itself costs to run.
I also ran into some specific deployment gotchas with Fly.io. I tried shipping a 13.6GB image, and the flyctl
command returned an exit code 0 (success). However, 95 seconds later, the machine quietly reverted to the previous image because Fly refuses images over 8GB. The only way I found this was by digging through the machine's event list. It's a reminder that a successful API response doesn't always mean your code is actually running.
Next AWS API MCP servers can actually fail-open if their security → a guide to making money with AI, with plenty of directly applicable cases.