Environment Variables and Configuration

Every real application needs configuration that differs between environments and must not be hard-coded: the database connection string, API keys for third-party services, the public URL of the site, feature flags, and secrets for signing sessions. Environment variables are how you supply this configuration from outside your code, so the same codebase runs against a local database in development and a production database in deployment without changing a line. In the App Router, environment variables carry an additional and critical dimension: because your code runs in two places — on the server and, for client components, in the browser — you must be deliberate about which variables are allowed to reach the client, since a secret exposed to the browser is a secret leaked to the world.

This topic is small in surface area but outsized in consequence, because the most common and damaging configuration mistake is leaking a secret to the client, and the framework's rules around this are precise enough to be worth understanding exactly rather than approximately. A database password or API key bundled into client JavaScript is visible to anyone who opens the browser's developer tools, and such leaks are a recurring source of real breaches. Next.js draws a bright line using a naming convention: variables are server-only by default and never sent to the browser unless they carry a specific public prefix, which is an explicit, visible opt-in to exposure. Getting this right means understanding the prefix rule, where variables are loaded from, the difference between build-time and runtime values, and the discipline of keeping secrets out of the client and out of version control. This lesson covers how environment variables are defined and loaded, the server-versus-client exposure rule, and the configuration practices that keep secrets safe across environments.

Analogy🏏Cricket

🏏 Think of it like cricket: Picture a Test match where, before the openers walk out, the curator has already prepared the pitch, the umpires are positioned, and the scoreboard is live — the players just play. Plain React is like arriving at an empty ground and being told to roll the pitch, set the field, and wire up the scoreboard yourself before a single ball is bowled. Just as the prepared ground lets the batsmen focus on batting rather than groundskeeping, Next.js prepares routing, rendering, and bundling so you focus on features rather than plumbing. Just as the live scoreboard shows runs the instant a shot is played, server rendering hands the browser finished HTML the instant the page loads. And just as every Test follows the same agreed laws so any team can play anywhere, the App Router's file conventions mean any developer can read the folder structure and instantly know the routes. This reveals why Next.js wins on large teams: shared conventions remove the guesswork that custom setups create.