Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
A .env file is meant to store secrets for local development. Is it an acceptable way to manage secrets in a staging or production environment?
💻 Code Challenge | +75 XP
Set up a new Node project with .env in .gitignore, a committed .env.example documenting PORT/DATABASE_URL/JWT_SECRET, and dotenv/config imported as the first line of the entry file.
A database client module reads process.env.DATABASE_URL and gets undefined, even though the .env file clearly has the value set. Reorder the steps to diagnose and fix the import-order bug.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant

Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Committing a real .env file to version control
# .gitignore — add on day one, before any secrets exist
.env
.env.*.localThe Solution //
A .env file typically contains real secrets for at least local development. Once committed, those secrets live permanently in git history, retrievable even after the file is later deleted, unless history is explicitly rewritten. Add .env to .gitignore before the very first commit, and rotate any secret that was ever committed, even briefly.
The Error //
Importing a module that reads process.env before dotenv/config has run
// Wrong: db client reads process.env before dotenv runs
import { connectDb } from "./db.js";
import "dotenv/config";
// Correct: dotenv runs first, always
import "dotenv/config";
import { connectDb } from "./db.js";The Solution //
dotenv only populates process.env once its config() function actually executes. If another module reads process.env at its own top-level (module load time) before that happens — common when import order is accidental rather than deliberate — it silently receives undefined for every variable. Always import dotenv/config as the literal first line of your application's entry file.