Immutable infrastructure is the practice of never changing a running server in place. Instead of logging into a machine to patch, reconfigure, or update it, you build a fresh image or version with the change already baked in, deploy that new version, and discard the old one entirely. The running instance is treated as disposable: if something needs to change, you replace it rather than edit it.
HashiCorp’s Terraform documentation describes this approach directly. Terraform, it says, “takes an immutable approach to infrastructure, reducing the complexity of upgrading or modifying your services and infrastructure.” The docs give a concrete example: when you change a property of a virtual private cloud and adjust the number of virtual machines inside it, “Terraform will recreate the VPC before scaling the virtual machines” rather than mutating the existing one in place.
The central benefit is the elimination of configuration drift. When servers are modified by hand over months and years, each one accumulates a slightly different and undocumented state, and two machines that should be identical no longer are. With immutable infrastructure, every instance of a given version is built from the same image, so there is nothing to drift; reproducing a deployment means rebuilding from the same definition.
Containers and golden machine images are the natural embodiments of this idea. A container image is fixed once built and rolled out unchanged; to update an application you ship a new image and replace the running containers. Combined with infrastructure as code, immutability turns servers from carefully tended pets into interchangeable, rebuildable units.