What is the Externalized Configuration pattern?
The same build artefact runs in every environment. Settings such as URLs, feature flags and limits come from the environment (variables, mounted files or a config service), and secrets come from a secrets manager. Changing a setting does not need a rebuild.
What problem does the Externalized Configuration pattern solve?
Config baked into images means one build per environment, rebuilds for every change, and secrets copied into repositories and images where they are hard to rotate and easy to leak.
How do you implement the Externalized Configuration pattern?
- Read all environment-specific settings from the environment at startup, and fail fast if required ones are missing.
- Store secrets in a secrets manager and grant each service access only to its own.
- Prefer short-lived, automatically rotated credentials over static passwords.
- Version and review configuration changes like code.
- Decide which settings can change at runtime and how services pick them up.
When should you use it?
- Always, for anything deployed to more than one environment.
When should you avoid it?
- Never skip it. Avoid a dynamic config service for settings that rarely change, though. Environment variables are enough.
What do you gain?
- One artefact for every environment
- Secrets stay out of code and images
- Faster, safer config changes
What does it cost?
- Another dependency at startup
- Config drift between environments
- Runtime changes can surprise you if not tracked
What are common mistakes with the Externalized Configuration pattern?
- Secrets in environment files committed to the repository.
- Silent defaults that make a misconfigured service start and behave wrongly.
- Changing config at runtime with no audit trail of who changed what.
Externalized Configuration in practice
Harbor Logistics
Database credentials were committed to config files in the repository. An audit flagged them, and rotating a leaked password meant rebuilding and redeploying every affected service.
Configuration now comes from the environment at deploy time, and secrets are issued by a secrets manager as short-lived credentials. Rotation no longer needs a rebuild.
Example decision record
- Context
- Configuration is baked into images, so changing a value means rebuilding the container.
- Decision
- Inject configuration from the environment and fetch secrets from a secrets manager at runtime.
- Consequences
- The same image runs in every environment.
- Secret access is audited and credentials can be rotated without a rebuild.