圣Claude AI工作站

Stop configuring. Start building.

One command. Full AI development workstation. Claude Code, web UI, headless browser, 8 AI CLIs, 50+ dev tools — containerized and ready.

You were going to spend 2 hours setting this up manually. Or you could just docker compose up.

Works with your existing Claude Code subscription. Max/Pro plan, API key — whatever you have, it just works.

[!TIP] Stop maintaining. Start building. A hosted AI workstation. Always-on Linux box. holycode.cloud

---

:whale: Docker Compose — Quick

The "I just want it running" template. Copy this entire block into a docker-compose.yaml file:

```yaml

Just run: docker compose up -d

:whale2: Docker Compose — Full

Same image, every knob exposed. Copy this entire block into a docker-compose.yaml file:

```yaml

:building_construction: Architecture

What survives `docker compose down && docker compose up`:

• File-based Anthropic authentication and Claude Code API-key settings
• Claude Code settings, memory (CLAUDE.md), and OAuth session (no re-login)
• All your code in ./workspace
• Git global configuration, aliases, and XDG Git settings
• GitHub CLI configuration and authentication
• Codex, Gemini, and Cursor file-based config and authentication stored below /home/claude/.claude (since v1.1.7). Environment-provided keys remain in your Compose or host environment.

Re-triggering first-boot setup:

```bash

:zap: Quick Start

1. Create a folder for HolyClaude:

mkdir holyclaude && cd holyclaude

2. Create a docker-compose.yaml file. Copy one of the templates below: - Quick template — minimal, zero config, just works - Full template — all options, fully documented

3. Pull and start:

docker compose up -d

4. Open the web UI:

http://localhost:3001

5. Create a CloudCLI account (takes 10 seconds), sign in with your Anthropic account, and you're live.

No .env files. No pre-configuration. No reading 40 pages of docs before you can start. It just runs.

Want to reach it from outside your network? Don't port-forward it. See Remote Access & Exposure — use Tailscale or Cloudflare Tunnel instead.

<p align="right"> <a href="#top">↑ back to top</a> </p>

---

HolyClaude — Quick Start

HolyClaude — Full Configuration

All options documented inline.

Detailed docs: https://github.com/CoderLuii/HolyClaude/blob/master/docs/configuration.md

:wrench: Environment Variables

The complete reference. Every variable, what it defaults to, what it does.

<p align="right"> <a href="#top">↑ back to top</a> </p>

---

Persisting the CloudCLI account (optional, local storage only)

By default, the CloudCLI account database (~/.cloudcli) is container-local and gets wiped on rebuild. Re-creating the account takes 10 seconds, so most people leave it as-is.

CloudCLI is a single-user service. Remote access shares the same CloudCLI account, /workspace, and mounted credential context; it does not create separate users or tenant isolation.

If you want it to survive rebuilds, add a named Docker volume to your compose file:

services:
  holyclaude:
    volumes:
      - ./data/claude:/home/claude/.claude
      - ./workspace:/workspace
      - cloudcli-data:/home/claude/.cloudcli   # add this line

volumes:
  cloudcli-data:                                # and this block

HolyClaude prepares this directory before CloudCLI starts. Fresh Docker volumes inherit the image's claude:claude ownership. Existing volumes are repaired to the configured PUID/PGID during normal root-starting Docker startup. If the mount is read-only or cannot be repaired, startup stops with the exact path and UID/GID instead of letting CloudCLI repeat unable to open database file.

For rootless Podman, use docker-compose.podman-rootless.yaml. Its keep-id mapping and :Z labels let the existing host user write the mounted state without a privileged ownership repair. :Z handles SELinux labeling; :U rewrites host ownership and is not the default.

Do NOT bind-mount ./data/cloudcli on a network share (NAS, SMB/CIFS, NFS). CloudCLI stores its account in SQLite, and SQLite's file locking breaks on network mounts. You'll hit database is locked errors constantly. Named volumes live on the Docker engine's local filesystem, which is why this works — bind mounts pointing at a NAS will not.

A bind mount to a local SSD path is fine too, just keep it off any network share.

<p align="right"> <a href="#top">↑ back to top</a> </p>

---

Optional SSH and Mosh

HolyClaude also ships sshd and Mosh for people who want a direct terminal from a phone, laptop, NAS, or VPN connection. It is off by default. Nothing listens on port 22 unless you enable it.

This is a remote shell into the same container that holds your /workspace and Claude state. Treat it like SSH to your dev box:

• key-only login as claude
• no password auth
• no root login
• no authorized_keys under .claude or /workspace
• no public internet port forwarding

Safe setup shape:

services:
  holyclaude:
    ports:
      - "127.0.0.1:2222:22"
      - "127.0.0.1:60000-60010:60000-60010/udp"
    volumes:
      - ./data/ssh/authorized_keys:/run/holyclaude-ssh/authorized_keys:ro
      - holyclaude-ssh:/var/lib/holyclaude-ssh
    environment:
      - HOLYCLAUDE_SSH_ENABLE=true
      - HOLYCLAUDE_MOSH_ENABLE=true

volumes:
  holyclaude-ssh:

Prepare the public key file on the host:

mkdir -p data/ssh
cp ~/.ssh/id_ed25519.pub data/ssh/authorized_keys

Connect over SSH:

ssh -p 2222 claude@127.0.0.1

Connect over Mosh when UDP is reachable:

mosh --ssh="ssh -p 2222" -p 60000:60010 claude@127.0.0.1

Bind those ports to localhost, a VPN interface, or a firewall-restricted address. If you change 127.0.0.1 to 0.0.0.0, you are taking responsibility for that exposure.

:robot: AI CLI Providers

The full image ships eight AI CLIs. The slim image ships the five core CLIs.

Claude Code is the primary CLI. The others are there because sometimes you want a second opinion, or a specific model's strengths, or you're comparing outputs. Having all of them one Tab away is the whole point.

OpenCode is the full-image path for OpenRouter and multi-provider model routing. Configure it inside opencode; free model availability depends on OpenRouter and provider account limits, not HolyClaude.

<p align="right"> <a href="#top">↑ back to top</a> </p>

---

:package: Image Variants

Two flavors. Same quality. Pick your weight class.

```bash

