HolyClaude: a containerized Claude Code workstation with a browser UI

The setup work HolyClaude is trying to delete

Getting Claude Code running in a browser on a Linux box is not one install. It is a chain of installs that each fail in their own way. Chromium will not start when Docker's shared memory defaults to 64MB. Xvfb has to be running before a headless browser can draw anything. The UID inside the container has to line up with the host user or every file the agent writes comes back permission denied. The README lists these as the problems the image was built to absorb, and the compose file shows the fixes: shm_size is set to 2g, and the container runs as a user whose home directory is bind-mounted from ./data/claude.

The target user is a solo developer or a small team that wants an always-on Claude Code environment reachable from a browser tab, with Playwright and a pile of command line tools already on PATH. The README frames the pitch as time saved on configuration rather than any new capability. That is an honest framing. HolyClaude does not add anything to Claude Code; it pre-assembles the surroundings.

What the image actually contains and how the pieces connect

The image is built from a Dockerfile with two variants. The default is full; passing --build-arg VARIANT=slim produces a smaller build. The build stages are visible in the Dockerfile: a Go stage compiles several pinned esbuild versions, and a separate stage builds an FFmpeg security backport from patches under security/patches/ffmpeg/. The runtime layer is Node 26.8.2 on Debian bookworm-slim.

The runtime story is a container running s6-overlay as PID 1, which supervises the services inside. The repository has an s6-overlay/ directory for this. The CloudCLI web UI listens on port 3001 and is the entry point; the compose file maps it to 127.0.0.1:3001 on the host, so a fresh install is reachable only from the machine it runs on. Claude Code itself is the real CLI, not a wrapper or a proxy. The README states that authentication happens through the web UI, either by OAuth against a Max or Pro plan or by pasting an Anthropic API key, and that the tools read credentials from container files, bind mounts or environment variables and then talk to the provider directly.

State lives in two bind mounts. ./data/claude maps to /home/claude/.claude, which holds Claude Code's own configuration and credentials. ./workspace maps to /workspace, which is where the agent works. Everything else in the container is disposable, which is the main operational advantage of the design.

Installing HolyClaude and reaching the web UI

The README's quick start is five steps and needs no .env file. Create a directory, drop in the provided compose template, start the stack, then open the browser.

mkdir holyclaude && cd holyclaude
docker compose up -d

After the pull finishes, the container starts in the background. The README says to open http://localhost:3001, where you create a CloudCLI account and then sign in with your Anthropic account. The compose file pins that port to the loopback interface only:

ports:
  - "127.0.0.1:3001:3001"     # CloudCLI web UI, localhost only

If you want to change the host port or move the bind mounts, .env.example exposes three variables that docker-compose.full.yaml reads: HOLYCLAUDE_HOST_PORT, HOLYCLAUDE_HOST_CLAUDE_DIR and HOLYCLAUDE_HOST_WORKSPACE_DIR. The quick template hardcodes the paths instead.

The compose file also sets shm_size: 2g, which is the setting that keeps Chromium from crashing, and passes TZ=UTC as an environment variable so you can set your own timezone. The first real use after login is opening the web UI's terminal or agent panel and pointing it at a project under /workspace.

The capabilities the compose file asks for

This is the part worth reading twice. The quick start compose file adds SYS_ADMIN and SYS_PTRACE capabilities and sets seccomp=unconfined. The comments in the file are explicit that this is the current browser profile for the release and that hardening is a separate concern. Running Chromium and Playwright inside a container generally does require loosening the default seccomp profile, so this is not gratuitous, but it does mean the container has more reach into the host kernel than a typical application container.

The README's own guidance reinforces the same boundary from the other side: if you want to reach the UI from outside your network, it says not to port-forward it and points to a remote access section. The default binding to 127.0.0.1 is deliberate. Anyone who changes that line to 0.0.0.0:3001 without putting an authenticating reverse proxy in front is exposing a shell that can run arbitrary commands as the container user.

