Most .env errors aren't missing secrets — they're the infrastructure variables nobody thinks to document. Ten env vars that have caused real outages, with what they do and why you want them set explicitly.
1. NODE_ENV
Node.js libraries change behavior based on this: Express caches views, React runs production checks, Next.js optimizes builds. An unset NODE_ENV defaults to a mystery — Express treats anything non-production as development; other libs are less generous.
Fix: always set to exactly development, test, or production.
2. TZ
Every container you don't set TZ on runs in UTC. Logs, cron jobs, and user-visible timestamps all silently assume UTC. Then one day a customer asks why their report says 2am and you can't explain.
Fix: TZ=America/New_York (or UTC explicitly) in every container. Yes, even the ones that "just do math."
3. NODE_TLS_REJECT_UNAUTHORIZED
You're proxying through a corporate MITM with a self-signed cert. Your Node app silently refuses the connection. You Google, find this variable, set it to 0, ship it to prod. Now your prod app trusts every cert.
Fix: set the specific CA bundle via NODE_EXTRA_CA_CERTS=/path/to/ca.pem. Never set REJECT_UNAUTHORIZED=0 outside local dev.
4. PORT
Hosts that bind your app to a port tell you the number via process.env.PORT. Hardcode port 3000 in prod and your app runs, but no traffic reaches it. The health check fails silently.
Fix: always const port = process.env.PORT || 3000.
5. NEXT_TELEMETRY_DISABLED
Next.js ships anonymous usage data by default. On ephemeral CI workers this adds noise and occasional slowdowns. Some regulated shops require it be off.
Fix: NEXT_TELEMETRY_DISABLED=1 in CI-mode .env.
6. CI
Many tools check CI=true to disable interactive prompts (create-next-app, npm init, Playwright's headed mode). If you script these in your own CI and don't set CI=true, the tool may hang waiting for input.
7. LOG_LEVEL
Your prod logs are either silent (and you miss the error) or chatty (and you pay $300/mo for log volume). Setting LOG_LEVEL=info explicitly avoids both.
8. HTTPS_PROXY / NO_PROXY
The developer on your team behind a corporate firewall. Their npm install silently fails. You never notice because your install works. They quit after a week.
Fix: document these in the .env.example so new hires know they exist.
9. DATABASE_POOL_SIZE (or equivalent)
Most ORMs default to a pool of 10. Your serverless function runs 100 concurrent invocations. Your DB accepts 100 connections. You see sudden "too many connections" errors.
Fix: set pool size explicitly per deployment target. Serverless needs small pools (1–5); long-running servers can use 20–50.
10. NEXT_PUBLIC_SITE_URL / equivalent canonical URL
OG tags, sitemap URLs, OAuth redirects, absolute API URLs — everything that generates a URL needs a canonical base. Without this env var, you either hardcode localhost:3000 in prod or generate protocol-relative URLs that break in email clients.
Fix: always expose a *_SITE_URL variable. Read our NEXT_PUBLIC_ guide for the Next.js specifics.
How to make sure these are actually set
Before every deploy:
- Run the missing env detector with this list as the required keys.
- Run the diff checker between staging and prod — drift on these variables is the #1 cause of weird post-deploy behavior.
- Validate with the validator to catch empty values.
The checklist
# Copy this into your .env.example
NODE_ENV=
TZ=
PORT=
LOG_LEVEL=
NEXT_TELEMETRY_DISABLED=
CI=
DATABASE_POOL_SIZE=
NEXT_PUBLIC_SITE_URL=
# Set only if you need them:
# NODE_EXTRA_CA_CERTS=
# HTTPS_PROXY=
# NO_PROXY=