Set up environment variables so a secret never ends up in the client bundle

You are designing the environment variable setup for a Next.js app across its local, staging, and production environments, with the goal of making it structurally difficult for a secret to end up exposed in the client bundle by accident.

VARIABLES NEEDED
DATABASE_URL, STRIPE_SECRET_KEY, NEXT_PUBLIC_ANALYTICS_ID, SESSION_SECRET, NEXT_PUBLIC_API_BASE_URL

ENVIRONMENTS
local development, a staging environment on a preview branch, and production

DEPLOYMENT PLATFORM
Vercel for staging and production; local development runs with next dev

CURRENT SETUP
A single .env file with all variables, and STRIPE_SECRET_KEY is currently prefixed NEXT_PUBLIC_ because an early prototype needed it in a client component that has since been refactored to a Server Action

DESIGN RULES
Classify every variable as either genuinely needed in the browser or server-only, and treat that classification as the single fact that decides its name — a variable prefixed with NEXT_PUBLIC_ gets inlined into the client JavaScript bundle at build time, which means it is not a runtime secret in any environment, no matter how sensitive the value or how tightly the deployment platform's dashboard access is restricted, and prefixing an API secret key with NEXT_PUBLIC_ out of habit or because the client code happens to need some related, genuinely public value is a real leak, not a naming inconsistency. Never let a server-only variable get read from a Client Component, even indirectly through a shared config module imported by both server and client code — a config file that reads process.env.DATABASE_URL and exports it as a named constant will bundle that value into the client if any client-rendered code imports from the same file, even code that never actually touches the DATABASE_URL export; keep server-only config in a module that a Client Component file cannot import at all, not just one where the specific export happens to go unused there. For each of the stated environments, specify whether the platform reads env vars at build time or at runtime, since this materially changes the deployment story: a variable baked in at build time requires a rebuild to change, while a runtime-read variable can be updated by changing the platform's configuration and restarting the app, and mixing up which category a given variable actually falls into is a common cause of "I changed the environment variable but nothing changed" reports. Use a single, checked-in .env.example listing every variable name with a placeholder or description but no real value, so a new environment's setup is copy-and-fill rather than reverse-engineered from whichever teammate remembers what's needed; never commit an actual .env file with real values to version control regardless of how private the repository is. State explicitly which variables differ in value across the three environments and which are identical, since a variable that's identical everywhere except accidentally in one environment is a specific and common source of an environment-specific bug that looks like application logic but is actually a config mismatch.

OUTPUT FORMAT
A table: Variable name | Client-exposed or server-only | Build-time or runtime | Differs across environments (yes/no, and how) | Where it's actually read in the codebase. Then the .env.example file content, and one paragraph flagging any variable in the current setup that's misclassified today.