Configuration
GORM-managed tenant persistence for LLM Proxy
Persist TAuth accounts, isolated tenants, provider settings, generated secret digests, defaults, and usage through GORM.
Backend operators deciding how management-mode state is stored.
The problem
Self-service management needs persistent tenant state without mutating runtime config files or adding raw SQL paths.
How LLM Proxy helps
LLM Proxy stores TAuth users, their personal tenants, provider keys, defaults, generated secret digests, and usage events in a GORM-managed database.
How it works
- Configure management.database_path with the SQLite database location.
- Run management mode with the required provider-key encryption key.
- Let GORM model APIs own signup, provider, defaults, secret, and usage state.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| SQLite through GORM | Hosted and local management profiles choose the database location with one path. | The pure-Go SQLite driver keeps CGO_DISABLED builds valid. |
| No runtime config mutation | User signup and provider enablement update database state, not config.yml. | Configuration stays operator-owned. |
| Usage event persistence | Managed request metadata is stored with tenant isolation. | Dashboards survive restarts. |
Use-case examples
Local development
A developer supplies the path to a local ignored SQLite database file.
Hosted deployment
The service receives its persistent SQLite database path through deployment configuration.
Usage dashboard
The dashboard reads aggregate usage from persisted events.
Objections and limitations
- The current persistence engine is SQLite; other database engines are outside the contract.
- Storage access failures can affect management state and dashboard access.
- Provider transport config and model catalogs still live in config.yml.
FAQ
What is the main job of GORM managed tenant persistence?
LLM Proxy stores TAuth users, their personal tenants, provider keys, defaults, generated secret digests, and usage events in a GORM-managed database.
Who should read this configuration resource?
Backend operators deciding how management-mode state is stored.
Does this page claim provider performance or pricing advantages?
No. The supported claim is about LLM Proxy's documented routing, configuration, management, security, usage, and deployment contracts. Provider cost, speed, rankings, and benchmark claims are not made here.
Where should setup details come from?
Use the main README and implementation notes for current command, config, and endpoint details. This page summarizes the workflow without replacing LLM Proxy documentation.
What should I read next?
A closely related resource is LLM model catalog configuration in config.yml, which covers LLM model catalog configuration.
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