haylanandClaude-Bot
24d749b2e0
update.sh now creates .env from .env.example if missing, idempotently fills in every random secret (same logic generate-secrets.sh had, now removed), resolves SEARXNG_LAN_IP from search.home via the host's own DNS, and mints OPENWEBUI_LITELLM_KEY / MEMORY_RETRIEVAL_EMBEDDING_KEY through LiteLLM's own /key/generate API once litellm is up — no more manual Admin UI step for the stack's own two workload keys. Docs updated to point at update.sh as the one command; docs/proxy-key-onboarding.md keeps the manual/API steps as the fallback and for onboarding other workloads. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2.1 KiB
Onboarding a workload onto the AI proxy
How to issue a new per-workload API key against the LiteLLM proxy (see 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.
OPENWEBUI_LITELLM_KEY and MEMORY_RETRIEVAL_EMBEDDING_KEY — the two keys this stack's own services need — are minted automatically by ./scripts/update.sh via the same API curl shows below; the steps here are for any other workload, or for those two if the automatic mint ever fails.
Create the key
- Log into LiteLLM's Admin UI (
/uion the proxy's deployed URL). - Create a new virtual key ("Keys" → "Create Key").
- Name it
<workload>-<purpose>— a short slug matching the workload, e.g.paperless-ocr,gitea-code-review,openwebui. This name is the ledger: LiteLLM's dashboard lists keys by name, so there's no separate tracking doc to keep in sync — name it clearly and the Usage tab tells you the rest (spend, last used, etc.). - Leave budget and rate limits unset (unlimited) by default. This is a shadow-cost estimate for fun, not real accounting or resource protection — see
docs/research/proxy-shadow-pricing.md. Only set a budget if a specific workload turns out to need a tripwire.
Or the same thing over the API (what update.sh does):
curl -sf -X POST "http://<proxy>:4000/key/generate" \
-H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
-H "Content-Type: application/json" \
-d '{"key_alias": "<workload>-<purpose>"}'
# -> {"key": "sk-...", ...}
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 Admin UI ("Keys" → delete) only when:
- the workload is retired, or
- the key is suspected leaked/compromised.
Then remove it from that workload's .env.