fix: evaluate login mode env at runtime

[mturac]

Summary

• mark login and logout pages as dynamic so DISABLE_LOGIN and CLOUD_MODE are read at runtime
• mark the config API route as dynamic so Docker runtime CLOUD_MODE is reflected in client config

Fixes #3549

Testing

• pnpm install --frozen-lockfile
• pnpm exec biome check src/app/login/page.tsx src/app/logout/page.tsx src/app/api/config/route.ts
• git diff --check

[vercel]

@mturac is attempting to deploy a commit to the Umami Software Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR fixes a Next.js static-rendering issue where DISABLE_LOGIN, CLOUD_MODE, and related env vars were evaluated at build time rather than at each request, causing Docker runtime configuration to be ignored. Adding export const dynamic = 'force-dynamic' to the login page, logout page, and config API route forces Next.js to skip static generation and evaluate env vars on every request.

• src/app/login/page.tsx and src/app/logout/page.tsx now check DISABLE_LOGIN/CLOUD_MODE per request, so Docker-injected env changes are reflected without a rebuild.
• src/app/api/config/route.ts now always returns live env values (e.g. cloudMode, privateMode) rather than values snapshotted at build time.

Confidence Score: 4/5

The three force-dynamic additions are safe to merge; a separate pre-existing bug in the config route returns currentVersion as a boolean instead of the version string.

The force-dynamic changes are minimal, targeted, and correct — they fix exactly the runtime env-var evaluation problem described. The only concern is unrelated to this PR: currentVersion: !!process.env.currentVersion in the config route coerces a version string to true/false, which would break any client logic that compares the returned value as a version string.

src/app/api/config/route.ts — the currentVersion field returns a boolean instead of the actual version string.

Important Files Changed

Filename	Overview
src/app/login/page.tsx	Adds export const dynamic = 'force-dynamic' so DISABLE_LOGIN and CLOUD_MODE env vars are evaluated at request time rather than build time.
src/app/logout/page.tsx	Adds export const dynamic = 'force-dynamic' for the same reason as the login page — env vars must be read per-request.
src/app/api/config/route.ts	Adds force-dynamic so CLOUD_MODE and other runtime env vars are always reflected in client config responses; pre-existing currentVersion: !!process.env.currentVersion coerces a version string to boolean, unrelated to this PR.

Sequence Diagram

sequenceDiagram
    participant Browser
    participant NextJS as Next.js Server
    participant Env as Runtime Env Vars

    Note over NextJS: Before fix — static rendering at build time
    Browser->>NextJS: GET /login
    NextJS-->>Browser: Page built at build time (DISABLE_LOGIN/CLOUD_MODE may be missing)

    Note over NextJS: After fix — force-dynamic
    Browser->>NextJS: GET /login
    NextJS->>Env: Read DISABLE_LOGIN / CLOUD_MODE
    alt env var set
        Env-->>NextJS: value present
        NextJS-->>Browser: return null (blank page)
    else env var absent
        Env-->>NextJS: undefined
        NextJS-->>Browser: Render LoginPage
    end

    Browser->>NextJS: GET /api/config
    NextJS->>Env: Read CLOUD_MODE, PRIVATE_MODE, etc.
    Env-->>NextJS: current runtime values
    NextJS-->>Browser: JSON config with live env state

Loading

Comments Outside Diff (1)

1. src/app/api/config/route.ts, line 22 (link)

   currentVersion coerced to boolean instead of returned as a string

   !!process.env.currentVersion converts the version string to true/false, so clients always receive a boolean rather than the actual version number. Any consumer of this field (e.g. an update-check comparison) will silently get true instead of e.g. "2.12.0". The !! coercion appears to be unintentional given that every other env field here is either returned as-is (strings) or deliberately double-negated (feature flags).

_{Reviews (1): Last reviewed commit: "fix: evaluate login mode env at runtime" | Re-trigger Greptile}