DEV Community: CoderLuii

i started holyclaude back in march. 2.4k stars later i'm building the hosted version of it

CoderLuii — Thu, 13 Aug 2026 14:24:17 +0000

i started holyclaude in march. a web ui for running claude on your own machine, built because i wanted one and the options at the time didn't fit how i worked. it's mit. i pushed it, used it every day, and mostly forgot it was public.

it's now at 2,478 stars and 257 forks. between it and my other project, holycode, there's roughly 132k docker pulls. people install it daily without me doing anything at all, which is still the strangest part of this whole thing.

this is what i've been building since, and why.

the thing my own tool couldn't fix

holyclaude runs on the machine it's installed on. that's the entire design and for a long time it was fine.

then i started leaving agents on longer tasks. builds, test suites, a refactor that touches forty files, anything that sits waiting on an api. and every one of those is a stretch of time where the sensible thing is to walk away from the computer.

so i'd start something, close the laptop, and come back to nothing. changing the sleep settings fixes the sleeping. it doesn't fix the work only ever existing on the machine in my bag.

people were already solving it by hand

there's a discussion open on the repo right now from a team running holyclaude on a shared vps. one container per developer, separate volumes, a shared git remote, access control handled entirely by tailscale.

that works. i want to be clear about that, because it's the honest answer for a lot of people and it costs nothing.

it's also a server somebody has to keep alive. patched, backed up, disk not full, certificates not expired, and awake at 3am when it stops answering. that maintenance is what i ended up building a product around, not the software.

what the hosted version actually is

a linux box that stays yours and stays on.

one firecracker vm and one persistent volume per person, running on fly. six agent clis already installed, claude code, codex, opencode, gemini, cursor and pi, plus around 60 dev tools so the box is useful the second it boots rather than after an afternoon of apt. root, ssh, and a browser terminal, so you can start something on a desktop and pick it up on a phone with the session still running.

your own api key. i don't proxy calls and i don't mark up tokens, which also means i never see what you're doing.

one detail that shaped the architecture more than anything else: holyclaude doesn't own its web ui. it ships cloudcli, which i package rather than wrote. so a feature like multi user login, which needs an auth layer inside the ui, means forking someone else's project and maintaining that fork forever. the hosted version runs a ui i wrote, with sso already in front of every box. that's why some things land there first. it's a dependency question rather than a commercial one, and i'd rather say that plainly than let people assume the free version is being starved.

what running it has taught me so far

selling infrastructure is not selling software. every user is a real vm that costs me about $13 a month whether they log in or not, so there is no free tier to grow into. that deletes half the standard playbook before you start.

the cost model has three lines, not two. the box is fixed. the model spend is variable. and retries are variable with no ceiling at all, which somebody pointed out in the comments of my last article and which i'd left out entirely. an agent stuck retrying the same failure overnight can outspend the machine it's running on without ever looking like it's failing.

fly refuses images over about 8gb, which i discovered by shipping a 13.6gb one. the deploy reported success, flyctl exited 0, and 95 seconds later the machine had quietly reverted to the previous image. the only trace was one line in the machine's own event list. exit code 0 means the api accepted your request, not that your machine is running your code.

and free stars don't convert. 132k pulls is flattering and it is not a funnel. the overlap between people who will install an mit project and people who will pay monthly for a hosted one is far smaller than a star count makes it feel.

what's honest about the state of it

sessions survive you disconnecting and survive me redeploying the box. they do not survive a hard restart, where you get a fresh shell. that one isn't solved.

every box sits behind an sso gate, so a stranger hitting a port gets a 401 rather than your terminal. proper cross tenant network isolation is on the list rather than done.

the 2gb entry tier will oom under a real build with a test suite next to it. 4gb is the first size that stopped annoying me.

and underneath all of it, it is a vps with the setup already done. if you enjoy running your own server, you genuinely don't need me.

the free one, forever: https://github.com/CoderLuii/HolyClaude
the hosted one, 3 days free: https://app.holycode.cloud/billing?code=TRY3DAYS

