haylan/LLM-Server
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

How should per-workload API keys/accounts be provisioned, rotated, and documented? #12

New Issue
Closed
opened 2026-08-25 04:39:55 +00:00 by haylan · 1 comment
haylan commented 2026-08-25 04:39:55 +00:00
Owner
Copy Link
Copy Source

Part of #9

Question

Given the tool chosen in #10, what's the actual workflow for issuing a per-workload API key/account: who/what creates it (CLI, admin UI, API call), where the credential is handed to each downstream workload, how it's stored, and how revocation/rotation works? Should mirror the local-usage-docs pattern from map #1 (#6) — a doc a future session can follow to onboard a new workload (e.g. the code-reviewer tool or Paperless-OCR) without re-deriving the process.

Part of #9 ## Question Given the tool chosen in #10, what's the actual workflow for issuing a per-workload API key/account: who/what creates it (CLI, admin UI, API call), where the credential is handed to each downstream workload, how it's stored, and how revocation/rotation works? Should mirror the local-usage-docs pattern from map #1 (#6) — a doc a future session can follow to onboard a new workload (e.g. the code-reviewer tool or Paperless-OCR) without re-deriving the process.
haylan added the wayfinder:grilling label 2026-08-25 04:39:55 +00:00
haylan added a new dependency 2026-08-25 04:40:14 +00:00
#14 Author the docker-compose service for the chosen proxy
haylan self-assigned this 2026-08-25 04:51:44 +00:00
haylan commented 2026-08-25 04:57:10 +00:00
Author
Owner
Copy Link
Copy Source

Resolved via grilling.

Keys created by hand in LiteLLM's Admin UI, named as a workload-purpose slug (e.g. paperless-ocr, gitea-code-review) — the name is the ledger, no separate tracking doc, since LiteLLM's dashboard already lists spend per key. No budget/rate limit set by default (this is a for-fun shadow estimate, not real accounting or resource protection — set one later only if a specific workload needs a tripwire). Key is dropped into that workload's own .env, never committed to this repo. Revocation is manual via the Admin UI, triggered only by retirement or suspected compromise — no scheduled rotation.

Documented in docs/proxy-key-onboarding.md, committed on main.

Resolved via grilling. Keys created by hand in LiteLLM's Admin UI, named as a workload-purpose slug (e.g. `paperless-ocr`, `gitea-code-review`) — the name is the ledger, no separate tracking doc, since LiteLLM's dashboard already lists spend per key. No budget/rate limit set by default (this is a for-fun shadow estimate, not real accounting or resource protection — set one later only if a specific workload needs a tripwire). Key is dropped into that workload's own .env, never committed to this repo. Revocation is manual via the Admin UI, triggered only by retirement or suspected compromise — no scheduled rotation. Documented in docs/proxy-key-onboarding.md, committed on main.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
wayfinder:grilling
Wayfinder grilling ticket
 wayfinder:map
Wayfinder map issue
 wayfinder:prototype
Wayfinder prototype ticket
 wayfinder:research
Wayfinder research ticket
 wayfinder:task
Wayfinder task ticket
No labels wayfinder:grilling
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
haylan (Arthur Erlich)
No Assignees haylan
1 Participants
Notifications
Due Date
No due date set.
Blocks
#14 Author the docker-compose service for the chosen proxy
haylan/LLM-Server
Depends on
#10 Which self-hosted AI gateway/proxy tool fits this effort's needs?
haylan/LLM-Server
Reference: haylan/LLM-Server#12