A configuration file should never be a hard startup requirement: "There is absolutely no reason to require a configuration file after the 90s." An application that aborts when `/etc/config.json` is missing fails its very first deploy for a trivial, avoidable reason. The three-layer pattern Hightower prescribes: 1. **Load the config file if it exists**; if it's absent, log the fact and fall back to sane built-in defaults rather than calling `log.Fatal`. 2. **Override individual settings from environment variables** when present — the 12-Factor style, "one of the easiest things you can do directly in your application." 3. **Create missing resources** (e.g. the working directory) rather than demanding they pre-exist. This collapses a fragile, file-dependent startup into one that runs out of the box and is tunable without rebuilding or remounting. It also removes the temptation to bake config files into per-environment images (`app-v2-prod-01022015`), which spawns an unmanageable sprawl of container images. **Cross-domain**: the "work with zero configuration, allow override at every layer" ladder applies far beyond servers — CLI tools that run with no flags, libraries with default constructors, SaaS onboarding that works before any setup. Required configuration is friction; layered optional configuration is graceful degradation toward the happy path. ## Source - [[12 Fractured Apps]] — Kelsey Hightower, Medium, Dec 14 2015