How do you manage Next.js env variables on Vercel and use NEXT_PUBLIC_?

WHAT THIS TESTS: This question tests whether you understand the boundary between server and client code in Next.js and whether you treat environment variables as a security surface. Interviewers want to see that you know where secrets live, how they are bundled, and why a database connection string must never reach the browser. They also care if you understand the build-time versus runtime distinction for client-side code.

A GOOD ANSWER COVERS: First, explain that sensitive variables like a database connection string should be added in the Vercel project dashboard under Environment Variables or in a local .env file, and they must not use the NEXT_PUBLIC_ prefix. Second, clarify that non-prefixed variables are only accessible in Node.js contexts such as Server Components, API routes, route handlers, getServerSideProps, or middleware. Third, state that NEXT_PUBLIC_ exists specifically to expose values to the browser, because Next.js replaces process.env.NEXT_PUBLIC_X with the literal string at build time so the client bundle can use it without a server round-trip. Fourth, describe the risk: any value prefixed with NEXT_PUBLIC_ becomes part of the static or server-rendered JavaScript sent to every user, meaning secrets are trivially recoverable from the page source or network tab.

COMMON WRONG ANSWERS: A major red flag is saying you would prefix a database URL with NEXT_PUBLIC_ so the frontend can fetch data directly. Another is claiming that Vercel encrypts NEXT_PUBLIC_ variables in the browser bundle or that the prefix is just a naming convention with no security impact. Some candidates also confuse server-side rendering with server-side secrecy, arguing that because the variable is rendered on the server first, it stays hidden; this misses that the inlined literal still ships to the client.

LIKELY FOLLOW-UPS: The interviewer may ask how to rotate a leaked secret, what to do if you accidentally committed an env file to git, or how to share a variable between server and client safely. They might also probe whether you know that NEXT_PUBLIC_ variables are set at build time on Vercel, so changing them requires a rebuild unless you use runtime configuration strategies.

ONE CONCRETE EXAMPLE: Imagine you need a public Stripe publishable key for checkout. You set NEXT_PUBLIC_STRIPE_KEY in the Vercel dashboard and reference it in a client component to initialize Stripe.js. This is correct because the key is designed to be public. In contrast, your Postgres connection string belongs in DATABASE_URL with no prefix, and you should call it only inside a Server Component or an API route that queries the database and returns JSON to the client.