Management UI
Self-service LLM key management for internal teams
Log in to the LLM Proxy app, create a client key for the selected tenant, and autosave one provider API key before leaving Settings.
Teams that want user-owned AI access without asking operators to edit YAML for every change.
The problem
Operator-provisioned AI access does not scale when each user or team needs provider keys, defaults, generated secrets, and examples updated separately.
How LLM Proxy helps
LLM Proxy includes an optional TAuth-protected management UI that creates a missing client key after authentication, autosaves provider settings, and keeps Settings open until at least one managed provider key persists.
How it works
- Enable management mode with TAuth and database configuration.
- Publish the static Pages UI and serve runtime config from the API backend.
- Users sign in; the UI creates and presents a missing client key once.
- Users enter at least one provider key; the selected provider settings autosave before they leave Settings.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| TAuth-gated UI | Management controls appear only after login. | Unauthenticated users see the sign-in state, not tenant controls. |
| Required first-run setup | Settings stays open until a client key and one persisted provider key exist. | Typed drafts and local dotenv credentials do not bypass onboarding. |
| Selected-provider editor | Provider key, text model, and system prompt live together and autosave. | A user can update one provider without scanning every provider card or pressing a save button. |
| Copyable examples | Default and provider-specific curl examples use the current proxy origin and generated-secret placeholder. | Users can start with the exact request shape shown in Settings. |
Use-case examples
New team onboarding
A user signs in, copies the automatically created client key, enters an OpenAI key, and closes Settings after autosave completes.
Provider update
A user switches the selected provider editor to DeepSeek and its changed model autosaves.
Usage review
The user returns to the dashboard and selects all-time, 30-day, 7-day, or 1-day request and token summaries.
Objections and limitations
- Management mode requires configured TAuth, CORS origins, database settings, and provider-key encryption key.
- The backend serves management APIs and runtime config; the static Pages app is only the shell.
- Autosave responses return masked key status; raw retrieval requires the separate owner-authenticated reveal action.
Repository evidence
if (this.settingsRequired) {
this.openSettings();
}
if (!this.hasSecret) {
await this.requestAndApplyGeneratedSecret();
}Verified 2026-08-08 by Tyemirov on GitHub against site/assets/llm-proxy/js/ui/authenticationLifecycle.js.
FAQ
How does first-run LLM Proxy setup begin?
After MPR UI reports an authenticated session, the account and selected tenant profile load. The app automatically creates a client key when that tenant has none.
What lets a user leave Settings?
The loaded profile must report a client key and at least one persisted managed provider key. Until both conditions are true, close actions explain what is missing and keep Settings open.
Does typing a provider key unlock Settings?
No. Only a provider record returned with has_key after a successful autosave counts; drafts and local dotenv credentials do not satisfy managed onboarding.
Does onboarding change provider or model defaults?
No. Automatic client-key creation and provider-key validation leave the user's existing provider and model defaults unchanged.
What should I read next?
A closely related resource is Bring-your-own provider key portal for AI access, which covers bring your own provider key portal.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference