Configuration

Artifact plus configuration equals a running service. What belongs in each, validating at startup rather than discovering at 3am, and treating config as a deployable with its own blast radius.

Artifact Plus Configuration

A running service is an immutable artifact combined with environment-specific configuration — and the configuration half is the one nobody versions, tests or reviews.

Q · What belongs in the artifact, what belongs in configuration, and why does that line decide so much?
Validate at Startup, Fail Clearly

Check every configuration value when the process starts and refuse to serve if anything is wrong — rather than discovering an invalid value at 3am, on the first request that happens to need it.

Q · When should a bad configuration value be detected, and what should happen when it is?
A Config Change Is a Production Change

Configuration changes reach production faster than code, apply to everything at once, are reviewed less, and frequently have no rollback story — which is why so many outages are config-only.

Q · Why do configuration changes cause so many outages when they involve no new code?
Configuration Drift

Configuration diverges between environments and between instances, and the divergence is invisible until a code path that only exists in one place runs for the first time.

Q · Why does a service behave differently in production when it is running the same artifact?
Build-Time and Runtime Configuration

When a value is fixed decides how you change it — build-time values need a new artifact and a full pipeline, runtime values change without one, and picking the wrong side quietly destroys build-once-promote-many.

Q · Should this value be baked into the artifact or read when the process runs?