CONCEPT Cited by 1 source
Immutable infrastructure¶
Definition¶
Immutable infrastructure is the operational philosophy of never modifying deployed instances in place. Instead of patching, updating, or reconfiguring running servers, changes are delivered by building new images/artifacts and replacing existing instances entirely. The running instance is treated as a disposable, reproducible artifact — not a pet to be nursed.
Why it matters¶
- Eliminates configuration drift: Every instance matches its image exactly; no accumulation of ad-hoc changes over time.
- Reproducibility: Any instance can be rebuilt identically from its image definition.
- Simplified debugging: If an instance misbehaves, replace it rather than diagnosing accumulated state.
- Audit clarity: The fleet state is always deterministic — look at the image version, not the instance history.
The "semi-immutable" pragmatic exception¶
In practice, most immutable-infrastructure implementations have one exception: secrets and certificates. Slack's Shipyard explicitly documents this: Consul Template refreshes secrets from Vault dynamically, making the architecture "semi-immutable" — core system and service layers are fixed at bake time, but runtime credentials can be rotated without cycling the fleet (Source: sources/2026-07-14-slack-shipyard-next-generation-ec2-platform).
Key trade-offs¶
| Benefit | Cost |
|---|---|
| No drift | Longer deployment cycles (build new image per change) |
| Easy rollback (deploy previous image) | Larger storage footprint (image versions) |
| Deterministic fleet state | Need separate mechanism for secrets rotation |
| Simpler incident response (replace) | Long-lived instances (databases) require different patterns |
Seen in¶
- sources/2026-07-14-slack-shipyard-next-generation-ec2-platform — Shipyard's core philosophy: "treats infrastructure as deployable artifacts rather than endlessly mutable instances." Semi-immutable secrets exception explicitly documented.