fix(docker): bake api token into frontend build

[diamondplated]

Summary

• pass AUTH_TOKEN into the frontend build as VITE_API_AUTH_TOKEN in Docker Compose
• export that build arg in the Dockerfile so browser clients stop prompting for the API token
• keep backend control-plane auth enabled while removing the extra login friction behind Cloudflare Access

[Copilot]

Pull request overview

This PR updates the container build configuration so the frontend is built with a predefined API auth token (via VITE_API_AUTH_TOKEN), aiming to stop browser clients from prompting for the token while backend control-plane auth remains enabled.

Changes:

• Pass AUTH_TOKEN into the Docker build as VITE_API_AUTH_TOKEN via Docker Compose build args.
• Add a corresponding Dockerfile ARG and export it as an ENV var during the build so Vite can embed it in the frontend bundle.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
docker-compose.yml	Adds VITE_API_AUTH_TOKEN build arg sourced from AUTH_TOKEN.
Dockerfile	Accepts VITE_API_AUTH_TOKEN build arg and sets it as an env var for the build step.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Passing the backend AUTH_TOKEN into the frontend build (VITE_API_AUTH_TOKEN: ${AUTH_TOKEN:-}) makes the control-plane bearer token effectively available to every browser user (it will be embedded in the built JS bundle via import.meta.env). That’s a significant security footgun and also couples backend token rotation to a required frontend rebuild.

Consider requiring an explicit, separate env var for the frontend token (e.g. ${VITE_API_AUTH_TOKEN:-}) or switching to a server-side/proxy-based auth approach so the shared control-plane token is never shipped to clients.

Suggested change

	VITE_API_AUTH_TOKEN: ${AUTH_TOKEN:-}
	VITE_API_AUTH_TOKEN: ${VITE_API_AUTH_TOKEN:-}

[Copilot]

Setting ENV VITE_API_AUTH_TOKEN=... in the Docker build stage bakes whatever token is provided into the static frontend build output. This means anyone who can load the UI can extract the token from the bundle, and if the image is pushed to a registry the token becomes part of the published artifact; rotating the backend token will require rebuilding/redeploying the frontend to match.

If the intent is to keep AUTH_TOKEN secret while reducing friction, consider moving auth to a server-side mechanism (reverse proxy that injects the header, Cloudflare Access JWT validation, etc.) or at least using a distinct, intentionally-scoped token for browser clients.

Suggested change

	ARG VITE_API_AUTH_TOKEN
	COPY --from=deps /app ./
	COPY . .
	ENV VITE_API_AUTH_TOKEN=${VITE_API_AUTH_TOKEN}
	COPY --from=deps /app ./
	COPY . .