There is a security/ directory and a security/patches/ tree in the repository, and the release notes mention patched nested dependencies and downstream backports. That is a sign the maintainer is tracking advisories, but it does not change what the container is permitted to do. Treat the capability set as a design decision you are accepting, not a detail to skim.

Where HolyClaude is the wrong tool

If your threat model requires a container that drops capabilities and runs under the default seccomp profile, this image does not fit. The compose file is the opposite of that posture by design. You could rewrite it, but then you are maintaining the browser sandbox configuration that the project exists to maintain for you, and the value proposition shrinks to a Dockerfile you would still have to patch.

Multi-tenant use is a second mismatch. The image is built around a single home directory and a single workspace mount, with credentials living in files under /home/claude/.claude. Sharing one container between several people means sharing those credentials and that filesystem. The README describes a personal workstation, and the architecture matches that description.

The third case is anyone already committed to a different agent CLI. HolyClaude bundles eight AI CLIs, but the workstation is organized around Claude Code and CloudCLI. If your workflow runs through another agent, you are carrying a large image for a tool you will not open. The README's alternatives section exists precisely because the project knows it is one option among several.

How it differs from running Claude Code directly

The obvious alternative is installing Claude Code on the host and skipping containers entirely. That gives you the same CLI, the same subscription, and no capability changes. What you give up is isolation and reproducibility: the agent runs with your user's full access to your home directory, and the Playwright and Chromium setup becomes your problem again, on every machine you work from. The README's own alternative is a hosted AI workstation, holycode.cloud, which trades the self-hosted container for someone else's always-on Linux box. That removes the Docker and capability decisions from your plate, and it also removes your control over where the credentials and workspace live.

A third approach is a plain Debian or Ubuntu container you configure yourself. That is the most flexible path and the most expensive in time, which is the exact cost the README opens by naming: two hours of manual setup. HolyClaude's bet is that a maintained Dockerfile plus a compose template is worth more to you than the freedom to assemble the stack your own way. Whether that bet pays off depends on how much you value the pinned versions and the pre-wired browser over the ability to choose every layer.

Upgrades, the MIT licence, and what the repository tracks

HolyClaude is MIT licensed, which is permissive and imposes few obligations beyond keeping the copyright notice. The image bundles a long list of third-party software, and the repository carries a THIRD-PARTY-NOTICES file for those components. If you redistribute the image or build a product on top of it, that file is the one to read, along with the licences of the individual CLIs inside. None of this is legal advice; it is a pointer to where the answers live.

Upgrades are the operational cost. The project pins aggressively. The v1.5.7 notes explain that npm stays at 11.19.0 because npm 12 rejects CloudCLI's verified shrinkwrap, and that TypeScript stays at 6.0.3 because the 7.0.2 native binary carries fixed-version Go findings. Those are deliberate holds, not neglect, and they mean a naive bump of a single dependency can break the build in ways the maintainer already discovered. The repository also has a contracts/product-facts.json file that the release workflow checks against the Dockerfile and compose files before building, which is a reasonable guard against documentation drifting from the image.

The last push to the default branch was on 2026-08-12, the same day as the v1.5.7 release, so the project is current. Upgrading means pulling a new tag and restarting; the README has an upgrading section, and the release notes mention restored rollback evidence in the workflow. What the README does not document is a supported rollback procedure for your own deployment, so pin a specific tag rather than tracking latest if you care about being able to return to a known state.

Editorial conclusion

HolyClaude is for developers who want Claude Code in a browser without assembling Node, Playwright, Chromium and a dozen CLIs by hand, and who are willing to run a container with SYS_ADMIN and an unconfined seccomp profile on a machine they control. It is a poor fit for anyone who needs a hardened container, a multi-tenant host, or a workflow built around a different agent CLI. Before adopting it, read the security/ directory and the compose file's cap_add and security_opt blocks, confirm the bind mounts under ./data/claude and ./workspace point where you expect, and check the image tag you are pulling against the version you intend to run.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes