Immutable Infrastructure

The pattern: never modify a running server in place. To deploy a change, build a new artifact (container image, AMI, OS image), spin up new instances, drain the old, decommission. Containers + Kubernetes make this the default. Talos Linux pushes the OS itself toward immutability — no SSH, no ad-hoc edits, the API is the only entry point.

The trade-off: debug ergonomics vs. drift elimination. Mutable systems are easier to “fix in place” — but you accumulate drift between machines, hidden config, ghost packages. Immutable systems force every change into code (Dockerfile, Packer template, NixOS config) — slower iteration, but every machine is identical to every other and reproducible from source. The debugging move shifts from “ssh and poke” to “rebuild the artifact and observe.”

Deepens in Year 1 Phase 6 (containerization from scratch — namespaces + cgroups + UnionFS) and Year 2 Phase 9: IaC (terralabs immutable AMIs via Packer).

Related patterns

• declarative-vs-imperative-infrastructure — declarative tooling is what makes immutable rolls cheap.
• gitops — image tags in git are how immutable artifacts get promoted.
• progressive-delivery — canary/blue-green only work because instances are interchangeable.
• defense-in-depth — short-lived, rebuilt instances shrink the window for persistent compromise.
• three-pillars-and-unified-telemetry — when you cannot ssh, telemetry is the only debugger you have.
• Phase 9: IaC and basecamp — where immutable artifacts become the platform default.