Full image only (additional packages)

The full image includes everything above, plus:

<details> <summary><strong>Additional AI CLIs</strong></summary>

</details>

<details> <summary><strong>Additional npm packages — deployment, ORMs, performance</strong></summary>

</details>

<details> <summary><strong>Additional Python packages — PDFs, data viz, web frameworks</strong></summary>

</details>

<details> <summary><strong>Additional system packages — media, documents</strong></summary>

</details>

Slim users: Missing a package? Ask Claude. It installs npm/pip packages in seconds. System packages (pandoc, ffmpeg) take 1-2 minutes. You get the same capabilities — the full image just has zero wait time.

<p align="right"> <a href="#top">↑ back to top</a> </p>

---

:construction: Troubleshooting

<details> <summary><strong>CloudCLI shows wrong default directory</strong></summary>

CloudCLI opens to /home/claude instead of /workspace.

Cause: A custom or modified CloudCLI service script did not set WORKSPACES_ROOT=/workspace before launching CloudCLI.

Fix: Already handled in HolyClaude. The s6 run script uses with-contenv, exports WORKSPACES_ROOT=/workspace, then starts CloudCLI as the claude user. </details>

<details> <summary><strong>CloudCLI says "Failed to browse filesystem"</strong></summary>

CloudCLI cannot open ~, /workspace, or a broad NAS mount such as /volume2/docker:/workspace.

Cause: HolyClaude 1.3.3 could remove CloudCLI's expandWorkspacePath helper while disabling CloudCLI's in-container self-update path.

Fix: Update to HolyClaude 1.3.4 or newer:

docker compose pull && docker compose up -d

Broad NAS mounts work, but /workspace is the CloudCLI boundary. Anything readable under that mount is visible to authenticated CloudCLI users. Use a narrower project mount when you do not want the whole NAS folder tree exposed inside CloudCLI. </details>

<details> <summary><strong>CloudCLI Web Terminal shows black squares or missing characters</strong></summary>

The Web Terminal output is hard to read. Box drawing, emoji, CJK text, or CLI banners may show as black squares or broken characters.

Cause: Older images built the CloudCLI Web Terminal plugin with string-based PTY output handling and a narrow xterm.js font stack. If a multibyte character was split between PTY chunks, or if WebGL picked a weak fallback font, terminal output could render as replacement blocks.

Fix: Update to HolyClaude 1.3.5 or newer:

docker compose pull && docker compose up -d

HolyClaude now patches the baked Web Terminal plugin before it is built. If your browser still shows black squares after updating, open browser DevTools on the CloudCLI page, run this once, then reopen the Web Terminal:

localStorage.setItem('web-terminal-disable-webgl', 'true')

<details> <summary><strong>SQLite "database is locked"</strong></summary>

Cause: SQLite databases on SMB/CIFS network mounts. CIFS doesn't support the file-level locking SQLite requires.

Fix: Don't store SQLite databases on network shares. HolyClaude keeps .cloudcli in container-local storage for exactly this reason. If you have your own SQLite databases in /workspace on a NAS, move them to a local path. </details>

<details> <summary><strong>Chromium crashes / blank pages / tab failures</strong></summary>

Cause: Usually insufficient shared memory. Docker defaults to 64MB. If the process exits immediately with SIGTRAP or exit 133, treat that as a separate browser/runtime failure instead of a shared-memory symptom.

Fix: Ensure shm_size: 2g in your compose file. For heavy browser use (many tabs, complex pages), increase to 4g. If you still get an immediate SIGTRAP, re-check the browser build path before only raising shm. </details>

<details> <summary><strong>File watchers not detecting changes (hot reload broken)</strong></summary>

Cause: SMB/CIFS network mounts don't support inotify.

Fix: Enable polling in your compose environment:

- CHOKIDAR_USEPOLLING=1
- WATCHFILES_FORCE_POLLING=true

<details> <summary><strong>Permission denied errors</strong></summary>

Cause: Container UID/GID doesn't match host file ownership.

Fix for Docker: ```bash