Deployment
GitHub Pages management UI for LLM Proxy
Publish the static management frontend from site/ while the backend owns API and runtime config.
Teams deploying the self-service management UI as a static site.
The problem
Serving the management frontend from the API backend couples static hosting, runtime config, and proxy endpoints in one deployment surface.
How LLM Proxy helps
LLM Proxy keeps the frontend in site/ for GitHub Pages and keeps the Go backend responsible for /config-ui.yaml, /api/management/*, /, /v2, and /dictate.
How it works
- Run make release to render and package site/ as an immutable Pages release asset.
- Run make publish to upload that prepared asset without changing the live site.
- Run make deploy to activate the published asset on gh-pages.
- Configure GitHub Pages branch publishing and the custom domain.
- Point llm-proxy-api at the backend gateway route.
- Keep browser runtime config served only by the backend API origin.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Pages-owned static UI | llm-proxy.mprlab.com belongs to GitHub Pages. | The backend does not serve management HTML. |
| Makefile lifecycle | Release prepares, publish uploads, and deploy activates Pages. | GitHub Actions does not own production deployment. |
| Artifact checks | The rendered Pages artifact is checked for forbidden static config files. | The static shell stays config-free. |
Use-case examples
Pages preparation
make release renders the validated Pages archive locally.
Artifact publication
make publish uploads the exact prepared image and Pages artifacts.
Backend deploy
make deploy rolls out the backend and then activates the published Pages archive.
Objections and limitations
- Production deploy still requires operator-controlled gateway work.
- GitHub Pages custom domain and HTTPS settings must be configured.
- The static UI needs the backend API host available at runtime.
FAQ
What is the main job of GitHub Pages LLM management UI?
LLM Proxy keeps the frontend in site/ for GitHub Pages and keeps the Go backend responsible for /config-ui.yaml, /api/management/*, /, /v2, and /dictate.
Who should read this deployment resource?
Teams deploying the self-service management UI as a static site.
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