Configuration
Strict YAML config placeholders for LLM Proxy
Use config.yml for service settings, providers.yml for provider definitions, and env only for declared values.
Operators who want predictable startup behavior and no hidden runtime defaults.
The problem
Services that merge flags, env, defaults, and files can start with surprising configuration. Missing secrets may appear only when traffic arrives.
How LLM Proxy helps
LLM Proxy reads service settings from config.yml and provider definitions from providers.yml. It expands declared environment values and rejects unknown YAML keys.
How it works
- Put service configuration in config.yml.
- Put provider definitions and environment bindings in providers.yml.
- Use process environment or a sibling .env only to satisfy placeholders.
- Avoid ${NAME:-default}; the loader supports plain ${NAME}.
- Let startup fail when required placeholders or unknown keys are present.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Explicit YAML owners | Runtime code receives one validated service config and one validated provider catalog. | Flags and env are not alternate schema sources. |
| Strict placeholders | Missing placeholders fail startup. | Configuration errors are visible before traffic. |
| Unknown-key rejection | Stale or misspelled YAML keys fail instead of being ignored. | Forward-only config stays clean. |
Use-case examples
Hosted profile
Deployment secrets provide LLM_PROXY_MANAGEMENT_* placeholder values.
Local profile
configs/.env supplies SQLite management database values for local runs.
Obsolete credential field
A provider api_key field is rejected because provider credentials are tenant-managed state.
Objections and limitations
- Changing config requires restart.
- Client keys and provider API keys are saved through authenticated tenant management.
- This is a config discipline feature, not a secrets manager.
FAQ
What is the main job of strict YAML config placeholders?
LLM Proxy reads service settings from config.yml and provider definitions from providers.yml. It expands declared environment values and rejects unknown YAML keys.
Who should read this configuration resource?
Operators who want predictable startup behavior and no hidden runtime defaults.
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 provider catalog configuration in providers.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