Configuration
Strict YAML config placeholders for LLM Proxy
Use config.yml as the only service config source and env only for strict placeholder expansion.
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 configuration from config.yml, expands ${NAME} placeholders from env or a sibling .env file, rejects unknown YAML keys, and fails startup for missing required placeholders.
How it works
- Put service configuration in config.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 |
|---|---|---|
| Single config file | Runtime code receives only validated config values. | Flags and env are not alternate service config sources. |
| Strict placeholders | Missing placeholders fail startup outside the exact optional provider-key case. | 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.
Provider disabled
A non-default provider api_key that is exactly a missing placeholder can expand to blank and remain disabled.
Objections and limitations
- Changing config requires restart.
- The optional-provider-key exception applies only to the whole api_key value.
- 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 configuration from config.yml, expands ${NAME} placeholders from env or a sibling .env file, rejects unknown YAML keys, and fails startup for missing required placeholders.
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 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