haylanandClaude-Bot
3bbda098b3
No longer needed - every client is a coding CLI behind the OmniRoute
gateway, not a chat UI. Drops the open-webui and qdrant services,
WEBUI_PORT/OPENWEBUI_OMNIROUTE_KEY env vars, and the openwebui-data/
qdrant-data volumes. Qdrant only ever served Open WebUI's own built-in
memory/RAG (unrelated to the gateway-level knowledgebase removed in
472e3a4), so it goes too rather than sit unused.
Docs updated: README, docs/network-access.md (ai.home/ai.haylan.ch
section was entirely about Open WebUI, rewritten around the gateway),
docs/proxy-key-onboarding.md, docs/proxy-request-priority.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VPZ6TogJiYxG8E4EQBB197
2.2 KiB
Onboarding a workload onto the AI gateway
How to issue a new per-workload API key against the OmniRoute gateway (see issue #31 — the LiteLLM → OmniRoute migration; original gateway rationale in issue #10 / docs/research/proxy-tool-choice.md), so a new workload (a code-reviewer tool, Paperless-OCR, Gitea code review, etc.) gets its own key and its own visible usage/spend.
No workload in this stack itself needs a key right now — every client is external (a coding CLI, or another self-hosted service). There's no scripted mint yet either way: POST /api/keys needs a dashboard login session (ManagementSessionAuth), not a static bearer key like LiteLLM's old /key/generate, and that flow hasn't been verified against a live instance (see issue #37). Create every key by hand for now, via the dashboard steps below.
Create the key
- Log into the omniroute dashboard (
http://<host>:${OMNIROUTE_DASHBOARD_PORT:-20128}— LAN/host-only, never published publicly, seedocker-compose.yml'somnirouteservice). - "Keys" → "Create API key".
- Label it
<workload>-<purpose>— a short slug matching the workload, e.g.paperless-ocr,gitea-code-review,claude-code-cli. This label is the ledger: the dashboard lists keys by label, so there's no separate tracking doc to keep in sync. - Copy the key value shown — it's only shown once at creation, per OmniRoute's docs.
Once POST /api/keys's session-auth flow is worked out (issue #37), the equivalent curl here can replace this manual step, the way update.sh used to automate LiteLLM's /key/generate.
Hand it to the workload
Drop the key into that workload's own .env (or equivalent config) — never into this repo. Each workload's config is the source of truth for its own credential, same pattern as .env.example in this repo for the existing stack.
Retiring or rotating a key
No scheduled rotation. Revoke the key by hand in the dashboard ("Keys" → delete) only when:
- the workload is retired, or
- the key is suspected leaked/compromised.
Then remove it from that workload's .env.