Production deployment requires a reverse proxy to split `/v1/` traffic

[Prikis]

Problem

The dashboard hardcodes BASE = '/v1' in client.ts and relies on the Vite dev server's proxy config to split traffic between the admin server and the runtime server:

• /v1/reservations/* → cycles-server (runtime plane)
• /v1/* → cycles-server-admin

This works fine in development, but the Vite proxy is only active during npm run dev. In production, the built static files have no proxy — so deploying the dashboard requires setting up a separate reverse proxy (nginx, proxy servlet, etc.) purely to replicate what the Vite config already does. This adds significant operational complexity for what should be a straightforward static file deployment.

Proposed Fix

Replace the hardcoded BASE with two configurable environment variables:

VITE_ADMIN_URL=https://your-admin-server:7979
VITE_RUNTIME_URL=https://your-runtime-server:7878

And update client.ts to use them:

const ADMIN_BASE = (import.meta.env.VITE_ADMIN_URL ?? 'http://localhost:7979') + '/v1'
const RUNTIME_BASE = (import.meta.env.VITE_RUNTIME_URL ?? 'http://localhost:7878') + '/v1'

API calls would then use the appropriate base depending on whether they target the admin or runtime plane. This eliminates the need for any proxy infrastructure, is consistent with standard Vite environment variable patterns, and makes the dashboard deployable anywhere without server-side configuration.

The Vite proxy config in vite.config.ts could remain as-is for local development convenience, or be removed since it would no longer be necessary.

[amavashev]

Thanks for the detailed write-up. I dug into the current deployment artifacts and want to share some findings, because I think the proposal trades one form of complexity for several heavier ones.

The premise is weaker than it looks

The dashboard image already bundles the reverse proxy — operators don't stand up a separate one:

• Dockerfile copies nginx.conf into the image, so ghcr.io/runcycles/cycles-dashboard is the proxy.
• nginx.conf does exactly this split — /v1/reservations → cycles-server:7878, /v1/ → cycles-admin:7979 — resolving upstreams at runtime via Docker DNS.
• docker-compose.prod.yml wires it with zero extra proxy config; the operator only supplies hostnames.

So a production deploy is one self-contained image, not "dashboard + a proxy you assemble yourself."

Concerns with the env-var / direct-call approach

1. CSP blocks it. nginx.conf sets connect-src 'self'. Direct cross-origin fetch to the admin/runtime hosts is blocked until CSP is relaxed to whitelist both backend origins — the proposed snippet doesn't address this, so it would fail at runtime.
2. It mandates CORS on the browser path. Today all /v1/* calls are same-origin (client.ts builds URLs against window.location.origin), so CORS is never exercised. Going direct forces both backends to emit correct CORS, including preflight for the custom X-Admin-API-Key header.
3. Build-time baking breaks "deployable anywhere." VITE_* vars are inlined at npm run build, not read at runtime. The current image is environment-agnostic precisely because nginx resolves backends at container start. Under the proposal, one published image can no longer be retargeted — you'd rebuild per environment, which is worse for the stated goal.
4. Security. The admin key would be sent cross-origin to two hosts, and any https-dashboard → http-backend topology becomes mixed-content.

Also, mechanically the snippet is incomplete: only the three /v1/reservations endpoints use the runtime plane; everything else is admin. A real change would need RUNTIME_BASE for those three and ADMIN_BASE for the rest, plus the CSP/CORS work.

Suggested direction

If the goal is "configure backends without a rebuild," the approach that fits this repo's one-portable-image model is a runtime config (an env-substituted config.js / window.__CYCLES_CONFIG__ emitted by the container entrypoint). That keeps the same-origin proxy, avoids the CSP/CORS/key-exposure costs, and still lets a single image be retargeted at deploy time.

But it's worth confirming first whether the real gap is just documentation — OPERATIONS.md could make clearer that the image is self-contained and the proxy isn't a component you assemble separately.

Happy to prototype the runtime-config variant if there's appetite for it.

[amavashev]

Opened #189 with the interim fix discussed above: the bundled nginx proxy's upstreams are now configurable via ADMIN_UPSTREAM / RUNTIME_UPSTREAM env vars, rendered at container start — no file edit, no rebuild. Defaults match the compose service names, so existing deployments are unaffected.

This keeps the same-origin proxy model (avoiding the CSP/CORS/key-exposure costs of the VITE_* cross-origin approach). The broader runtime-config question can stay open if there's appetite for a fully proxy-less deployment; this unblocks split-host / external-endpoint deploys in the meantime.