Immutable Infrastructure

Immutable infrastructure is the practice of never modifying a running server, container or image after it is deployed. A change means building a new artifact and replacing the old one; patching in place is not allowed even when it would be faster. The reason is not aesthetic. A machine that has been modified over months carries a configuration nobody can reproduce, because the current state is the sum of an original image plus every hotfix, package upgrade and manual edit applied since, in an order nobody recorded. That is how two servers behind the same load balancer come to behave differently, and how a problem reproduces on one and not the other. Replacing rather than patching makes three things true. Deployment and recovery become the same operation, so the path used to roll forward is exercised constantly and works when it is needed to roll back. The identical artifact runs in staging and production, which removes a whole class of it-worked-in-staging failures. And rollback becomes redeploying the previous artifact rather than reversing a series of changes, which is far more reliable because nobody has to know what the changes were. The costs are real and worth naming. Any state that must survive has to live somewhere else, in a database, object storage or a mounted volume, which is a design constraint rather than a detail. Replacement cycles are slower than editing a file, so an urgent fix takes a build. And debugging changes character: you cannot log into a box and poke at it over days, so logs, metrics and traces have to be good enough to diagnose from outside, and a machine kept alive for investigation should be pulled out of service rather than left serving traffic.