Immutable Infrastructure
Immutable infrastructure replaces servers instead of patching them: every change produces a new image, and running instances are never modified in place, removing drift.
Definition
Immutable infrastructure is a model in which deployed instances are never modified after they start. Any change, from a security patch to a configuration tweak, is baked into a new image or artifact, and the old instances are replaced by new ones.
Context and scope
It fits teams running fleets of servers or containers that need reproducible builds, fast rollback, and freedom from configuration drift.
Common misconceptions
- Immutable means data is immutable — stateful data still lives in databases and volumes; only compute images are replaced.
- Containers are automatically immutable — a container that downloads dependencies at startup or mounts mutable config is not.
- You never debug a running server — you still inspect live instances, but you fix them by rebuilding, not editing.
Anti-patterns
- SSH-ing into production to patch a file and calling it a fix
- Baking secrets into images instead of injecting them at runtime
- Rebuilding images without pinning base images, so builds are not reproducible
Related concepts
Authoritative source
Replace, do not patch
The core rule is simple: once an instance starts serving, nobody edits it. Changes flow through the build pipeline into a new image, and the orchestrator replaces old instances with new ones. Because every instance of a version is identical, two servers that claim the same version actually are the same. Rollback means deploying the previous image, not reversing a series of manual edits.
commit -> build image (tag: sha) -> test -> deploy new instances -> drain old
Rollback: deploy previous image tagWhen to use it
Use immutable infrastructure for stateless services, autoscaling groups, and container platforms where instances are disposable. It shines when fleets are large, when compliance requires knowing exactly what runs, or when configuration drift has caused outages. For a single long-lived database server, full immutability is impractical; apply the idea to the compute layer around it.
Trade-offs
Image builds take time and need caching to stay fast. Stateful components require careful handling: volumes persist while compute is replaced. Debugging moves from editing files to reproducing the build. Teams also need image scanning and retention policies, or the registry becomes a graveyard.
Example and misconceptions
A team discovers a missing CA certificate in production. Instead of copying it onto twenty servers, they fix the Dockerfile, rebuild, and roll out. The fix is reviewable and repeatable. The common misconception is that immutability applies to data; it does not, databases remain stateful and need their own migration strategy. Related concepts: infrastructure as code, blue-green deployment, and rolling deployment.