fix(docker): accept NEXT_PUBLIC_VF_DEMO_MODE build arg

[TerrifiedBug]

Summary

Adds ARG NEXT_PUBLIC_VF_DEMO_MODE + ENV NEXT_PUBLIC_VF_DEMO_MODE=${NEXT_PUBLIC_VF_DEMO_MODE} to the build stage of docker/server/Dockerfile immediately before pnpm build. This allows downstream consumers (e.g., the demo deployment in vectorflow-demo-ops) to inline the demo-mode flag into the Next.js client bundle at build time.

Why

Next.js inlines NEXT_PUBLIC_* env vars at build time, not runtime. Without exposing this as a Docker build arg, a vectorflow-demo-ops compose passing build.args.NEXT_PUBLIC_VF_DEMO_MODE: "true" is silently ignored — the client bundle bakes in the default (false), causing a hydration mismatch where the demo banner / hidden sign-out flicker after page load.

Safety

When NEXT_PUBLIC_VF_DEMO_MODE is not passed as a build arg, it resolves to an empty string. The app's check is process.env.NEXT_PUBLIC_VF_DEMO_MODE === "true", which is false for an empty string. Existing production builds are unaffected.

Relationship to PR #172

PR #172 (feat: hosted demo mode) introduced NEXT_PUBLIC_VF_DEMO_MODE and the demo-mode UI behaviors. This PR is the Dockerfile-side change that makes that feature actually inline into the client bundle. The two should land together — either order works, but neither is fully functional without the other.

Test plan

• CI green
• Build with no arg: docker build -f docker/server/Dockerfile . — succeeds, demo mode off
• Build with arg: docker build -f docker/server/Dockerfile --build-arg NEXT_PUBLIC_VF_DEMO_MODE=true . — succeeds, demo mode on in client bundle

[greptile-apps]

Greptile Summary

This PR adds ARG NEXT_PUBLIC_VF_DEMO_MODE and the corresponding ENV assignment immediately before pnpm build in the Docker build stage, allowing the Next.js client bundle to inline the demo-mode flag at build time as required by Next.js's NEXT_PUBLIC_* semantics. The change is minimal, correctly placed, and safely defaults to an empty string (which the app treats as false) when the arg is omitted.

Confidence Score: 5/5

Safe to merge — the change is a two-line, well-scoped Dockerfile fix with no impact on production builds when the arg is omitted.

No bugs, security issues, or correctness problems found. The ARG/ENV pair is placed correctly in the build stage immediately before pnpm build, which is the precise point Next.js needs NEXT_PUBLIC_* vars to be available for bundle inlining. The runner stage correctly omits the var since it's already baked into the static bundle.

No files require special attention.

Important Files Changed

Filename	Overview
docker/server/Dockerfile	Adds ARG + ENV for NEXT_PUBLIC_VF_DEMO_MODE before pnpm build in the build stage; placement and defaulting are correct.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["docker build --build-arg NEXT_PUBLIC_VF_DEMO_MODE=true"] --> B["Stage 3: build\nARG NEXT_PUBLIC_VF_DEMO_MODE\nENV NEXT_PUBLIC_VF_DEMO_MODE=..."]
    B --> C["pnpm build\n(Next.js inlines NEXT_PUBLIC_* at compile time)"]
    C --> D["Stage 4: runner\n(static bundle already contains baked value)"]
    D --> E["Browser receives bundle\nprocess.env.NEXT_PUBLIC_VF_DEMO_MODE === 'true'"]

    A2["docker build (no arg)"] --> B2["Stage 3: build\nNEXT_PUBLIC_VF_DEMO_MODE=''"]
    B2 --> C2["pnpm build\n(defaults to empty string → false)"]
    C2 --> D2["Stage 4: runner\n(demo mode off)"]

Loading

_{Reviews (1): Last reviewed commit: "fix(docker): accept NEXT_PUBLIC_VF_DEMO_..." | Re-trigger Greptile}

[TerrifiedBug]

Folded into PR #172. Same change, cleaner as one logical PR.