WSS
On this page
Infrastructure & ProvisioningRecommendedUpdated

Immutable infrastructure

The practice of replacing infrastructure components entirely rather than modifying them in place, guaranteeing consistency and eliminating configuration drift.

Reference Card

  • Origin/Prior Art: Chad Fowler (2013).
  • Related Practices: Containers, Machine images, Blue-Green deployments.
  • Key Concepts: Bake vs Fry, Replacement over modification, Disposable components.
  • Primary Failure Modes: Slow build times, Stateful data loss, Image bloat.

Introduction

Immutable infrastructure dictates that servers and components are never modified after deployment. If a change is needed - whether it is a security patch, a configuration update, or a new application version - the existing instance is destroyed and a new one is provisioned from a fresh image. This strictly enforces consistency across environments and completely eliminates configuration drift.

Mental Model

Traditional infrastructure acts like a pet. It is nurtured, updated, named, and patched over time. If it gets sick, an operator logs in and carefully nurses it back to health. This mutable approach leads to unique snowflakes: servers that are impossible to perfectly reproduce.

Immutable infrastructure treats servers like cattle. They are identical, disposable, and easily replaced. If a component fails or requires an update, it is not repaired. It is terminated and instantly replaced by a cloned replica built from a known-good template.

Operational Pattern

Immutable deployments rely heavily on the “bake vs. fry” concept.

Frying (mutable) means provisioning a bare server and running configuration management scripts (like Ansible or Chef) against it at boot time to install software.

Baking (immutable) means running those scripts during a build pipeline to create a static, read-only template (an AMI, a Docker image, or a VM snapshot).

  1. A configuration tool builds a machine image or container containing the OS, dependencies, and application code.
  2. The pipeline pushes this baked image into a central registry.
  3. The deployment orchestration system launches new instances exclusively from this exact image.
  4. The application handles live traffic.
  5. A new version requires triggering the pipeline to build a completely new image. The orchestration system replaces the running instances with the new image, often using rolling updates or blue-green deployment patterns.

Failure Modes

Long Feedback Loops

Building new machine images for every small change takes significant time. If the pipeline takes forty-five minutes to bake an Amazon Machine Image (AMI), this slows down the development cycle dramatically. Teams working with immutable patterns must aggressively optimize their build pipelines to keep feedback loops tight.

Persistent Data Mishandling

Storing data locally on an immutable instance causes permanent data loss upon replacement. Databases, user uploads, and critical log files must never reside on the ephemeral instance storage. They must exist on separate, persistent volumes, external block storage, or managed cloud services.

Image Bloat

Continuously building new images without a lifecycle policy leads to massive storage costs in the artifact registry. Registries become cluttered with thousands of gigabytes of obsolete images.

Security

Immutable components drastically reduce the attack surface. An attacker attempting to persist malware, install a backdoor, or modify system binaries faces a hostile environment because the entire instance is regularly destroyed and replaced.

In strict immutable environments, SSH access is disabled entirely. Because the server will never be patched or repaired interactively, there is no legitimate operational reason for a human to log into it. This eliminates an entire category of credential theft and privilege escalation vectors.

Operational Guidance

Separate application code from the base operating system image to improve build speeds. Build a “golden base image” on a monthly schedule containing security updates, monitoring daemons, and common tooling. Layer the fast-changing application code on top of this pre-baked base image to speed up the final deployment step.

Design applications to boot quickly. Because immutable infrastructure relies on constantly spinning up new instances for scaling and deployment, applications that take five minutes to start will cripple the responsiveness of autoscaling groups.

Diagnostics

When an immutable instance fails, do not troubleshoot it interactively. Do not attempt to restart the daemon or clear the disk space manually. Terminate the instance. The orchestration system will launch a fresh replacement.

If the new instance also fails immediately, the problem lies within the baked image itself, the external environment (like a database outage), or a misconfigured environment variable passed at boot. Pull the image locally and inspect it, or rely on centralized structured logging to diagnose the failure without accessing the live server.

Related topics

Sources & further reading