fix: Sentry to be configured on runtime

[ludovicm67]

Context

The Sentry configuration — DSN, environment, and CSP host — was intended to be injected at container startup via environment variables, but none of the values were actually being picked up at runtime after the container was built, but was working well in local development setup.

There were two distinct root causes:

1. NEXT_PUBLIC_* variables are baked in at build time

SENTRY_DSN and SENTRY_ENV were exported from env.ts as process.env.NEXT_PUBLIC_SENTRY_DSN / process.env.NEXT_PUBLIC_SENTRY_ENV.
Next.js uses webpack's DefinePlugin to statically inline all NEXT_PUBLIC_* references into the bundle during next build.
By the time the container starts, those values are already frozen as undefined — runtime env vars have no effect.

2. next.config.js headers() is evaluated at build time, not at startup

With output: "standalone", Next.js compiles the result of headers() into routes-manifest.json during next build.
NEXT_PUBLIC_SENTRY_CSP, CSP_REPORT_ONLY, and PREVENT_SEARCH_BOTS were all read inside that function — meaning they too were evaluated once at build time and never re-read from the container environment.

Fix

SENTRY_DSN / SENTRY_ENV — dropped the NEXT_PUBLIC_ prefix and wired them into the existing runtime injection mechanism: api/client-env.ts already serves a JS snippet that populates window.__clientEnv__ at request time, and env.ts reads from it with a process.env fallback. These two vars are now included in that flow.

SENTRY_CSP / CSP_REPORT_ONLY / PREVENT_SEARCH_BOTS — moved all CSP and X-Robots-Tag header generation out of next.config.js and into a new middleware.ts.
Next.js middleware runs on every request and reads process.env live, so all these values are picked up correctly from the container environment.
The static security headers that have no env var dependency (X-Content-Type-Options, Referrer-Policy, etc.) remain in next.config.js.

Those changes are needed in the deployed instances:

• NEXT_PUBLIC_SENTRY_DSN → SENTRY_DSN
• NEXT_PUBLIC_SENTRY_ENV → SENTRY_ENV
• NEXT_PUBLIC_SENTRY_CSP → SENTRY_CSP

How to test

Build the image:

docker build --build-arg NEXTAUTH_URL=https://localhost:3000 -t visualize .

And start the app:

docker run -e SENTRY_CSP=https://glitchtip.puzzle.ch -e SENTRY_DSN=https://afa6c897392c46cdb1236235120771f4@glitchtip.puzzle.ch/34 -e SENTRY_ENV=dev -e 'WHITELISTED_DATA_SOURCES=["Prod"]' -e NEXTAUTH_SECRET=dummy --rm -p 3000:3000 -it visualize

You should see in the logs the value of the SENTRY_DSN in a log line starting with: Sentry DSN:.

When you open the homepage at http://localhost:3000/, you should see in the response headers, that the value from SENTRY_CSP was injected into the content-security-policy header.

---

• I added a CHANGELOG entry (the Add Sentry integration back was already there)
• I made a self-review of my own code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
visualization-tool	Ready	Preview, Comment	May 21, 2026 1:53pm