Deployment
API-served runtime config for a static LLM UI
Keep the Pages frontend static while the backend serves current runtime config at /config-ui.yaml.
Teams deploying a split-origin static management UI and backend API.
The problem
Static frontends can accidentally ship stale API origins, OAuth values, or runtime config if those values are rendered into the artifact.
How LLM Proxy helps
LLM Proxy's Pages app fetches backend-owned /config-ui.yaml at runtime, and the Pages artifact contains no static config-ui.yaml or llm-proxy-config.json.
How it works
- Publish the static UI from site/ to GitHub Pages.
- Run the backend with management config loaded from config.yml.
- Serve /config-ui.yaml from the API origin with allowed frontend CORS.
- Let the browser use that YAML for management API origin, proxy origin, MPR UI, and TAuth bootstrap.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Single browser config surface | The API backend projects runtime config into /config-ui.yaml. | Pages does not own a duplicate JSON config. |
| Split-origin support | managementApiOrigin and proxyOrigin are served to the browser. | The UI can call llm-proxy-api while hosted on llm-proxy. |
| Publish validation | The Pages publisher rejects forbidden static config artifacts. | Stale config files are removed from the rendered artifact. |
Use-case examples
Production Pages host
llm-proxy.mprlab.com serves the static UI while llm-proxy-api.mprlab.com serves config and APIs.
Local preview
A test server can serve /config-ui.yaml for browser checks without editing the static HTML.
Config rotation
Updating backend runtime config changes browser config without rebuilding the Pages artifact.
Objections and limitations
- The static UI needs the backend config endpoint to load fully.
- CORS and TAuth origins must match the hosted profile.
- Do not publish static config files as a fallback.
FAQ
What is the main job of API-served runtime config static UI?
LLM Proxy's Pages app fetches backend-owned /config-ui.yaml at runtime, and the Pages artifact contains no static config-ui.yaml or llm-proxy-config.json.
Who should read this deployment resource?
Teams deploying a split-origin static management UI and backend API.
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 Local and hosted LLM Proxy config profiles, which covers local and hosted LLM proxy config.
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