env-cmd vs envscan

env-cmd injects env vars from a file when running a command. envscan reads your source code to discover which vars your app actually uses — then validates they're all set before you deploy.

Jump to waitlist ↓

Side-by-side comparison

Feature env-cmd envscan
Auto-discovers process.env calls ✗ ✓
Generates .env.example ✗ ✓
Validates vars present at deploy ✗ ✓ (exits non-zero)
Per-environment .env files ✓ (--environments flag) ✗ (not its job)
CLI command env-cmd -f .env ... npx envscan
Zero config ✗ (must define .env file) ✓

The workflow

env-cmd

# Install: npm install env-cmd

# package.json scripts
{
  "scripts": {
    "start": "env-cmd -f .env node server.js",
    "start:staging": "env-cmd -f .env.staging node server.js",
    "start:prod": "env-cmd -f .env.prod node server.js"
  }
}

# Loads vars from .env before running node
# No validation — if a var is missing,
# your app finds out at runtime

env-cmd reads a .env file and injects its contents as environment variables for the subprocess. You define which files to use — it doesn't know which vars your code actually needs.

envscan

# Scan source code for env vars
$ 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

# Generate .env.example from what it finds
$ envscan generate
# Wrote .env.example (8 vars)

# Validate before deploy
$ envscan validate
Validation: 7/8 vars set. Missing: JWT_SECRET
Exit code: 1

No config to write. envscan reads your .ts and .js files and knows which vars your app uses. Run validate in CI to catch missing vars before they hit production.

They solve different problems

env-cmd is a loader: it takes a .env file and injects its contents before running your command. It doesn't know which env vars your application actually reads from process.env — it just makes a file's contents available.

envscan is a discoverer and validator: it reads your source code to find every process.env.SOMETHING reference, then checks whether those vars are actually set before you deploy. Missing a var? Non-zero exit code stops the deploy.

The gap env-cmd leaves: if you add process.env.NEW_STRIPE_KEY to your codebase but forget to add it to your .env.prod file, env-cmd has no way to warn you. That var is undefined at runtime — and you find out in production.

Use both together

env-cmd and envscan are complementary. env-cmd loads your environment variables per-environment (dev, staging, prod). envscan validates that all the vars your code needs are actually present in whatever environment you're loading.

Add envscan to your existing env-cmd workflow as a pre-deploy check:

Combined workflow

# package.json
{
  "scripts": {
    "start": "env-cmd -f .env node server.js",
    "start:prod": "env-cmd -f .env.prod node server.js",

    // Add envscan validate before deploying
    "predeploy": "envscan validate",
    "deploy": "env-cmd -f .env.prod node deploy.js"
  }
}

# envscan validate runs first.
# If any var is missing, deploy never runs.
# env-cmd handles the actual loading.

When to use env-cmd

  • You need per-environment .env files (dev, staging, prod)
  • You want to inject env vars into npm scripts without a shell export
  • You're using a .env-cmdrc config file with multiple named environments
  • You want a simple loader that works cross-platform (no bash required)

When to use envscan

  • You want to know every env var your Node.js app actually reads from source code
  • You want .env.example generated automatically, not written by hand
  • You want CI to fail when a deploy is missing required env vars
  • You want to audit your codebase for undocumented env var references
← Back to all envscan comparisons

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