if you've taken a popular free project and put a paid version next to it, i'd like to know how you handled the line between them. that's the part i'm least sure i'm getting right.

priced out what running agents 24/7 actually costs & wrote it up the machine is the cheapest thing in the whole setup. everyone optimises the small fixed number & lets the big variable one run full diy walkthrough included, you don't need to buy anything

CoderLuii — Tue, 11 Aug 2026 17:37:34 +0000

CoderLuii

Aug 11

how to run coding agents 24/7 for about $19 a month...

#ai #programming #tutorial #productivity

4 min read

how to run coding agents 24/7 for about $19 a month...

CoderLuii — Tue, 11 Aug 2026 17:34:10 +0000

the consensus is that running agents around the clock is expensive, so people don't. they give an agent a task, sit and watch it, and close the laptop when they're done.

i think that's backwards. the machine is the cheapest thing in this entire setup & almost nobody prices it out.

the number people get wrong

a small linux box, running constantly, is somewhere between $5 and $25 a month depending on where you put it & how much ram you give it. that's the whole cost of the compute.

now go look at what you spent on tokens last week.

for most people running agents on real work, the model bill is the larger number by a wide margin & it isn't close. one long session can cost more than the machine costs for the month.

so the thing people optimise is the fixed, small, predictable number. and the variable, large, unpredictable one just runs.

why it feels expensive when it isn't

because "always on" sounds like "always billing" & on most providers it is. you rent a box, it runs whether you're using it or not, and you pay for every idle hour at the same rate as every working hour.

that's the part worth fixing, and it's a solved problem. a machine that suspends when nothing is happening & resumes when you come back costs you for the working hours and pennies for the rest.

mine resumes in about a second. that number matters more than it sounds, because a resume that takes thirty seconds is one you start avoiding, and a setup you avoid isn't a setup.

the diy version, in full

you do not need to buy anything to do this. here's the whole thing.

1) get a vps. any provider. what you want is a real vm with a disk that persists across reboots, and no idle reaper. what you do NOT want is a container platform that reclaims your box when nobody types for twenty minutes, because that's exactly what an unattended agent looks like from the outside.

2) ram is your constraint, not cpu. agents spend most of their wall clock waiting on api calls. but a headless browser or a test suite will take 2gb without asking.

3) run the agent under tmux:

sudo apt install tmux
tmux new -s agent

start your agent here

ctrl-b then d to detach

now close your laptop. tmux attach -t agent when you're back, and the scrollback is still there including everything it printed while you were gone.
this is the part people skip & it's the part that matters. if the agent is a child of your ssh session, a dropped connection is a kill signal. under tmux it isn't.

4) preinstall what it's going to reach for. postgres, playwright with its system deps actually resolved, ffmpeg, pandoc, ripgrep. half a bad agent session is the agent discovering the machine is empty & installing its way out, on your tokens.

5) keys in the environment, never in the prompt. a key pasted into a prompt ends up in the scrollback, in whatever the agent writes to disk, and in the session transcript on disk. put it in .bashrc & let the cli read it.

one gotcha that cost me a day: playwright caches browsers under $HOME. if you mount a volume over $HOME, the build passes, the browser is genuinely there at build time, and every chromium.launch() fails for the user. set PLAYWRIGHT_BROWSERS_PATH=/opt/ms-playwright before you install.

what the diy version actually costs

not money. time.

you now own a server. patching, backups, the security of the thing, and the afternoon you spend on playwright's system dependencies before you write a line of your own code. that afternoon is the real price & nobody quotes it.

i ran it that way for a long time and it was fine. i stopped because i was spending maintenance time on infrastructure that had nothing to do with what i was building.

what i ended up building

HolyCode Cloud is that setup, on a machine i maintain instead of you.

$19/mo gets 1 vcpu, 2gb ram and 12gb disk. that's enough for one agent doing real work. the ladder goes to $199 for 8 vcpu and 16gb, and every feature is on every tier — you're paying for horsepower, not to unlock things.

