charlieviettq Dynamic Config Management
Centralize and validate configuration at startup. Reduces "works on my machine" and silent misconfiguration in deployed environments.
When to use
- New service or deploy target
- Mystery bugs from missing/wrong env vars
- Standardizing config across dev/staging/prod
When not to use
- Secrets rotation policy (use team secret manager docs)
- Feature flag product logic (may overlap with feature-flag systems)
Workflow
- Inventory — list all config keys, required vs optional, defaults
- Schema — validate types and allowed values (Zod, pydantic, envconfig, etc.)
.env.example— committed template with placeholders, no real secrets- Fail fast — app refuses to start if required keys missing or invalid
- Document — README section: key, purpose, example placeholder
Checklist
- No secrets in repo or logs
- Placeholder detection (
changeme,TODO, empty required vars) - Different files or prefixes per environment documented
- CI loads test config explicitly (not developer
.env) - Config dump endpoint disabled in production
Anti-patterns
- Reading os.environ scattered across codebase
- Defaulting production credentials to dev values
- Silent fallbacks that hide misconfiguration
Output
- Config schema module
- Updated
.env.example - Startup validation with actionable error messages
Related skills
secure-api-design— secrets handlingci-cd-quality-gates— CI env for testsserverless-debugging— env mismatch in functions
Clean-room config discipline workflow.