What is a public environment variable?

A public environment variable is a variable that a front-end build tool copies into the JavaScript it sends to browsers, usually selected by a name prefix such as NEXT_PUBLIC_ in Next.js or VITE_ in Vite, so its value becomes readable by anyone who loads the page.

How the prefix works

Server code reads environment variables when it runs. Browser code can't: there is no process environment in a visitor's tab. So the build tool replaces references with the literal value while it builds.

Next.js describes it directly: it can "inline" a value "at build time, into the js bundle that is delivered to the client, replacing all references to process.env.[variable] with a hard-coded value", and the prefix is how you ask for that (Next.js). Vite says variables prefixed with VITE_ "will be exposed in client-side source code after Vite bundling", and that they "should not contain sensitive information such as API keys" (Vite). Other frameworks draw the same line in their own way; see Astro, Nuxt and SvelteKit.

# Fine: designed to be public
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_EXAMPLE_not_a_real_key
# Never: this ships to every visitor
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_EXAMPLE_not_a_real_key

Two consequences people miss

• The value is public, permanently. Once a build with a secret in a public variable is deployed, the value is in files that browsers, CDNs and crawlers have copied. Removing it from the next build doesn't remove those copies. Treat it as a leaked secret and reissue it.
• The value is frozen at build time. Next.js notes that after the build, "all NEXT_PUBLIC_ variables will be frozen with the value evaluated at build time", so one image promoted from staging to production keeps the staging value. Changing the variable in your hosting dashboard does nothing until you rebuild.

Common mistakes

• Adding the prefix to make an error go away. A component reads process.env.API_KEY, gets undefined in the browser, and someone renames it to NEXT_PUBLIC_API_KEY. The fix belongs on the server: call your own API route, which uses the key.
• Assuming the publishable key's rules apply to everything. Keys built for the browser, such as Stripe's publishable keys, are safe there. Most other keys are not.
• Expecting a runtime change. Public variables need a rebuild; server variables don't.

Where Crunu fits

No vault can make a public value secret again, and Crunu doesn't try. If a value is meant to reach the browser, it isn't a secret, and keeping it encrypted in a vault only controls who can edit it.

What Crunu can do is keep the two kinds apart. Store server-only values, such as STRIPE_SECRET_KEY, in the environment and pass them to the server process with crunu run. If you also keep public values there, the build reads them like any other variable, so name them with the public prefix only when you mean it. Before a release, Compare environments shows which variables differ between staging and production, which is where a stray prefix tends to show up.

Stack-specific details are in the pages for Next.js and Vite, and the leak pattern in detail in NEXT_PUBLIC_ leaks. Team setup: how to share .env files with your team.

Sources

• Next.js: How to use environment variables, checked October 30, 2026.
• Vite: Env variables and modes, checked October 30, 2026.