serverAppConfigs/serverAppConfigs-docs/Dankclaw/OpenWebUI.md

OpenWebUI

OpenWebUI is a self-hosted chat interface for LLMs. It connects to OpenAI-compatible endpoints (vLLM, llama.cpp, Ollama) and adds RAG, plugins, tool calling, and multi-user support.

Host: Dankclaw — Port: 3005 (host) → 8080 (container) — Vhost: ai.franksdank.cloud routes straight to 192.168.0.143:3005 (unguarded — OpenWebUI enforces its own auth) — Boot-persistent: Quadlet — Docs: https://github.com/open-webui/open-webui

Facts

Item	Value
Image	ghcr.io/open-webui/open-webui:main (verified from the live quadlet unit)
Port	3005 (host) → 8080 (container). Port 3000 is Gitea's HTTP, so it is not usable.
Data volume	/home/dank/Containers/open-webui/data → /app/backend/data
Default backend	frank-large on Dankclaw :7770 (ROCmFPX llama.cpp fork — see the LLM knowledge base below) — reached via host LAN IP 192.168.0.143:7770
Network	Pinned bridge systemd-open-webui (10.89.3.0/24, gateway 10.89.3.1) — see History
Persistence	Quadlet unit open-webui.service; [Install] WantedBy=default.target
Deploy	scripts/deploy-open-webui-quadlet.sh dankclaw

The LLM backends

The fleet runs two OpenAI-compatible endpoints. This mapping is the live state (verified 2026-09-03). Both services listen on :7770, distinguished by host; frank-large moved from :52625 to :7770 on 2026-08-22.

Endpoint	Model name	Host	Capability
:7770 (ROCmFPX llama.cpp fork)	frank-large	Dankclaw	completion
:7770 (ROCmFPX llama.cpp fork)	frank-medium	Dankserver	completion

The default connection points at the on-host endpoint (frank-large). To add the other backend, open Admin → Connections in the UI and point an OpenAI connection at http://192.168.0.235:7770/v1 (key none).

Both endpoints are bare-metal systemd services managed by this repository (the former vllmScripts repo, merged in 2026-08-22). Model swaps, context sizing, and spec tuning happen there. See the LLM knowledge base.

Web search

Chat web search is served by SearXNG on this host, wired in the quadlet (ENABLE_WEB_SEARCH, WEB_SEARCH_ENGINE=searxng, SEARXNG_QUERY_URL).

• Access path: the backend calls http://192.168.0.143:8081/search?format=json directly — gluetun's published port, NOT the search.franksdank.cloud vhost. The Anubis→Authentik guard chain is a browser mechanism (proof-of-work + session flow); a plain HTTP client cannot solve it, and the internal port bypasses Caddy entirely.
• Limiter: SearXNG caps non-HTML (JSON) requests at 4/IP/hour (API_MAX, a hardcoded Python constant — no config knob). The pass_ip list is checked FIRST and short-circuits the whole botdetection chain, and OpenWebUI's bridge egress (10.89.x) is in pass_ip, so the cap never applies. Verified: an 8-request burst from the container returned 8×200.
• Config storage: OpenWebUI keeps web-search settings per-key in its SQLite config table (webui.db, web.search.*). The quadlet env vars seed that table on first start (fill-missing only); afterwards the DB is authoritative and Admin-UI edits persist there.

Boot persistence (Quadlet)

The unit lives at dankclaw/open-webui/quadlet/open-webui.container. On the host it installs to ~/.config/containers/systemd/open-webui.container. The generator turns it into open-webui.service. Because the unit sets [Install] WantedBy=default.target and user linger is on, it starts at boot. systemctl --user is-enabled open-webui.service reports generated (the quadlet boot-start state).

Volumes

Container path	Host path
/app/backend/data	/home/dank/Containers/open-webui/data

The data dir holds the database, RAG indexes, and uploads. The deploy script creates it if missing and preserves it across reruns.

Healthcheck

The quadlet carries a built-in healthcheck (30s interval, 3 retries, 300s start period). It checks two things from inside the container:

1. App liveness — GET http://127.0.0.1:8080/health returns 200 ({"status":true}).
2. Network liveness — a non-loopback interface exists in /sys/class/net. The dead-tap zombie state (History) leaves only lo behind, and this is the check that catches it.

podman ps shows the container as unhealthy if either fails. Probe manually at http://dankclaw:3005/health.

Retired instances

• The compose open-webui service (port 3000) was never run: 3000 is Gitea's HTTP port, so it could not bind.
• The bare-container open-webui on Dankserver (port 3000) pointed at a dead backend (:9090) and was removed. Its data dir is preserved on Dankserver in case it is needed.
• The bare-container searxng on Dankserver (port 8081) was removed. SearXNG now runs only on Dankclaw behind Caddy.

Gotchas

• The image tracks upstream main; pin a digest in the quadlet unit if reproducible rollback matters more than tracking. (The old "CPU-only host" framing is stale: this APU runs the gfx1151 ROCm build — see ComfyUI.)
• The default admin account is created on first login; secure it immediately.
• If the backend is loading (3–8 minute model load), OpenWebUI shows connection errors until the model is ready.
• The LLM is reached via the host LAN IP 192.168.0.143:7770, not the bridge gateway: the gateway (10.89.3.1) lives in the rootless netns, while llama-server runs in the host netns, so the gateway refuses. host.containers.internal is slirp4netns-only and does not resolve on a bridge either. To reach the Dankserver backend, use the LAN address 192.168.0.235:7770.

History

• 2026-08-22 — slirp4netns → pinned bridge. The unit ran on Network=slirp4netns. The slirp4netns helper process died (no OOM, no kill entry, no crash log found), and the container kept running with only lo in its netns: published port 3005 accepted TCP and reset every request, so chat served empty responses for ~2 days. Nothing logged an error. Moving to a kernel bridge removes the per-container helper entirely, and the healthcheck's interface check makes the zombie state visible if it ever returns.

See Also

• Dankclaw Stack
• Hermes — the agent OpenWebUI can talk to
• SearXNG — the search engine on this host
• LLM knowledge base — the vLLM and llama.cpp endpoints