Why recommend not mounting the CloudCLI folder & .claude.json?

[mAAdhaTTah]

I'm perhaps more interested in understanding why we should be reconfiguring the webui on every startup vs persisting that folder. As I was working on configuration, I had to reboot this a few times, and going through the onboarding flow was a little annoying. it also means I have to reboot every time I upgrade as well. Obviously, it's easy to fix, but wondering why that's suggested.

[chrisrothwell]

Firstly, great work! Holyclaude is awesome. If it's not possible to persist the Cloud CLI credentials to survive a container restart, I'd love to see a Docker environment variable that can set the default Cloud CLI username, password and git credentials. I am running Holyclaude on a docker image with Watchtower enabled so when a new docker image is published it will automatically upgrade. After upgrade the container restarts and anyone accessing the link can set a new username/password and access my environment. This means I can't expose the container to the public internet via reverse proxy in case someone hijacks it after a restart. Would love to know your thoughts on this.

[CoderLuii]

@mAAdhaTTah @chrisrothwell

Good question. The .claude.json part is outdated now. Current HolyClaude releases already persist that, so you should not be going through Claude onboarding on every restart anymore.

The part that still does not persist is ~/.cloudcli, and that's intentional for now because CloudCLI stores its account data in SQLite, and SQLite on SMB/CIFS/NAS mounts is a headache.

That said, the security concern here is real: if you expose HolyClaude publicly and the container restarts without persisted CloudCLI state, whoever reaches it first can create the web UI account and take over the instance.

So yes, docs need to be corrected, and yes, the current CloudCLI persistence story is still weak for public or automatically updating deployments.

The likely fix is an optional persistence path for ~/.cloudcli on local storage only, not network mounts, plus clearer warnings in the docs until that exists.

[CoderLuii]

Quick follow up since this thread also touches on the exposure angle.

Even after I ship the optional ~/.cloudcli persistence, I would still not recommend putting HolyClaude directly on the public internet with only a CloudCLI login in front of it. A password is only as strong as the attacker's patience, and brute force plus credential stuffing attacks are constant. This container has a full shell, a headless browser, and your AI credentials behind it. That is a juicy target.

The right setup is Tailscale or a Cloudflare Tunnel so it is never directly reachable from the open internet. Then your CloudCLI login becomes the second layer, not the only layer. Treat HolyClaude like a homelab dashboard, not a public web app.

And while I'm here, if the self host tradeoffs are more pain than they are worth for your setup, I have a related project worth a look.

HolyCode is the same idea as HolyClaude but wrapped around OpenCode, so you get 30+ dev tools and 10+ providers (Anthropic, OpenAI, Gemini, Groq, Bedrock, Azure) in one container. Repo: https://github.com/coderluii/holycode

And I'm building HolyCode Cloud, the managed version. Zero setup, no Docker, no terminal, nothing to expose. Works from any device, sessions and settings follow you, always on the latest build. Waitlist: https://holycode.coderluii.dev/cloud

Going to close this out. Action items on my side are clear: docs fix, optional .cloudcli persistence, and security guidance. If any of that ships, I'll come back and drop a note with the version.

[chrisrothwell]

Thanks for the reply! I'll be checking out HolyCode.