six agent clis are already on PATH: claude code, codex, gemini, opencode, cursor, pi. so is postgres, playwright with its deps resolved, ffmpeg, pandoc, gh, ripgrep, tmux. the disk persists. the process survives you disconnecting.

you bring your own anthropic or openai key & they bill you directly. i don't mark up tokens and i don't want to be in that business. the machine costs what the machine costs.

it suspends when you're not using it & wakes in about a second, so always-on isn't always-billing.

the honest edges

leave a box idle for several days and the wake is closer to a minute than a second, while the host pulls the image again. nothing is lost, you just wait.

a hard crash gives you a fresh shell. files and the volume survive.

scrollback doesn't. i can restart the machine in seconds and still can't hand you back what was on the screen.

there's no free tier. every account is a real vm that costs me money from the first minute, so instead there's a 7-day refund: no form, no call, you email me.

and everything in the diy section above works without me. if you enjoy owning the box, own the box.

holycode.cloud

the thing i'd actually like to know: for those of you running agents on real work, what's your split? machine cost against model cost, roughly. i suspect most people have never put the two numbers next to each other.

HolyCode: OpenCode in Docker with 30+ Tools, Persistent State, and No API Key Required

CoderLuii — Tue, 31 Mar 2026 08:25:01 +0000

You get your dev environment exactly right. Then you switch machines. Or rebuild a container. Or your system decides today is the day it dies.

Suddenly you're reinstalling tools. Hunting down config files. Re-entering API keys. Wondering why ripgrep isn't on PATH anymore. Figuring out why Chromium won't launch. Then Xvfb isn't configured. Then the UID inside the container doesn't match your host and everything is permission denied.

I built HolyCode after solving every single one of those problems.

What HolyCode Is

HolyCode wraps OpenCode, an AI coding agent with a built-in web UI, in a Docker container with everything already wired up. 30+ dev tools, two language runtimes, a headless browser stack, process supervision via s6-overlay, and support for 10+ AI providers. Pull the image, run one compose command, open your browser. That's the whole setup.

Quick Start

Step 1. Create a docker-compose.yaml:

services:
  holycode:
    image: coderluii/holycode:latest
    container_name: holycode
    restart: unless-stopped
    shm_size: 2g
    ports:
      - "4096:4096"
    volumes:
      - ./data/opencode:/home/opencode
      - ./workspace:/workspace
    environment:
      - PUID=1000
      - PGID=1000
      - ANTHROPIC_API_KEY=your-key-here

Step 2. Start it:

docker compose up -d

Step 3. Open http://localhost:4096.

You're in. OpenCode's web UI is running with all tools available.

One thing worth calling out: shm_size: 2g is required. Chromium crashes with Docker's default 64MB. This is a known Docker + Chromium issue and the image handles everything else, but you need to set this in your compose file.

What's Inside

The image ships with:

Dev tools: git, ripgrep, fd, fzf, bat, eza, lazygit, delta, gh (GitHub CLI), htop, tmux, vim, jq, curl, wget, tree, and more. Everything you would install one by one anyway.

Language runtimes: Node.js 22 (LTS) with npm, Python 3 with pip and venv support. Native npm addon compilation (build-essential, pkg-config) is included.

Browser stack: Chromium, Xvfb, and Playwright. Pre-configured and supervised. Headless browser automation works on first boot. No GPU, no display server to configure, no extra setup.

Process management: s6-overlay v3 supervises OpenCode and Xvfb. Either crashes, s6 restarts it automatically. Your container restart policy stays clean.

Persistence

All OpenCode data lives under /home/opencode inside the container. The compose file maps that to ./data/opencode on your host:

volumes:
  - ./data/opencode:/home/opencode

That one bind mount covers everything: sessions, settings, MCP configs, plugins, tool history, cache. Rebuild the container, update to a new image, or move to a different machine. Your state comes back.

This is a bind mount, not a named volume. That means you can browse the files directly, back them up, or rsync them to another machine. docker compose down -v does not touch them.

Claude Auth Plugin: Use Your Subscription Instead of an API Key

