Two hosts, three subnets, one edge.

01 Two physical hosts.

Everything runs on two machines:

echo is the compute box — it has the GPU for vLLM/llama.cpp + the moshi voice pipeline, the agent SDKs, and the live-reloading frontend. Unraid is the everything-else box: it holds the storage array, runs the long-lived infrastructure services, and is where the reverse proxy + auth stack live. Postgres lives on Unraid so that even if echo reboots, the database (which both echo and BawtHub depend on) stays up.

02 Three Docker networks (per host).

There's no overlay network connecting the two hosts. Docker bridges on each host stay local; cross-host traffic goes over the LAN by IP.

The two compose projects on echo (bawthub and llm-bawt) deliberately stay on separate bridge networks. They communicate through host.docker.internal:8642 instead of a shared network — every compose service includes extra_hosts: host.docker.internal:host-gateway for exactly this purpose. The benefit is that either stack can be torn down and recreated without affecting the other.

03 Edge topology.

04 Hostnames and what they route to.

The naming model has two flavors. Internal LAN hostnames live under *.lan.ferreri.us and *.lan.zenoran.com and resolve only inside the LAN via AdGuard Home rewrites. Public hostnames live at the bare domains and resolve to 204.210.248.216 via Porkbun.

05 Echo: the compute box.

echo runs two compose projects (bawthub and llm-bawt) plus a few standalone containers. The currently-running set:

06 Bridges as agent sidecars.

The three bridge containers (openclaw-bridge, claude-code-bridge, codex-bridge) all share one Docker image — llm-bawt-bridge from Dockerfile.bridge — and are started with different module entrypoints. The image runs Python 3.12-slim, non-root user bridge, and bind-mounts the host's ~/dev directory at /home/bridge/dev.

That bind mount is the key design choice. Both Claude Code and Codex are agent harnesses — they need filesystem access to read and edit code. The bridges are the workspace: when one of those bots executes Edit or Bash, it's writing to the same files your editor on the host sees. The host's ~/.ssh is also mounted read-only so the agents can clone from GitHub and SSH between hosts. The bridges themselves talk to Redis at redis:6379 over the llm-bawt_default bridge network.

Each agent's auth credentials are bind-mounted from the host config dir:

• Claude Code: ~/.config/claude-code-bridge/.claude.json + ~/.config/claude-code-bridge/ for settings, skills, and SOUL.md.
• Codex: ~/.codex/auth.json (RW so the binary can self-refresh OAuth tokens — codex login on the host self-heals the bridge with no docker restart).
• OpenClaw: gateway URL + token in .env.

Health checks expose /health on ports 8680 (OpenClaw), 8681 (Claude Code), 8682 (Codex). All three depend on Redis being healthy and the main app being started.

07 Unraid: the always-on services.

Unraid runs ~30 containers, but only a handful matter for BawtHub:

08 Authelia gating.

NPM is configured per-host with an auth_request directive that calls Authelia's /authz/auth-request endpoint. If the request has a valid session cookie (matching one of Authelia's configured users), Authelia returns 200 + identity headers (Remote-User, Remote-Email, Remote-Groups); if not, it returns 401 and NPM redirects to https://auth.bawthub.com for login.

The auth-portal proxy host (NPM proxy_host #39, auth.bawthub.com) is special — it must not apply server_proxy[.]conf to itself or it'd loop. It's also added to $oauth2_bypass in http_top.conf. The unraid-ops skill captures this as a recurring footgun.

Identity headers from Authelia are forwarded as X-Forwarded-User / X-Forwarded-Email / X-Auth-Request-User / X-Auth-Request-Email / Remote-User / Remote-Email. BawtHub's frontend reads X-Forwarded-Email as the canonical user identity for its entityId column.

09 The public site.

This very page is served by a separate, intentionally minimal container — bawthub-public-site, plain nginx:alpine on Unraid br0.2 at 10.0.2.36. NPM routes the bare apex (bawthub.com and www.bawthub.com) here with no Authelia gate, because the marketing/architecture pages are deliberately public.

The deployment story for this site is dead simple: edit HTML, copy to /mnt/user/appdata/bawthub-public-site/, done. There is no build step, no framework, no JS framework dependency tree. Just static HTML, one shared site.css, one shared site.js, and the Inter web font.

10 The dev loop.

BawtHub's frontend is live-reloaded — that's the deploy. The frontend container bind-mounts ./frontend from disk and runs next dev --webpack. Editing a .ts/.tsx/.css file triggers webpack HMR; users see the change without a container restart.

llm-bawt's main app similarly mounts src/ in dev mode (the FastAPI worker reloads on Python file changes), though changes to that container's dependencies require a rebuild. The bridges, since they're share an image, get rebuilt with make rebuild-bridge when the Dockerfile.bridge changes — but the bind-mounted ~/dev + the live-mounted Python sources mean most changes don't need an image build.

11 DNS recap.

• Public records at Porkbun. app.bawthub.com, auth.bawthub.com, bawthub.com, www.bawthub.com, echo.ferreri.us, echo.zenoran.com, and a long tail of *.ferreri.us service subdomains all point at 204.210.248.216.
• LAN records via AdGuard rewrite rules: *.lan.ferreri.us and *.lan.zenoran.com resolve to LAN IPs internally only. AdGuard is the DHCP-advertised DNS server, so every device on the LAN sees these names.
• TLS certificates via Let's Encrypt DNS-01 challenge through Porkbun's API. NPM manages renewal; the npm-17 cert covers bawthub.com + Subject Alternative Names for all the subdomains.

12 Key files + locations.