Immutable Infrastructure

Immutable infrastructure is an approach where a deployed server, VM or container is treated as read-only. To update software or configuration, you build a new image, launch fresh instances from it and retire the old ones, instead of patching in place.

Why it matters

Because instances are replaced rather than edited, they cannot drift, and every server in a pool is identical and reproducible from versioned code. Rollback becomes simple: redeploy the previous image. Failures during upgrades are less likely to leave a machine half-changed. The cost is a build pipeline, a place to keep images, and a need to store state such as databases and uploads outside the replaceable instances.

Example

A rolling replacement of web servers behind a load balancer:

1. Build image web-2026-10-08 from the repository.
2. Launch new instances and wait for health checks to pass.
3. Add them to the load balancer, then drain and terminate the old ones.

If errors rise, point the group back at the previous image ID.

Common mistakes

• Logging in over SSH to fix production, which breaks the model.
• Baking secrets into images.
• Storing user uploads or session data on instance disks that vanish at replacement.

Related

• Config drift
• Infrastructure as code
• Rolling deployment
• Rollback

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.