8b3fbab7a03991a0db01378657cd326dbc416828
The Dokploy build failed at "Collecting page data for /api/assistant" with "LOYALY_API_BASE is required in production". The guard was right; where it ran was not. const BASE = resolveBase(); // evaluated on import next build imports every route module to collect page data, the Docker builder stage sets NODE_ENV=production, and LOYALY_API_BASE is a RUNTIME value that is not present while an image is being built. So the check fired against the build instead of against a misconfigured server. The previous comment claimed this matched tokenStore's stance on AUTH_SECRET; it did not - tokenStore.key() is a function, called per use. It is now genuinely the same shape: resolved on first use and memoised, so building needs no platform host and serving still refuses to guess one. The value is also validated rather than merely present. It used to accept any string, so platform.loyaly.ai - which serves THIS console, not the API - was taken and only failed later as a contract_mismatch at first login. Production is now an allowlist of exactly one origin, and the known-wrong host is rejected everywhere with the reason attached, because "rejected" alone sends somebody hunting for a firewall when the fix is one word in a variable. Development stays permissive (LAN, tunnel, container host) minus that same host - nothing a dev machine reaches is production. production https://mcp.loyaly.ai only; missing, http://, platform.loyaly.ai, any other origin, a bare hostname and a non-http scheme all throw development loopback and friends, or unset -> http://127.0.0.1:8088 An invalid or missing value is never cached, so a misconfigured process fails identically on every request rather than once and then differently. AUTH_SECRET is no longer an ENV line in the Dockerfile. A session-signing key in git means anyone who can read the repo can forge a cookie for any user, and every built image carried it in a layer `docker history` will print; Docker's own linter flags the pattern. Both AUTH_SECRET and LOYALY_API_BASE are now supplied by the orchestrator at runtime, and the file says so. ROTATE the old AUTH_SECRET - it remains in this repository's history. Verified: docker build --no-cache with neither variable set compiles, passes TypeScript and collects page data. The built container starts without them, serves /login, and answers the first API call with the configuration error naming the variable. With LOYALY_API_BASE set it reaches the real platform. tsc clean; lint unchanged at the existing baseline. REQUIRED in Dokploy before this deploys: LOYALY_API_BASE=https://mcp.loyaly.ai AUTH_SECRET=<openssl rand -base64 48> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0161AMotQ8FxGPZ9gFGb5wiK
This is a Next.js project bootstrapped with create-next-app.
Getting Started
First, run the development server:
npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev
Open http://localhost:3000 with your browser to see the result.
You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.
This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.
Learn More
To learn more about Next.js, take a look at the following resources:
- Next.js Documentation - learn about Next.js features and API.
- Learn Next.js - an interactive Next.js tutorial.
You can check out the Next.js GitHub repository - your feedback and contributions are welcome!
Deploy on Vercel
The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.
Check out our Next.js deployment documentation for more details.
Description
Languages
TypeScript
95.4%
CSS
2.9%
JavaScript
0.9%
Dockerfile
0.6%
Shell
0.2%