What Is Immutable Infrastructure?

Immutable infrastructure means servers are never modified after deployment. A change of any kind — a patch, a configuration adjustment, a new application version — produces a new instance from a new image, and the old one is destroyed rather than updated.

It began as an operational discipline aimed at reproducibility, and it turns out to have substantial security consequences that are worth understanding on their own terms.

Why it helps security

Configuration drift disappears. Systems cannot diverge from their intended state if they are never changed, which removes the gap between what your documentation says and what is actually running — a gap that ordinarily grows for as long as a server exists.

Persistence becomes hard. An attacker who establishes a foothold on an instance loses it when that instance is replaced. Where replacement happens regularly, maintaining access requires re-compromising continually or finding a way into the image pipeline itself.

Patching becomes a deployment. Instead of running updates across a fleet and hoping they applied uniformly, you rebuild the image and roll it out through the same mechanism as any other change — with the same testing and the same rollback.

Forensics improve. A compromised instance can be isolated and preserved intact while a fresh one takes over, so investigation does not compete with restoring service.

Where the risk relocates

None of this removes risk; it moves it into the image pipeline. That pipeline now determines what runs everywhere, which makes it the highest-value target in the architecture and the place where build integrity, signing and access control genuinely matter.

A vulnerability baked into a base image is also reproduced across every instance built from it, so rebuild cadence becomes a security control in its own right. An organisation that rebuilds images quarterly is running quarterly-old vulnerabilities everywhere, uniformly.

The practical constraint

Not everything is stateless, and the discipline requires state to live somewhere that survives replacement — managed databases, object storage, external session stores. Retrofitting that onto an application that writes to local disk is often the real cost of adopting the model.

Emergency changes are the other friction point. When something breaks at three in the morning, the instinct is to log in and fix it, and in an immutable model that fix vanishes at the next deployment. A documented break-glass path that ends in a rebuild prevents the quiet abandonment of the model under pressure.

Golden images and the pipeline that maintains them

The practice depends on a small set of maintained base images that everything else builds from. Where that set is not curated, teams build from whatever public image they found, and the estate acquires the inconsistency the model was meant to remove.

A golden image pipeline — rebuilding approved bases on a schedule, scanning them, signing them and publishing them into your own registry — is the machinery that makes immutability work at scale. It also becomes the single place a vulnerability gets fixed for every downstream consumer.

Treat that pipeline as production infrastructure with corresponding access control. Whoever can publish a golden image can determine what runs on every instance built from it, which makes it one of the most privileged capabilities in the organisation and one of the least frequently reviewed.

Where to start

Find out how old the oldest running instance in your estate is. In an immutable model that number should be small, and where it is not, you have mutable infrastructure regardless of how it was designed.

See cloud security best practices. GuardsArm runs cloud security assessments.