We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · DevOps & CI/CD
Servers are never modified after deployment. To update, you build a new image and replace the old instance entirely. Eliminates configuration drift.
In short
Immutable infrastructure is an operations model where you never change a server after it is deployed. To ship a change, you build a brand new machine image with the change baked in, launch fresh instances from it, and throw the old ones away instead of patching them in place. This kills configuration drift because every running server is an exact copy of a known, version-controlled image.
In short
Immutable infrastructure is an operations model where you never change a server after it is deployed. To ship a change, you build a brand new machine image with the change baked in, launch fresh instances from it, and throw the old ones away instead of patching them in place. This kills configuration drift because every running server is an exact copy of a known, version-controlled image.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Immutable Infrastructure across a run of lessons, not one page. These 4 alone are about 64 minutes of step-by-step reading, every one with a quiz.
Never modify running systems, replace them entirely with new, tested versions.
Managing application and infrastructure configuration in version-controlled files instead of manual settings.
Detecting and preventing configuration drift, when reality slowly diverges from your declared infrastructure.
Tagging, semantic versioning, and immutable deployments for container images.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Immutable Infrastructurepay once,
yours for life
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. A Kubernetes Deployment does not patch its running Pods; 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.
Netflix (Spinnaker)
Bakes a versioned AMI per service release and deploys via red-black swaps into AWS autoscaling groups; running instances are never patched.
Docker
Container images are immutable by design; you build a new tagged image rather than editing layers in a running container.
Kubernetes
Never modifies a running Pod; a new Deployment revision launches fresh Pods from the new image and rolls out by replacement.
HashiCorp Packer and Terraform
Packer builds the immutable machine image; Terraform launches and replaces instances from it as code, with no in-place SSH edits.
Configuration drift is when servers that started identical slowly diverge because of manual edits, ad hoc patches, and one-off fixes applied over time. Immutable infrastructure stops it by forbidding in-place changes: every server is launched from the same version-controlled image and replaced rather than edited, so two instances from image v37 are guaranteed identical.
You keep state off the immutable instances. Databases run on managed services like Amazon RDS, files go to object storage like S3, and logs are shipped to a central system. The immutable servers stay stateless so that replacing them never loses data. State living on a server that gets rebuilt is the classic mistake.
No, but containers are the easiest way to do it. Immutable infrastructure is the principle of never modifying a deployed server. You can apply it with VM images and AMIs, no containers required. Containers just make it the default, since a Docker image cannot be edited once built and Kubernetes replaces Pods rather than patching them.
You bake the patch into a new image, build a new version, and roll the fleet over to it, terminating the unpatched instances. This is slower than SSHing in to run an update, but it guarantees every server actually got the patch and leaves a versioned, auditable trail of what changed.
A pet is a uniquely configured server you name and nurse back to health when it breaks. Cattle are numbered, interchangeable machines you replace instead of repair. Immutable infrastructure treats servers as cattle: when one is unhealthy or outdated, you destroy it and launch a fresh one from the image rather than logging in to fix it.
Docker
A platform for packaging applications into lightweight, portable containers. 'Works on my machine' becomes 'works everywhere.'
Infrastructure as Code
Managing servers, networks, and cloud resources through declarative configuration files instead of manual setup. Terraform, Pulumi, and CloudFormation are IaC tools.
Blue-Green Deployment
A deployment strategy using two identical environments. Traffic switches from blue (current) to green (new) instantly, with easy rollback.
CI/CD
Continuous Integration and Continuous Deployment: automating the process of testing and deploying code. Push code, tests run, and it ships to production automatically.
Canary Deployment
Rolling out a new version to a small percentage of users first, then gradually increasing. Like sending a canary into a coal mine to test for danger.
Rolling Deployment
Gradually replacing old instances with new ones, a few at a time. No downtime, but both versions run simultaneously during the rollout.
This page explains the idea. The "Immutable Infrastructure" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Immutable Infrastructure lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Immutable Infrastructure in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
