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, 155 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
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 | ||
Running terraform apply twice produces the same result | • Operations safely repeatable without side effects • critical for automated pipelines | ||
my-app:v2.3.1, ami-name-20260528 | Every artifact is versioned, enabling rollback and reproducibility | ||
Production server configured over years with undocumented manual changes | Anti-pattern: unique, fragile server impossible to reproduce or replace safely | ||
Talos Linux managed entirely via API; no SSH | Manage infrastructure through versioned API calls rather than interactive shell access | ||
Kubernetes pods terminated and recreated on any update | • Treat every instance as ephemeral • state lives externally, compute is disposable |