Immutable infrastructure is a modern paradigm where servers and components are replaced entirely rather than modified in-place after initial deployment. This eliminates configuration drift, increases deployment reliability, and ensures consistency across environments by treating infrastructure as disposable, versioned artifacts rebuilt from scratch for every change. The "cattle not pets" philosophy and the phoenix server pattern form its philosophical foundation, while containerization, Infrastructure as Code, and GitOps provide the practical tooling. In 2026, immutable principles extend from cloud VMs to purpose-built immutable operating systems like Talos Linux, to WebAssembly at the edge — making this approach central to secure, auditable, cloud-native operations.
What This Cheat Sheet Covers
This topic spans 21 focused tables and 229 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Principles and Philosophy
The mental model of immutability is as important as the tooling — understanding why you replace instead of modify changes how you design every pipeline, image, and deployment. These foundational concepts are the shared vocabulary of the entire discipline.
| Concept | Example | Description |
|---|---|---|
aws ec2 run-instances --image-id ami-0abcdef1234567890 | • Server that once deployed is never modified • all changes require a full replacement | |
Regular full rebuilds from base images on a schedule | Server rises from ashes at each deployment, preventing accumulated drift | |
Named srv-prod-01 (pet) vs autoscaled instances (cattle) | • Pets are individually maintained and irreplaceable • cattle are interchangeable, replaced when unhealthy | |
Untracked apt-get install or manual firewall rule on production | Silent divergence from desired state that immutability structurally prevents | |
Pre-baked AMI with Nginx vs apt-get install nginx at boot | • Baking embeds config into image at build time • frying applies config at runtime (mutable) | |
Terraform/OpenTofu HCL describing desired state | • Describe what should exist, not how to create it • tooling resolves the difference |