Deployment
Local and hosted LLM Proxy config profiles
Use the same strict config contract locally and in hosted split-origin deployments.
Operators who need local development and production profiles to stay aligned.
The problem
Local profiles often accumulate defaults, fallback values, or alternate config paths that do not match hosted runtime behavior.
How LLM Proxy helps
LLM Proxy uses config.yml plus strict placeholder expansion for both local and hosted profiles, with ignored .env values supplying environment-specific secrets and database paths.
How it works
- Keep config.yml as the canonical service configuration.
- Use configs/.env locally for ignored placeholder values.
- Use deployment secrets for hosted LLM_PROXY_MANAGEMENT_* values.
- Run repo Makefile targets to validate config and tests.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Same loader | Local and hosted profiles pass through the same config loader. | There is no separate Pages config expansion path. |
| Ignored local DB | SQLite management files are ignored for local runs. | State does not enter git. |
| Hosted split origins | Production separates Pages frontend, API backend, and TAuth backend origins. | CORS and runtime config stay explicit. |
Use-case examples
Local UI preview
A developer serves site/ and mocks /config-ui.yaml for browser tests.
Hosted backend
Production provides real management database and encryption key through deployment secrets.
Provider smoke
Live provider smoke tests load available API keys from LIVE_ENV_FILE.
Objections and limitations
- Do not commit configs/.env, SQLite databases, or OAuth client secrets.
- Hosted deployment still requires gateway and DNS setup.
- Local validation does not replace live provider smoke tests when real provider behavior matters.
FAQ
What is the main job of local and hosted LLM proxy config?
LLM Proxy uses config.yml plus strict placeholder expansion for both local and hosted profiles, with ignored .env values supplying environment-specific secrets and database paths.
Who should read this deployment resource?
Operators who need local development and production profiles to stay aligned.
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 API-served runtime config for a static LLM UI, which covers API-served runtime config static UI.
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