Don't Panic — Immutable Infrastructure

Immutable infrastructure is the rule that says a running production resource is not a pet project with a screwdriver drawer. When it needs to change, you build a new version and replace the old one. This sounds severe until you meet the alternative: a server that has collected patches, manual fixes, and one mysterious exception made at 02:13 by someone who was probably very tired.

The important trick is that immutable does not mean frozen. The system changes all the time. The change happens in the source definition, image recipe, and deployment configuration, then travels through a build and test path before it reaches production. The running resource gets to be boring. Boring is a fine career for a server.

The first idea to keep is configuration drift, the difference between what a resource was supposed to be and what it has become. Replacing from reviewed inputs limits that accumulation. It also gives a more useful answer to “what is running?”: an artifact identifier, source revision, and evidence, rather than an archaeological dig through shell history.

The second idea is the state boundary. Compute can be disposable; required data cannot. Database records, uploaded files, useful logs, and controlled configuration need a life outside the resource that runs the application. If deleting one instance loses something required, that instance is not yet a safe candidate for replacement. The vocabulary may sound grand. The test is usefully blunt.

The third idea is that replacement needs a recovery path. A blue-green deployment keeps a parallel candidate environment before traffic moves. A canary deployment gives a candidate a small share of traffic first. Both methods buy time to look at health evidence. Neither rewinds an incompatible data change by magic, because magic has an alarming record with database schemas.

This model moves authority into the delivery pipeline. That makes the pipeline worth protecting: its credentials, definitions, scans, and deployment records now decide what production becomes. Exceptional break-glass access still has a place, but its fix needs to return to the source definition or the next replacement politely removes it.

Read the Intro when you need the full replacement loop and the line between durable state and replaceable compute. Use Slides for the flow and rollout comparison. Keep the Cheatsheet nearby when designing a health gate, evidence record, or recovery decision. The Practice Reference turns those ideas into a planning method, and the Exercise lets you test the method without introducing a surprise bill or a surprise outage.