Immutable Infrastructure, Explained

Immutable infrastructure is an approach where servers, containers, and machine images are never modified after they’re deployed — instead, any change is shipped as a brand-new, versioned artifact that replaces the old one entirely. Nothing gets patched in place. If something needs to change, you build a new image, deploy it, and tear down the old instance.

The alternative it replaces

The older, “mutable” model treats a server like a pet you maintain: you SSH in, apply a patch, install a dependency update, tweak a config file, and the server keeps running with an accumulating history of manual changes. Over time, two servers that were provisioned identically drift apart — one has a patch the other doesn’t, one has a stray config edit nobody documented. This is configuration drift, and it’s the reason “it works on that server but not this one” bugs exist at all.

Immutable infrastructure eliminates drift by construction. If a running instance can’t be changed, it can’t drift — the only way to get a different instance is to build a new image from a known, versioned definition, deploy it, and replace the old one. Every instance running a given version is, by definition, identical.

What it actually looks like in practice

The mechanics vary by layer, but the pattern is consistent:

• Machine images. Instead of patching a running VM, you build a new image (with the OS patch, dependency update, or config change baked in), version it, and roll it out by replacing instances — not editing them.
• Containers. A container image is inherently immutable once built; you don’t patch a running container’s filesystem in a way that persists — you build a new image and redeploy. This is part of why containers made the immutable model so much more common; see Docker for beginners for the container fundamentals this builds on.
• Infrastructure as code. Tools like Terraform describe the desired infrastructure state in version-controlled files. A change to the file produces a plan to create new resources and destroy old ones, rather than an in-place edit — the infrastructure itself becomes as versioned and reproducible as application code, which is the core idea behind GitOps.

How rollouts work without in-place changes

If you can’t patch an instance, deploying a change means running old and new versions side by side, then shifting traffic. This is exactly what blue-green and canary deployments are built for: blue-green stands up the new version fully alongside the old and switches traffic over at once; canary shifts traffic gradually while watching for regressions. Both patterns assume the new version is a complete, independent replacement — not a patch applied to what’s already running — which is the same assumption immutable infrastructure makes at the instance level.

Kubernetes deployments follow the identical logic one layer up: a rolling update doesn’t modify running pods, it creates new pods from the updated image and terminates old ones once the new ones are healthy.

Immutable vs. mutable infrastructure

	Immutable infrastructure	Mutable infrastructure
How changes ship	New versioned artifact replaces the old	In-place edits (SSH, config management)
Configuration drift	Not possible by construction	Common over time
Rollback	Redeploy the previous known-good artifact	Manually reverse changes, often incomplete
Reproducibility	Every instance from a given version is identical	Instances can diverge
Debugging “works here, not there”	Rare — instances are identical	A recurring class of bug

The trade-offs

Immutable infrastructure isn’t free. Building and deploying a whole new image for a one-line config change is more overhead than editing a file over SSH, and it requires tooling — image pipelines, orchestration, load balancers that can shift traffic — that a small, low-stakes system might not need. It also assumes state lives outside the instance (in a database, object storage, or a managed cache) since anything written to a replaced instance’s local disk is gone. That separation of state from compute is itself a broader shift in how platform engineering teams design systems: instances become disposable, and durability is somebody else’s problem — a database, not the box running your app.

The payoff is that a whole category of production incidents — drift, “someone changed something and forgot,” unreproducible environments — stops being possible, because there’s no in-place state to drift from. Combined with feature flags for behavior changes that don’t need a redeploy at all, teams get two separate, composable tools: flags for toggling behavior, immutable deploys for shipping code and infrastructure changes.

The takeaway

Immutable infrastructure trades the convenience of patching a running server for the reliability of never having to trust that a running server matches its definition. Every change becomes a new artifact, deployed as a replacement rather than an edit, which is what makes rollbacks, reproducibility, and drift-free environments possible in the first place. The cost is more upfront tooling — image pipelines, orchestration, traffic-shifting deploys — but it’s the same trade every layer of modern infrastructure, from containers to Kubernetes rollouts, has converged on for the same reason.