Immutable Infrastructure

The opposite of immutable infrastructure is the traditional mutable server: you SSH in, run apt-get upgrade, edit a config file, restart a service, and the box keeps running. Over months, every server accumulates a slightly different set of hand-applied changes. Two machines that started identical are now subtly different, and nobody can say exactly how. That difference is called configuration drift, and it is the reason for a huge share of "works on that box but not this one" outages.

Immutable infrastructure bans the in-place edit. A server, once running, is treated as read-only. When you need a new version of your app, a security patch, or a config change, you do not touch the live machine. You build a new image (an AMI, a container image, a VM template) that already contains the change, launch new instances from it, shift traffic over, and terminate the old instances.

The phrase people use is "cattle, not pets." A pet has a name, you nurse it back to health when it gets sick. Cattle are numbered, and a sick one is replaced, not treated. Immutable servers are cattle: disposable, interchangeable, and rebuilt from a recipe rather than repaired.

The pipeline has three repeatable steps: build an image, deploy instances from it, and replace the old fleet. The build step is usually done with a tool like Packer or a Dockerfile. You start from a base image, install your dependencies and application, and produce a single artifact with a version tag. That artifact is immutable: image v37 will always contain exactly what it contained the day it was built.

Deployment launches instances from that image. Because the image is fully baked, boot time is short and there is no install step that can fail halfway. Tools like Terraform describe the desired set of instances, and an autoscaling group or Kubernetes Deployment keeps that count alive. If an instance dies, the platform launches a fresh copy from the same image with no manual intervention.

Replacement is where the safety comes from. Instead of upgrading the running fleet, you stand up a parallel fleet from the new image and cut traffic over. A blue-green deployment runs both fleets and flips a load balancer. A rolling update replaces instances a few at a time. If the new image is broken, rollback is just pointing traffic back at the old image, which still exists, rather than trying to undo a tangle of in-place edits.

Immutable infrastructure shines when you deploy often and run many identical machines: stateless web servers, API workers, container fleets. It gives you reproducible environments, trivial rollback, and confidence that staging matches production because both came from the same image. It also raises your security posture, because long-lived servers that never get rebuilt are where unpatched vulnerabilities and forgotten backdoors live.

The cost is up front. You need a real build pipeline, image storage, and the discipline to put every change in code rather than typing it into a terminal. Builds and replacements are slower than a one-line SSH edit, so a tiny hotfix now means rebuild, redeploy, and reboot rather than a quick patch. For a single hand-tuned server this overhead is rarely worth it.

The biggest catch is state. Anything that must survive a replacement, such as databases, uploaded files, and logs, cannot live on the immutable instance. You push that state outside: managed databases like RDS, object storage like S3, and centralized logging. Get this wrong and you delete a customer's data every time you redeploy.

Netflix is the canonical example. Their internal tool Spinnaker bakes a fully configured Amazon Machine Image for every service version, then deploys it into AWS autoscaling groups using a red-black (their name for blue-green) strategy. Nobody patches a running Netflix instance. A new version is a new AMI, a new set of instances, and a traffic flip, with rollback being a flip back to the previous AMI.

The container world makes this the default. A Docker image is immutable by design: you cannot edit a layer once it is built, you build a new tagged image. Kubernetes never patches a running Pod; a new Deployment revision creates new Pods from the new image and terminates the old ones in a rolling update. The immutability is baked into the platform, which is part of why containers spread so fast.