August 30, 2026 · In JLPTest
The variables that get baked into the build
Three times a deploy came up perfectly healthy and nobody could sign in. Always the same cause, and it never looked like it.
In Next, a NEXT_PUBLIC_ variable isn't read at startup: it's substituted for its value while compiling. If the build can't see it, what ends up inside the browser bundle is literally `undefined`, forever, until the next build.
And the build ran inside Docker, which doesn't inherit the platform's variables by default. The result was an app that passed every health check — container starts, server answers, pages render — and was broken in three different places:
- the sitemap pointed at localhost, and that's what the search engine picked up;
- the paywall couldn't be dismissed, because the payments client was born without a token;
- and login didn't work: the Supabase client was null, with not one error in the logs.
The obvious fix is declaring each variable as an ARG in the Dockerfile. It works, but it leaves the same trap set for whoever adds the next one. So the app stopped depending on that: whatever the browser needs is read on the server, at runtime, and handed down as props.
// Sólo la llave pública viaja, y viaja en el HTML, no en el paquete.
export function configurarSupabase(url?: string | null, key?: string | null) {
if (!url || !key || configurado) return;
configurado = { url, key };
clienteNavegador = undefined; // que se cree de nuevo con lo bueno
}The rule that stuck: if changing a variable forces an image rebuild, that variable is in the wrong place. And the security rule beside it: a secret key never carries that prefix, and the modules that use it import `server-only`, so leaking it is a compile error instead of an incident.