The stack needs to be reachable locally as ai.home and externally as ai.haylan.ch — not just localhost/LAN IP:port as currently built (#4). This changes the architecture: needs a reverse proxy in front of Open WebUI (and possibly llama.cpp's endpoints for direct CLI access), TLS termination for the external hostname, and DNS/routing for both names.
Open questions to resolve with the user: is there already a reverse proxy / ingress (Traefik, nginx, Caddy, Cloudflare Tunnel, etc.) running on this network that other self-hosted services (e.g. git.arthurerlich.de) go through, which this stack should register with — or does this stack need its own? Where does ai.home resolve (router/Pi-hole entry, /etc/hosts, mDNS)? Where does ai.haylan.ch's DNS point, and is external exposure directly port-forwarded or tunneled? Does external (ai.haylan.ch) access change the auth/security posture beyond Open WebUI's existing login (e.g. does llama.cpp's raw API need to stay LAN-only even if Open WebUI is externally reachable)?
Part of #1
## Question
The stack needs to be reachable locally as `ai.home` and externally as `ai.haylan.ch` — not just `localhost`/LAN IP:port as currently built (#4). This changes the architecture: needs a reverse proxy in front of Open WebUI (and possibly llama.cpp's endpoints for direct CLI access), TLS termination for the external hostname, and DNS/routing for both names.
Open questions to resolve with the user: is there already a reverse proxy / ingress (Traefik, nginx, Caddy, Cloudflare Tunnel, etc.) running on this network that other self-hosted services (e.g. git.arthurerlich.de) go through, which this stack should register with — or does this stack need its own? Where does ai.home resolve (router/Pi-hole entry, /etc/hosts, mDNS)? Where does ai.haylan.ch's DNS point, and is external exposure directly port-forwarded or tunneled? Does external (ai.haylan.ch) access change the auth/security posture beyond Open WebUI's existing login (e.g. does llama.cpp's raw API need to stay LAN-only even if Open WebUI is externally reachable)?
Resolved. No new reverse-proxy service needed — the existing Nginx Proxy Manager (NPM) instance on this network already fronts other self-hosted services and will handle this one too.
ai.home (LAN) and ai.haylan.ch (external, via the existing DMZ) both route through NPM to Open WebUI's published port — no code change needed, docker-compose.yml already publishes it.
llama.cpp's raw API stays LAN-only, deliberately — not registered in NPM, no auth of its own (unlike Open WebUI's login). Coding CLIs reach it via the box's LAN IP or ai.home directly, bypassing NPM (which only fronts 80/443).
Added docs/network-access.md documenting the NPM proxy-host setup, and fixed docs/coding-cli-setup.md + README.md — they previously said localhost, which is wrong for any CLI not running on the AI box itself. Committed on main (c01ef89).
Resolved. No new reverse-proxy service needed — the existing Nginx Proxy Manager (NPM) instance on this network already fronts other self-hosted services and will handle this one too.
- **ai.home** (LAN) and **ai.haylan.ch** (external, via the existing DMZ) both route through NPM to Open WebUI's published port — no code change needed, `docker-compose.yml` already publishes it.
- **llama.cpp's raw API stays LAN-only, deliberately** — not registered in NPM, no auth of its own (unlike Open WebUI's login). Coding CLIs reach it via the box's LAN IP or `ai.home` directly, bypassing NPM (which only fronts 80/443).
Added `docs/network-access.md` documenting the NPM proxy-host setup, and fixed `docs/coding-cli-setup.md` + `README.md` — they previously said `localhost`, which is wrong for any CLI not running on the AI box itself. Committed on `main` (c01ef89).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #1
Question
The stack needs to be reachable locally as
ai.homeand externally asai.haylan.ch— not justlocalhost/LAN IP:port as currently built (#4). This changes the architecture: needs a reverse proxy in front of Open WebUI (and possibly llama.cpp's endpoints for direct CLI access), TLS termination for the external hostname, and DNS/routing for both names.Open questions to resolve with the user: is there already a reverse proxy / ingress (Traefik, nginx, Caddy, Cloudflare Tunnel, etc.) running on this network that other self-hosted services (e.g. git.arthurerlich.de) go through, which this stack should register with — or does this stack need its own? Where does ai.home resolve (router/Pi-hole entry, /etc/hosts, mDNS)? Where does ai.haylan.ch's DNS point, and is external exposure directly port-forwarded or tunneled? Does external (ai.haylan.ch) access change the auth/security posture beyond Open WebUI's existing login (e.g. does llama.cpp's raw API need to stay LAN-only even if Open WebUI is externally reachable)?
Resolved. No new reverse-proxy service needed — the existing Nginx Proxy Manager (NPM) instance on this network already fronts other self-hosted services and will handle this one too.
docker-compose.ymlalready publishes it.ai.homedirectly, bypassing NPM (which only fronts 80/443).Added
docs/network-access.mddocumenting the NPM proxy-host setup, and fixeddocs/coding-cli-setup.md+README.md— they previously saidlocalhost, which is wrong for any CLI not running on the AI box itself. Committed onmain(c01ef89).