Environment variables: configuration kept out of the code

An application needs to know which database to connect to, which key to use for sending emails and whether it is running in test or production. Writing that information into the code means changing the code at every change, and exposes the keys to anyone who reads the repository. Environment variables solve both problems: the code asks for a value by name, and each environment supplies its own.

How it works

An environment variable is a name and value pair, for example STRIPE_SECRET_KEY=sk_live_.... The code only contains the name. At startup or build time, the host or the .env file supplies the value.

The same code can then run in three places with three configurations:

This split is what makes a serious staging environment possible, where you test a change without touching real data or real payments.

The distinction that matters: browser or server

A modern app has two categories of variables, and confusing them is one of the most common causes of an exposed secret.

Browser variables are read at build time and copied into the JavaScript sent to every visitor. With Vite, these are the ones starting with VITE_. The Vite documentation states that they should not contain sensitive information such as API keys. They are fine for the public Supabase URL, its publishable key or an analytics ID.

Server variables stay on the server and are never sent to the browser. On Supabase, these are Edge Function secrets, set in the dashboard or with supabase secrets set, then read in code with Deno.env.get. That is where the Supabase secret key and the payment, email or AI model keys belong. Supabase notes that deployed functions pick up a new secret without a redeploy.

Why it is a key point in a handover

The code leaves with the GitHub export. The variable values do not. That is intentional, since secrets should not be in the repository, but it creates a blind spot during a handover or a change of host: the migrated app starts, then payments, emails or sign-in fail one after another, for lack of configuration.

Our guide on exporting and owning the code details what travels with the repository. Variables are part of what must be inventoried separately, along with the account owner of each service.

How to check your app

1. Look for a .env.example file or a documented list of required variables. If none exists, the handover will start with an investigation
2. List the VITE_ or NEXT_PUBLIC_ variables and check that none holds a secret
3. Check the .gitignore: .env, .env.local and *.local should be excluded from the repository, as Vite recommends
4. Inventory the server-side secrets in the Supabase or platform dashboard, with the service involved and the owning account
5. Check the separation between test and production: different keys, a different database, and no live key on a developer's machine

A concrete example

A startup brings an app built with Replit in house. The code is on GitHub, the new host is ready. On first launch, the home page loads. Sign-ups fail: the email service key was never written down anywhere. Payments fail too: the Stripe key was registered on the account of the freelancer who started the project.

It took two days to track down the accounts, regenerate the keys and restore service. A fifteen-line inventory, prepared before the migration, would have cut that to an hour.

The most common mistakes

• A secret in a VITE_ or NEXT_PUBLIC_ variable, and therefore published
• A versioned .env file, sometimes since the first commit
• No documentation of the variables, known only to the tool or the freelancer
• The same values in test and production
• Secrets registered on a personal account rather than the company's

The takeaway

Environment variables are a simple good practice that only asks for one discipline: knowing which ones are public, which ones are secret, and where each one is stored. The vibebusters Scan produces that inventory, and the checklist places it among the points to check before a handover.