Immutable infrastructure
Servers you never patch in place: to change anything, build a new image and replace the machine. No SSH surgery, no snowflake boxes.
See it
What it is
A server, once running, is never modified. Want a new package, a config change, or a security patch? You bake a fresh image, launch new instances from it, shift traffic over, and destroy the old ones. The phrase people use is 'cattle, not pets': machines get numbers, not names. Tooling: Packer or Dockerfiles to bake the image, Terraform or Kubernetes to replace what is running.
The payoff is that the running system matches something you can read in git, so configuration drift on your servers mostly stops happening. Nobody bothers hand-patching a box that gets destroyed next Tuesday. It does not vanish as a category of bug, though: clicks in the cloud console, mutable managed services, runtime config living in a dashboard, and a floating image tag that quietly points somewhere new all still drift out from under the file. Rollback becomes boring too: redeploy the previous image instead of reverse-engineering which hand-typed command broke the box at 2am. Containers made this the default, which is why most teams practice it now without ever naming it.
Gotcha: anything that must survive replacement has to live outside the machine, so local disk writes, uploaded files, and in-memory sessions move to managed databases, object storage, or attached volumes before this works. The other trap is emergency speed. If a one-line hotfix now requires a full image build, your pipeline has to be fast, or people will quietly SSH in anyway and you get the worst of both worlds.
Ask AI for it
Convert this deployment to immutable infrastructure. Bake the app and all its dependencies into a versioned container image tagged with the git SHA, move every runtime setting into environment variables and every piece of persistent state (uploads, sessions, sqlite files) out to managed storage, and replace in-place restarts with a rolling replacement of instances from the new image. Remove any deploy step that mutates a running server. Make rollback a redeploy of the previous image by its content digest, or by a tag the registry has been configured to keep immutable, since an ordinary tag can be moved and then 'the previous image' is whatever someone pushed last.