Cloud and infrastructure as code
Configuration, environments and feature flags
Twelve-factor config, environment parity, secrets injection, feature flags and the blast radius of a bad config push.
Code that works on your laptop and fails in production is usually a configuration difference. A variable is missing, a database URL is wrong, a flag is left on, or a migration ran in staging only. Configuration is how one artifact behaves in many places. Get the model right, and a deploy becomes "ship the image and set the knobs". Get it wrong, and every environment becomes a snowflake.
This topic covers the twelve-factor ideas that still hold, how many environments you need, how to layer and validate config, and how feature flags separate deploy from release. It also covers dynamic config, which has caused some of the sharpest outages. Database migrations follow the same rule: state must move carefully with the code. They are covered in zero-downtime schema changes.
The concept pages
| Step | Concept | What it answers |
|---|---|---|
| 1 | Twelve-factor config | Why must config stay out of the image? |
| 2 | Environments and parity | How many environments do you actually need? |
| 3 | Config layering and validation | Which value wins, and what happens when one is wrong? |
| 4 | Feature flags | How do you ship code dark and turn it on later? |
| 5 | Dynamic config and blast radius | How do you change live config without causing an outage? |
How the pieces fit together
A release is one image digest plus one config bundle. The image is built once, tested once and promoted unchanged. Config is layered on at startup and validated there. Flags and dynamic config change behaviour while the app is running. Each of these has its own blast radius, and the larger the blast radius, the stricter the control should be.
Database migrations follow the same rule. Schema state must change alongside the code that reads it, so the migration plan belongs in the release plan. The zero-downtime schema changes page walks through the safe order.
Common mistakes
- Baking hostnames or credentials into the image. One artifact can then run in only one place.
- Hot-editing production config. Without an audit trail and a rollback, you cannot explain the next incident.
- Flags that default to on. A new deployment then turns features on before anyone has checked them.
- Environments that differ in shape. Staging that runs SQLite while production runs Postgres proves nothing.
Key takeaways
- Config belongs outside the image, so one artifact runs everywhere.
- Prefer a few high-parity environments plus ephemeral previews.
- Validate config at startup, and fail fast.
- Feature flags decouple deploy from release. Delete them when the rollout is done.
- Dynamic config is a production control plane. Canary it, validate it, version it and audit it.
Further learning
Start with the first concept page, twelve-factor config, which explains why config stays out of the image.
Related
Deployment strategies and safe releases
Rolling, blue-green and canary deploys, automated rollback, and zero-downtime schema changes - ship often without betting the fleet on every commit.
Secrets management and encryption
Keeping credentials out of code and data safe at rest and in transit with KMS, Vault and envelope encryption — plus how to catch leaks before they become incidents.
A/B testing and experimentation
Designing randomized experiments, sizing samples with real arithmetic, reading lift and confidence intervals, and shipping only what the data actually supports.