Before You Deploy

Three things apply regardless of how you deploy.

Environment variables

Every project has a web/.env.example listing every variable the app needs. Each one requires a production value before you deploy.

Variables starting with NEXT_PUBLIC_ are baked into the browser bundle during the build. They must be set before the build runs, not at runtime. Changing a NEXT_PUBLIC_* value requires a full rebuild.

Reverse proxy

You need a reverse proxy in front of your app for TLS. The proxy must pass three headers so the app knows what the original request looked like:

Header	What it tells your app
Host	The hostname the user typed (e.g. app.example.com).
X-Forwarded-Proto	Whether the original request was http or https. The app uses this to build correct absolute URLs and decide whether to mark cookies as Secure.
X-Forwarded-For	The real client IP address.

Each deployment guide shows how to configure these headers for its platform.

Cookie domains

If your project uses cookie-based authentication, the frontend and the auth endpoint must sit on the same registrable domain. The registrable domain is the part you buy from a registrar. For app.example.com, that’s example.com. For auth.example.com, also example.com.

Modern browsers only send auth cookies on requests that share this domain. Ports don’t factor into the comparison.

Frontend	Auth endpoint	Works?
app.acme.com	auth.acme.com	Yes — both acme.com
app.acme.com	acme-auth.com	No — different domains
localhost:3000	localhost:10010	Yes — ports don’t affect same-site

If you can’t put both services under one domain, use the reverse proxy to expose the auth endpoint under a path on your main domain (e.g. https://app.example.com/auth/... proxying through to the real auth service). The browser only ever sees one domain.

If your project doesn’t use authentication, skip this section.