Immutable infrastructure means servers are never modified after deployment. Need a config change? Build a new image, deploy new instances, terminate the old ones. No SSH-ing in to tweak nginx.conf. No apt-get upgrade on running boxes. No hotfix scripts. The running server is a read-only artifact.

The alternative — mutable infrastructure — accumulates drift. Server A got a manual firewall rule at 2am during an incident. Server B has an older OpenSSL because the patch script failed silently. Server C has a leftover debug flag from last quarter's investigation. Six months in, "identical" servers behave differently, and nobody knows why. Configuration management tools (Puppet, Chef, Ansible) tried to solve this by converging state, but convergence assumes the starting state is knowable. Often it isn't.

How it works in practice:

• Bake artifacts: Packer builds an AMI, or Docker builds an image, with everything baked in — OS, runtime, app, config.
• Deploy fresh: Launch new instances from the artifact. Never edit them.
• Replace, don't repair: A broken instance gets terminated and replaced, not debugged in place.
• Version everything: Every image is tagged. Rollback = redeploy the previous tag.

Real example: Netflix's Aminator pipeline bakes an AMI for every deploy. When a service scales up, ASG launches instances from the current AMI — no bootstrap scripts running yum install at boot (which would be slow and could fail if a mirror is down). Deploys are AMI swaps. Rollbacks are AMI swaps in the other direction. No server lives longer than a deploy cycle.

The rule of thumb — the "cattle, not pets" test: If you know your server's hostname by heart, or you'd hesitate to terminate it because "that one's special," you have pets. Aim for servers you can kill without a second thought. A healthy fleet should tolerate random termination of any instance with zero human involvement (this is literally what Chaos Monkey verifies).

The tradeoffs: Build times get longer (every change = full image bake). State must move somewhere persistent (databases, object storage, external volumes) — the server itself holds nothing valuable. Debugging shifts from "SSH in and poke" to "reproduce locally or in a sacrificial instance" — some engineers find this jarring at first.

When it doesn't fit: Bare-metal environments where provisioning takes hours. Stateful systems where the local disk is the product (some databases). Dev environments where fast iteration beats reproducibility. But for stateless web services on cloud infrastructure, mutable servers are a legacy habit, not a requirement.