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. This is 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, and SaaS onboarding that works before any setup all follow the same ladder. ## Source - [[12 Fractured Apps]] — Kelsey Hightower, Medium, Dec 14 2015