FundamentalsAsistido por IA2026-04-03•10 min de lectura

Environment Variables Explained Like You're 5

Por Salty Deprecated Software Engineer

✨ Contenido asistido por IA

Este artículo fue generado con asistencia de IA y revisado por nuestro equipo para garantizar su exactitud y calidad. Toda la información técnica y los ejemplos han sido verificados.

Every tutorial says "add your API key to a .env file" like you should know what that means. Nobody explains whythere's a .env file, what happens if you forget one, or why your app works on your machine but crashes on the server.

Environment variables are the simplest concept in software that everyone overcomplicates.Here's the entire idea in one sentence:

Environment variables are settings that change depending on where your code runs.

Your code stays the same. The database URL, the API key, the payment gateway — those change between your laptop, the test server, and production. Environment variables are how you tell your app "here's the right value for thisenvironment."

The Restaurant Analogy

Imagine a restaurant recipe (your code) that says "add salt." How much salt depends on where the dish is being served:

Development (your kitchen at home): A pinch. Experimenting. Doesn't matter if it's wrong.
Staging (taste test): The real amount. Testing before the restaurant opens.
Production (serving customers): The exact, measured amount. No mistakes.

The recipe doesn't change. The salt amount (environment variable) does.

What a .env File Looks Like

# .env.local (your machine only, never committed to git)
DATABASE_URL=postgres://localhost:5432/myapp_dev
STRIPE_SECRET_KEY=sk_test_abc123
NEXT_PUBLIC_SITE_URL=http://localhost:3000
# Lines starting with # are comments
# No quotes around values (usually)
# No spaces around the = sign

That's it. It's a list of KEY=VALUE pairs. Your code reads these values instead of hardcoding them.

Why Not Just Hardcode Values?

Three reasons, each one learned the hard way by someone before you:

Security. If you put your Stripe API key directly in your code and push it to GitHub, anyone can find it. Bots scan public repos for API keys — you'll get a bill within hours.
Flexibility. Your development database is at localhost. Your production database is at some-aws-url.com. If the URL is hardcoded, you'd need different code for each environment.
Teamwork. Every developer has their own API keys, their own test accounts, their own local database. Env files let each person configure their own setup without changing shared code.

How Your Code Reads Them

JavaScript / Node.js:
const dbUrl = process.env.DATABASE_URL;
Python:
import os
db_url = os.environ.get('DATABASE_URL')
Bash:
echo $DATABASE_URL

The File Naming Convention

.env — Default values, sometimes committed to git (non-secret only)

.env.local — Your machine only. Never committed. Overrides .env

.env.development — Used during npm run dev

.env.production — Used during production builds

.env.example — Template showing which variables are needed (committed to git, no real values)

The 5 Mistakes Everyone Makes

1. Committing .env.local to git. This exposes your secrets. Add .env*.local to your .gitignore immediately.
2. Forgetting to restart the server. Most frameworks only read env files at startup. Changed a variable? Restart.
3. Adding spaces around =. KEY = value breaks in most parsers. Use KEY=value.
4. Missing NEXT_PUBLIC_ prefix. In Next.js, only variables starting with NEXT_PUBLIC_ are available in the browser. Without it, the variable is server-only.
5. No .env.example file. New developers join your project and have no idea which variables are needed. Always maintain an example file with placeholder values.

The Bottom Line

Environment variables are not complicated — they're just configuration that changes per environment. Put secrets in .env.local, never commit them, restart your server after changes, and keep a .env.example so your teammates (and future you) know what's needed.

Building a project that needs environment variables? Our free Password Generator creates strong API keys and secrets, and our .gitignore Generator makes sure your .env files never get committed.

Salty Deprecated Software Engineer

Escrito bajo el seudónimo editorial de The IT Hustle: más de 25 años como técnico de laptops, administrador de sistemas, ingeniero de storage e ingeniero de software, ahora operando agentes de IA. Cada artículo pasa por revisión humana antes de publicarse; consulta la política editorial.

Nuestras herramientas Todos los artículos Sobre nosotros

Mantente al tanto

Sé el primero en conocer nuevas herramientas, artículos y actualizaciones. Sin spam.

Genera tus propios prompts anti-alucinaciones

Nuestro AI Prompt Engine usa tecnología propia para generar prompts con verificación integrada y pruebas de contradicción.

Prueba 3 generaciones gratis →

The Restaurant Analogy

Imagine a restaurant recipe (your code) that says "add salt." How much salt depends on where the dish is being served:

Development (your kitchen at home): A pinch. Experimenting. Doesn't matter if it's wrong.

Staging (taste test): The real amount. Testing before the restaurant opens.

Production (serving customers): The exact, measured amount. No mistakes.

The recipe doesn't change. The salt amount (environment variable) does.

What a .env File Looks Like

# .env.local (your machine only, never committed to git)

DATABASE_URL=postgres://localhost:5432/myapp_dev

STRIPE_SECRET_KEY=sk_test_abc123

NEXT_PUBLIC_SITE_URL=http://localhost:3000

# Lines starting with # are comments

# No quotes around values (usually)

# No spaces around the = sign

That's it. It's a list of KEY=VALUE pairs. Your code reads these values instead of hardcoding them.

Why Not Just Hardcode Values?

Three reasons, each one learned the hard way by someone before you:

Security. If you put your Stripe API key directly in your code and push it to GitHub, anyone can find it. Bots scan public repos for API keys — you'll get a bill within hours.

Flexibility. Your development database is at localhost. Your production database is at some-aws-url.com. If the URL is hardcoded, you'd need different code for each environment.

Teamwork. Every developer has their own API keys, their own test accounts, their own local database. Env files let each person configure their own setup without changing shared code.

The File Naming Convention

.env — Default values, sometimes committed to git (non-secret only)

.env.local — Your machine only. Never committed. Overrides .env

.env.development — Used during npm run dev

.env.production — Used during production builds

.env.example — Template showing which variables are needed (committed to git, no real values)

The 5 Mistakes Everyone Makes

1. Committing .env.local to git. This exposes your secrets. Add .env*.local to your .gitignore immediately.

2. Forgetting to restart the server. Most frameworks only read env files at startup. Changed a variable? Restart.

3. Adding spaces around =. KEY = value breaks in most parsers. Use KEY=value.

4. Missing NEXT_PUBLIC_ prefix. In Next.js, only variables starting with NEXT_PUBLIC_ are available in the browser. Without it, the variable is server-only.

5. No .env.example file. New developers join your project and have no idea which variables are needed. Always maintain an example file with placeholder values.

The Bottom Line

Building a project that needs environment variables? Our free Password Generator creates strong API keys and secrets, and our .gitignore Generator makes sure your .env files never get committed.