Configuration Review

The Problem

Configuration is where development and operations collide. Hardcoded API URLs break when deploying to staging. Missing environment variables crash the app on startup without a useful error message. Secrets committed to git history persist forever. Feature flags without cleanup accumulate into an unmaintainable maze of conditionals. And when a production incident turns out to be a typo in an env var, everyone agrees they should have validated configuration at startup — but nobody does.

The Prompt

Review the configuration management in the following code. Act as a DevOps engineer auditing how the application handles environment-specific settings.

DEPLOYMENT: [e.g., Vercel, Docker, AWS Lambda, Netlify]
ENVIRONMENTS: [e.g., development, staging, production]

FILES:
[paste .env.example, config files, and code that reads env vars]

Evaluate across these dimensions:

1. **Secrets Management**
   - Are any secrets hardcoded in source code?
   - Are .env files excluded from git (.gitignore)?
   - Does .env.example exist with placeholder values (not real secrets)?
   - Are secrets accessed through environment variables, not config files?

2. **Validation at Startup**
   - Are required env vars validated when the app starts (not when first used)?
   - Do missing vars produce clear error messages naming the missing variable?
   - Are env vars typed (parsed as number, boolean, URL) rather than used as raw strings?
   - Is there a configuration schema (zod, joi, env-schema)?

3. **Defaults & Fallbacks**
   - Do non-sensitive settings have sensible defaults?
   - Are dangerous defaults avoided (DEBUG=true, CORS=*)?
   - Is it clear which values MUST be provided vs. which have defaults?

4. **Environment Separation**
   - Is configuration separated by environment (not if/else chains in code)?
   - Can the same build artifact run in any environment (12-factor)?
   - Are environment-specific configs documented?

5. **Feature Flags**
   - Are feature flags centrally managed (not scattered if/else)?
   - Do flags have expiration dates or cleanup reminders?
   - Can flags be toggled without redeployment?
   - Are stale flags (older than 3 months) identified for cleanup?

6. **Documentation**
   - Is every env var documented (purpose, format, example, required/optional)?
   - Are deployment instructions included for each environment?
   - Is the configuration changelog maintained?

For each issue, provide:
- **File**: Where the issue is
- **Severity**: security-risk / startup-crash / confusion / improvement
- **Problem**: What goes wrong
- **Fix**: Corrected configuration code

Example Output

## Configuration Review: 5 issues found

### Security Risk: API Key in Source Code
File: src/lib/analytics.ts:3
Code: `const API_KEY = 'sk_live_abc123def456'`
Fix: Move to env var:
  const API_KEY = process.env.ANALYTICS_API_KEY;
Add to .env.example:
  ANALYTICS_API_KEY=sk_test_placeholder

### Startup Crash: Silent Missing Env Var
File: src/db.ts:5
Code: `const url = process.env.DATABASE_URL` — undefined if not set, crashes on first query.
Fix (validate at startup):
  import { z } from 'zod';
  const env = z.object({
    DATABASE_URL: z.string().url(),
    PORT: z.coerce.number().default(3000),
  }).parse(process.env);

### Confusion: No .env.example
No .env.example file exists. New developers must guess which env vars are needed.
Fix: Create .env.example documenting every variable with placeholder values and comments.

When to Use

Run this when setting up a new project, onboarding a new developer, or preparing for deployment to a new environment. Essential before any production deployment and after any incident caused by misconfiguration. Use it as a checklist to audit configuration hygiene quarterly.

Pro Tips

• Include all config touchpoints — paste not just .env files but also the code that reads them. Configuration bugs often live in the consumer, not the declaration.
• Ask for a config schema — follow up with “Generate a zod schema that validates all environment variables at startup with proper types and defaults.”
• Check git history — ask “Are there any secrets that were committed and then removed? They still exist in git history.”