If you have Claude Max or Pro, you're already paying for Claude access. You don't need to pay for a separate API key on top of that.

Enable the Claude Auth plugin with one env var:

environment:
  - ENABLE_CLAUDE_AUTH=true

The plugin reads credentials from ./data/opencode/.claude/.credentials.json. Log in once, the credentials persist via the bind mount, and the plugin picks them up on every restart. No API key needed, no extra billing.

Toggle off by removing the env var and restarting.

Note: This may be outside what Anthropic's terms of service cover. The README calls this out. Make your own call.

oh-my-openagent: Turn OpenCode Into a Multi-Agent System

HolyCode ships with optional support for oh-my-openagent, a multi-agent orchestration plugin for OpenCode. Enable it the same way as Claude Auth:

environment:
  - ENABLE_OH_MY_OPENAGENT=true

It installs automatically on first boot and activates on restart. No manual setup.

What it does: parallel execution, specialized agents, background tasks. Instead of a single agent working through your request sequentially, oh-my-openagent coordinates multiple agents running in parallel, each focused on a specific part of the problem.

Toggle it off by removing the env var and restarting. Everything else in HolyCode stays exactly the same.

Provider Support

OpenCode is not locked to one provider. HolyCode exposes environment variables for every supported provider:

Provider	Variable
Anthropic	`ANTHROPIC_API_KEY`
OpenAI	`OPENAI_API_KEY`
Google Gemini	`GEMINI_API_KEY`
Groq	`GROQ_API_KEY`
AWS Bedrock	`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_REGION`
Azure OpenAI	`AZURE_OPENAI_ENDPOINT`, `AZURE_OPENAI_API_KEY`, `AZURE_OPENAI_API_VERSION`
GitHub Models	`GITHUB_TOKEN`

Set the keys for the providers you use. Ignore the rest.

HolyCode Cloud

Don't want Docker? HolyCode Cloud is coming.

Same tools. Same conversation history. Synced state across any device. Open a browser on your laptop, your tablet, anywhere, and pick up exactly where you left off. No Docker, no compose file, no terminal required.

Early access is free: https://holycode.coderluii.dev/cloud

How I Run Claude Code in Docker with a Web UI and Headless Browser

CoderLuii — Sun, 22 Mar 2026 04:42:44 +0000

You know the drill. You want Claude Code on a server. In a browser. With Playwright so it can actually interact with web pages. With every AI CLI you might need. With TypeScript, Python, database clients, the works.

So you start installing things.

Then Chromium won't launch because Docker's shared memory is 64MB. Then Xvfb isn't configured. Then the UID inside the container doesn't match your host and everything is permission denied. Then Claude Code's installer hangs silently because WORKDIR is root-owned. Then SQLite locks on your NAS mount.

Two hours later you haven't written a single line of code.

I got tired of doing this on every new server. So I built a container that handles all of it, and I ran it on my own server daily until every edge case surfaced and got fixed. That container is HolyClaude. It's free and open source, MIT license.

getting it running

Create a folder, drop in a compose file, pull, start.

mkdir holyclaude && cd holyclaude

Here's the compose file:

services:
  holyclaude:
    image: coderluii/holyclaude:latest
    container_name: holyclaude
    ports:
      - "3001:3001"
    volumes:
      - ./data/claude:/home/claude/.claude
      - ./workspace:/workspace
    environment:
      - TZ=UTC
    restart: unless-stopped
    shm_size: 2g
    cap_add:
      - SYS_ADMIN
      - SYS_PTRACE
    security_opt:
      - seccomp=unconfined

docker compose up -d

Open http://localhost:3001. Create a CloudCLI account (takes about 10 seconds), then sign in with your Anthropic credentials. You're in Claude Code, in your browser, with a headless browser ready to go.

That shm_size: 2g line is important. Chromium crashes without it because Docker allocates 64MB of shared memory by default. This is the number one issue people hit and the error messages don't point you anywhere useful.

how authentication works

HolyClaude runs the real Claude Code CLI from Anthropic. Not a wrapper, not a proxy. Your existing account works directly.

