Environment Variables

Objectives

By the end of this lesson, you should be able to:

• Read an environment variable with process.env
• Use a .env file and the dotenv package to manage configuration locally
• Explain why secrets shouldn’t be hardcoded into source code

💡 Why this matters: Real applications need different configuration in different places, a database URL in development is never the same as in production, and secrets (API keys, passwords) should never be committed directly into code. Environment variables solve both problems.

⚠️ A note on verification: every command and output in this lesson was actually run with Node.js.

Reading Environment Variables

// envdemo.js
console.log("NODE_ENV:", process.env.NODE_ENV);
console.log("PORT:", process.env.PORT || 3000);

NODE_ENV=production PORT=8080 node envdemo.js

NODE_ENV: production
PORT: 8080

node envdemo.js

NODE_ENV: undefined
PORT: 3000

process.env (Lesson 3) is an object holding every environment variable available to the running process. Setting NODE_ENV=production PORT=8080 before the command makes both available inside the program. Without setting them, process.env.NODE_ENV is undefined, and process.env.PORT || 3000 falls back to a sensible default, this || defaultValue pattern is extremely common for optional configuration.

Managing Variables with a .env File

Setting variables by hand on every command is tedious for real development. A .env file, combined with the dotenv package, loads them automatically:

npm install dotenv

# .env
API_KEY=abc123secret
DB_NAME=myapp_db

// dotenvdemo.js
require('dotenv').config();
console.log("API_KEY:", process.env.API_KEY);
console.log("DB_NAME:", process.env.DB_NAME);

node dotenvdemo.js

API_KEY: abc123secret
DB_NAME: myapp_db

require('dotenv').config() reads the .env file in the project root and loads every entry into process.env, exactly as if each one had been set on the command line. (Running this also prints a short confirmation line from dotenv itself, in addition to the two lines shown above.)

Never Commit .env to Version Control

A .env file typically holds real secrets, API keys, database passwords, tokens, and should never be committed to version control. The standard practice is adding .env to a project’s .gitignore file immediately, and instead committing a .env.example file listing the names of required variables with placeholder values, documenting what configuration a project needs without exposing any actual secret.

Try It

1. Write a script that reads process.env.GREETING, falling back to "Hello" if it isn’t set, and run it both with and without setting GREETING.
2. Create a .env file with two variables, install dotenv, and load them into a script.
3. Add .env to a .gitignore file, and create a .env.example file documenting the same variable names with placeholder values instead of real ones.
4. Explain, in your own words, why hardcoding a real API key directly into a .js file is a security risk, even for a private project.

Recap

• process.env gives access to environment variables, process.env.NAME || defaultValue is the standard pattern for an optional one.
• A .env file plus the dotenv package loads variables automatically during local development.
• .env should never be committed to version control, .gitignore it and commit a .env.example with placeholder values instead.

Next lesson: debugging, actually stepping through a running Node.js program.