Compile‑time config in config/config.exs versus runtime config in config/runtime.exs for environment‑specific values

Goal: Ensure that configuration values such as database credentials or feature flags reflect the environment where the released Elixir node runs, without requiring a new build for each change.

Constraint: In a release, code in config/config.exs is executed during the mix release step, so any System.get_env/1 call captures the build‑time environment and becomes baked into the artifact. Moving the same call to config/runtime.exs defers evaluation to startup, but introduces a small runtime cost and requires the file to be imported after all compile‑time configuration.

Uncertainty: Which trade‑off favors reliability and operational flexibility for environment‑specific values, and how does the placement affect startup latency and the possibility of accidental overrides?

• Should secrets that may differ between deployments be placed exclusively in config/runtime.exs to avoid rebuilding?
• What measurable impact does evaluating config/runtime.exs have on application startup time compared to a pure compile‑time configuration?
• Can a hybrid approach safely use config/config.exs for static values while reserving config/runtime.exs for dynamic ones without risking key overrides?