Skip to content

Immutable infrastructure

Immutable infrastructure is the practice of never changing a server after it is deployed. To patch, upgrade, or reconfigure, you build a new image, deploy new instances from it, and destroy the old ones. Nothing is updated in place.

The problem it solves is configuration drift. When servers are modified in place — a hotfix here, a manual package install there — the fleet slowly diverges, and each machine accumulates a history nobody has recorded. Eventually no two servers are quite the same, “works on that box” becomes a real diagnosis, and rebuilding a server exactly is impossible. Immutability removes the mechanism: if instances are never modified, they cannot drift.

It also makes rollback ordinary. The previous image still exists, so reverting is a deployment rather than an act of reconstruction.

The tradeoffs are real. Every change — including a one-line config edit — requires an image build and a replacement cycle, which is why the practice depends on that build being automated and reasonably fast. State has to live somewhere that survives instance replacement, which forces a discipline about what belongs on a server at all. And the image itself becomes a critical artifact: a fleet built on a golden image is only as current as its last rebuild.

Machine-readable:/glossary/immutable-infrastructure.md

Get started now.

Request access, describe the image you want, and have your first hardened image in about 15 minutes — a typical estimate, before publishing to your clouds. Primcoat builds, hardens, scans, signs, and publishes it, on the operating systems you already run.