Patch in place when a system holds state, is slow to rebuild or cannot be replaced easily. Rebuild and redeploy when the system is stateless, built from code, and can be replaced from a fresh image. Rebuilding gives cleaner rollback and less drift. Patching in place is sometimes the only option.
Two approaches
Patch in place. Update packages on the running host, restart if needed. The host keeps its history.
Rebuild and redeploy. Build a new image with the updates, start new instances, shut old ones down. Nothing is modified after it ships.
Decision table
| Question | Points to in place | Points to rebuild |
|---|---|---|
| Does the host hold local state? | Yes | No |
| Is it created from code or an image? | No | Yes |
| How long to rebuild? | Many hours | Minutes |
| Is capacity redundant? | No | Yes |
| Do you need clean rollback? | Less important | Important |
| Is configuration drift a worry? | Low | High |
Why rebuilding often wins
An image has a version, so rollback is redeploying the previous one. Every instance is identical, so a patch applied to one is applied to all. There is little drift, since the host is never hand edited. Evidence is simple: the image digest and the deployment record show exactly what ran.
For containers this is the standard route. Docker's build guidance advises rebuilding images regularly with updated dependencies, and notes that --pull checks for a newer base image. Patching packages inside a running container is possible but does not survive a restart from the old image. See apt upgrade inside a container or rebuild the image.
When patching in place is right
- Databases and stateful stores with local data.
- Appliances and long lived servers with vendor managed update paths.
- Systems where a rebuild takes longer than the risk window allows.
- Edge cases in an incident where speed matters more than elegance.
Even then, snapshot first, patch a canary, restart on a plan, and verify the running version. NIST SP 800-40 Rev. 4 notes that routine patching interrupts operations through reboots, which is why windows and outage restrictions exist for such groups.
A hybrid pattern
Many teams rebuild stateless tiers and patch stateful ones in place, then work towards making the stateful ones easier to replace, for example by moving data to a managed service. Document which approach each maintenance group uses.
Where dependencies fit
Application dependencies follow the rebuild model almost always: change the lockfile, build, deploy. There is no in place option worth using, because editing installed libraries on a running server breaks the link between source and production.
Where Safeguard fits
Safeguard's container image scanning and SBOM generation help confirm what each rebuilt image contains. See what is a golden image.
Quick check
Is rebuilding always faster?
Not always on the first try. Once the pipeline exists, it usually is, and the result is more predictable.
Can I mix both approaches?
Yes, by maintenance group. Record the approach per group in your plan.
Sources
Last reviewed: 19 October 2026.
