Docs

Config and env doctor

The teammate who catches "works on my machine, breaks in prod" before you deploy. Plain-language checks for the classic config footguns in a repo, each with the exact fix: an env var the code reads that nothing declares, a var set locally but missing from .env.example, a hard-coded localhost URL that will not resolve in prod, and a stale var declared in .env.example but never read.

Where to find it

  • Localhost: /env-doctor.html
  • API: GET /api/env-doctor (add ?fresh=1 to re-scan)
  • Sidebar: Config, then Doctor

What it does for you

Names the config gap and the fix.The scan reads the env-var names declared in your .env* files and the names your code references, then flags the mismatches: referenced-but-unset (high), missing-from-example (high), no-env-example (warn), prod-unsafe hard-coded loopback URLs (warn), and declared-but-unused (warn). It is tuned for low false positives, with an allowlist of standard runtime vars and inline-default detection.
Reads names, never values.The doctor works from the variable names declared and referenced; it never reads or transmits the secret values. A clean result means none of these checks fired, not that every var is set correctly on your deploy host.

Built vs. planned

All five checks, the plain-language fixes, and the on-demand re-scan (?fresh=1) ship today, backed by lib/env-doctor.mjs (pure detection over already-read content plus a git and filesystem wrapper). A non-git path degrades to an honest error rather than throwing, and the detector regexes are written so the scanner's own source never self-matches. In the local dashboard this scan is folded into the Config tab as its Doctor subtab.