Immutable Infrastructure

In Turkish: Değiştirilemez Altyapı

Updated September 30, 20262 min read

In short

Immutable infrastructure is an approach where servers are never changed after deployment; every update replaces them with new, freshly built ones.

What is immutable infrastructure?

Immutable infrastructure means that once a server, virtual machine, or container is deployed, nobody modifies it. There are no in-place package upgrades, configuration edits, or quick fixes over SSH. When something needs to change, whether a security patch, a new app version, or a setting, the team builds a new image, deploys fresh instances from it, and destroys the old ones.

The process starts with an image, such as a container image or a virtual machine image, built automatically by a CI pipeline from files kept in version control. That exact image is tested and then promoted unchanged from staging to production, so what was tested is exactly what runs. Because every instance comes from the same image, there is no configuration drift, the slow divergence that happens when servers are patched by hand over months, and a rollback is as simple as redeploying the previous image.

A popular comparison is pets versus cattle: a mutable server is a pet that is nursed back to health when it gets sick, while immutable servers are cattle that are replaced without ceremony. Containers made this style the default, since Kubernetes replaces pods rather than editing them, and the same idea works with virtual machines behind autoscaling groups. Persistent data, such as databases and uploaded files, must live outside the replaceable instances, in managed databases or object storage, or it would be lost on every deployment.

Immutable infrastructure is often confused with infrastructure as code. Infrastructure as code describes infrastructure in files, and those files can be used either to replace servers or to modify them in place; immutable infrastructure is the decision to always replace. It also contrasts with traditional configuration management, where tools connect to long-lived servers and update them to match a desired state.

Key takeaways

Servers and containers are never modified after they are deployed.
Every change produces a new image, and old instances are replaced, not patched.
The same tested image moves unchanged through staging and production.
It eliminates configuration drift and makes rollbacks simple.
Persistent data must be stored outside the replaceable instances.

Example

Shipping a change by replacing, not patchingbash

# Build a new image for every change, tagged with its commit
docker build -t registry.example.com/web:3f9c2ab .
docker push registry.example.com/web:3f9c2ab

# Replace the running instances with the new image
kubectl set image deployment/web web=registry.example.com/web:3f9c2ab

# Rolling back means redeploying the previous, unchanged image
kubectl set image deployment/web web=registry.example.com/web:a71d0e4

Readers ask

What is the difference between mutable and immutable infrastructure?

With mutable infrastructure, servers live for a long time and are updated in place with patches and configuration changes. With immutable infrastructure, servers are never changed; each update replaces them with new instances built from a fresh image.

How do you fix a bug on an immutable server?

You don't edit the running server. You fix the code or configuration in version control, build a new image, and deploy it, which replaces the old instances; you can still debug a copy, but the fix always goes through the pipeline.

Is immutable infrastructure the same as using containers?

No, but containers make it easy. The approach also works with virtual machine images, and a container can still be treated as mutable if someone changes files inside it after it starts, which is discouraged.