If you're on the Max or Pro plan, sign in through CloudCLI. It's the same OAuth flow as desktop Claude Code. Your subscription works as-is. If you prefer API keys, paste your Anthropic API key in the web UI. Pay-per-use, same billing.

Your credentials live in ./data/claude/ on your host. The container doesn't intercept or proxy anything.

the headless browser situation

This is the part that takes the most work to get right in Docker. Here's what HolyClaude handles for you:

Chromium needs more than 64MB of shared memory. It needs a virtual display, so Xvfb has to be configured at :99 and start before Chromium. It needs specific sandbox flags for running in a container. Playwright needs to find the system Chromium instead of trying to download its own copy.

When you ask Claude to take a screenshot, run Playwright tests, fill out a form, or scrape a site, it works. Because all of this is already configured.

process management

The container runs multiple services: Xvfb, the web UI server, file watchers. A shell script loop won't handle restarts cleanly or guarantee startup order.

I'm using s6-overlay. It gives proper dependency ordering (Xvfb starts before anything that needs a display), auto-restart on crash, and clean shutdown when you run docker compose down. It's what Linuxserver.io uses in their images, and for good reason.

image variants

The full image is about 4GB because it bundles Chromium, Playwright, and a full dev toolchain. If you don't need the browser stuff, the slim tag is about 2GB.

docker pull coderluii/holyclaude:latest
docker pull coderluii/holyclaude:slim

Both are multi-arch. AMD64 and ARM64. Works on Linux, macOS with Docker Desktop, Windows with WSL2, and Synology/QNAP NAS.

what I actually use it for

Long-running Claude Code sessions on my home server. I close my laptop and come back the next day. Session is still there.

Browser automation. I ask Claude to screenshot a URL, run tests, interact with a page. Chromium is ready. I don't configure anything.

Multi-model comparison. Claude, Gemini, and Codex are all in the same environment. Useful when I want to see how each handles a task on the same codebase.

Everything persists in ./data/. Files, auth, configs, state. Upgrade the container and nothing changes.

things it doesn't do

No built-in HTTPS. Put it behind Caddy, Traefik, or nginx if you're exposing it outside localhost. No multi-user access control. CloudCLI is a third-party web UI, not the official Anthropic desktop app.

troubleshooting the common stuff

If Chromium crashes, check shm_size: 2g in your compose file. If file changes aren't detected on a NAS mount, add CHOKIDAR_USEPOLLING=true.

if you try it and hit something, open an issue on GitHub. free and open source, MIT license.

GitHub: https://github.com/CoderLuii/HolyClaude
Docker Hub: https://hub.docker.com/r/coderluii/holyclaude
Website: https://holyclaude.coderluii.dev

DEV Community: CoderLuii

i started holyclaude back in march. 2.4k stars later i'm building the hosted version of it

the thing my own tool couldn't fix

people were already solving it by hand

what the hosted version actually is

what running it has taught me so far

what's honest about the state of it

priced out what running agents 24/7 actually costs & wrote it up the machine is the cheapest thing in the whole setup. everyone optimises the small fixed number & lets the big variable one run full diy walkthrough included, you don't need to buy anything

how to run coding agents 24/7 for about $19 a month...

how to run coding agents 24/7 for about $19 a month...

the number people get wrong

why it feels expensive when it isn't

the diy version, in full

start your agent here

ctrl-b then d to detach

what the diy version actually costs

what i ended up building

the honest edges

HolyCode: OpenCode in Docker with 30+ Tools, Persistent State, and No API Key Required

What HolyCode Is

Quick Start

What's Inside

Persistence

Claude Auth Plugin: Use Your Subscription Instead of an API Key

oh-my-openagent: Turn OpenCode Into a Multi-Agent System

Provider Support

HolyCode Cloud

Links

How I Run Claude Code in Docker with a Web UI and Headless Browser

getting it running

how authentication works

the headless browser situation

process management

image variants

what I actually use it for

things it doesn't do

troubleshooting the common stuff