dotenv vs envscan
dotenv loads .env files into process.env. envscan scans your source code to know which vars you need — then generates and validates .env.example automatically. They work together, not against each other.
Jump to waitlist ↓Side-by-side comparison
| Feature | dotenv | envscan |
|---|---|---|
| Loads .env into process.env | ✓ | ✗ (use dotenv for this) |
| Auto-discovers vars from source code | ✗ | ✓ |
| Generates .env.example automatically | ✗ | ✓ |
| Shows file + line for each var | ✗ | ✓ |
| Type inference (_PORT, _SECRET, _URL) | ✗ | ✓ |
| Validates all vars are set before run | ✗ | ✓ |
| Fails CI with exit code 1 on missing vars | ✗ | ✓ |
| GitHub Action PR comments on new vars | ✗ | ✓ (CI tier) |
| Zero config — no schema file | ✗ | ✓ |
| Works at runtime (app startup) | ✓ | ✗ (runs pre-deploy) |
dotenv and envscan are complementary. Use dotenv to load vars at runtime. Use envscan to document and validate them before deploy.
The workflow
dotenv only
# Install: npm install dotenv
# Your .env.example needs manual upkeep:
# DATABASE_URL=
# PORT=
# JWT_SECRET=
# REDIS_URL=
# In your app:
require('dotenv').config()
// process.env.DATABASE_URL is now set
# But .env.example can go stale:
# You add process.env.NEW_KEY in code
# You forget to add it to .env.example
# Newcomers miss it. Deploy fails.dotenv loads vars. You still maintain .env.example by hand — and it can drift from reality.
dotenv + envscan together
# Scan source code for all process.env refs
$ envscan scan
Found 8 environment variables:
DATABASE_URL type: url src/db.ts:12
PORT type: number src/server.ts:5
JWT_SECRET type: secret src/auth.ts:8
NEW_KEY type: string src/api.ts:3
# Generate .env.example from what it finds
$ envscan generate
# Wrote .env.example (8 vars)
# Validate before deploy
$ envscan validate
Validation: 7/8 set. Missing: NEW_KEY
Exit code: 1envscan reads your source files to discover vars. .env.example is generated, not maintained.
dotenv and envscan work together
These are not competing tools. dotenv loads your .env into process.env at runtime — that part is solved. The unsolved problem is keeping .env.example accurate as your codebase grows.
Every time a developer adds a new process.env.VARIABLE reference, someone needs to update .env.example. envscan automates that. Run envscan generate to regenerate from source. Add envscan validate to your CI pipeline to catch missing vars before deploy.
When to use dotenv (always — it's the standard)
dotenv is not optional for most Node.js apps — it loads your .env file at startup. Every Node.js project that uses environment variables should use dotenv (or a compatible loader like dotenv-flow, dotenv-defaults).
envscan does not replace dotenv. It complements it.
When to add envscan
- You want .env.example auto-generated from source (not maintained by hand)
- Your .env.example has gone stale before and caused onboarding friction
- You want CI to catch missing env vars before a deploy fails in production
- You want file and line context for every env var in the project
- You want type hints on every var (
_PORT→ number,_SECRET→ redacted,_URL→ url)
Get Early Access
envscan is in development. Join the waitlist to get notified at launch.
From the team behind textlens — 96/week npm downloads.
Get Early Access$0 — no credit card required