feat: implement provider management (multi-auth, runtime CRUD, local providers) #451
Description
Summary
Full provider lifecycle management: add, edit, remove, and test LLM providers at runtime through the API and web UI. Support multiple authentication methods (API keys, OAuth, no-auth for local providers) with encrypted credential storage.
Motivation
Currently providers are defined in YAML and loaded at startup — no runtime changes, no UI. Users must edit files and restart. This blocks:
- First-run setup (no way to add a provider without a config file)
- Switching providers without downtime
- Using local providers (Ollama, LM Studio) that need no keys
- OAuth-based providers (Azure OpenAI, GCP Vertex) that use token refresh
Provider Auth Types
| Auth Type | Examples | Config Fields |
|---|---|---|
api_key |
OpenRouter, Anthropic, OpenAI, Together, Groq | api_key (encrypted in DB) |
oauth |
Azure OpenAI, GCP Vertex AI | client_id, client_secret, token_url, scope |
none |
Ollama, LM Studio, vLLM, LocalAI | base_url only |
custom_header |
Some proxy setups | header_name, header_value (encrypted) |
Provider Presets
Pre-configured templates for common providers (user just adds their key):
| Preset | Driver | Base URL | Auth | Notes |
|---|---|---|---|---|
| Ollama | litellm | http://localhost:11434 |
none | Local, no key needed |
| LM Studio | litellm | http://localhost:1234/v1 |
none | Local, OpenAI-compatible |
| OpenRouter | litellm | https://openrouter.ai/api/v1 |
api_key | Multi-model gateway |
| vLLM | litellm | http://localhost:8000/v1 |
none | Local, OpenAI-compatible |
Users can also add fully custom providers.
API Endpoints
| Method | Path | Description |
|---|---|---|
GET |
/api/v1/providers |
List all providers (keys masked) |
GET |
/api/v1/providers/{name} |
Get provider details |
POST |
/api/v1/providers |
Add new provider |
PUT |
/api/v1/providers/{name} |
Update provider config |
DELETE |
/api/v1/providers/{name} |
Remove provider |
POST |
/api/v1/providers/{name}/test |
Test connection (makes a minimal API call) |
GET |
/api/v1/providers/presets |
List available presets |
POST |
/api/v1/providers/from-preset |
Create provider from preset + user credentials |
Web UI
- Provider cards on Settings page — show name, driver, model count, connection status
- Add provider dialog — preset selector or custom form, auth type picker, key input
- Edit provider — update fields, rotate keys
- Test connection button — inline status indicator (green/red/spinner)
- Key input — password field, never echoed back, "key saved" indicator
Credential Storage
- All credentials stored via the settings persistence layer (feat: implement settings persistence layer (DB-backed config) #450)
- Marked
sensitive: true→ encrypted at rest (Fernet) - Never returned in API responses (stripped before serialization)
- Audit log entry on every credential write/rotate
Hot-Reload
When a provider is added/edited/removed via API:
- SettingsService persists to DB
- Change notification published to message bus
- ProviderRegistry rebuilds affected provider(s) without restart
- Existing in-flight requests finish with old provider; new requests use updated config
Dependencies
- feat: implement settings persistence layer (DB-backed config) #450 — Settings persistence layer (must exist first)
Acceptance Criteria
- CRUD API endpoints for providers
- Support for api_key, oauth, none, custom_header auth types
- Provider presets for Ollama, LM Studio, OpenRouter, vLLM
- Connection test endpoint
- Encrypted credential storage via settings layer
- Hot-reload: provider changes take effect without restart
- Web UI: provider cards, add/edit dialog, test button
- Credentials never returned in API responses
- Audit log for credential changes