"Entering" a server and running "apt dist-upgrade" probably means you've got a stateful fleet, because some package upgrade can fail, it can be performed at dif

"Entering" a server and running "apt dist-upgrade" probably means you've got a stateful fleet, because some package upgrade can fail, it can be performed at different time from one server to another, et cetera. Your servers should be cattle, not pet. So, you should instead create a sort of manifest/snapshot/checkpoint with all your deps pinned, and distribute that to your servers. You can do the same without containerization - you could use a fleet of machines and keep their versions pinned with a configuration management tool, but you'd still not want to manually perform an apt upgrade on your server. And manually "check that everything is fine and maybe reboot" to verify your new shared lib was loaded - you should already have a precise, reproducible, automated testing and upgrade procedure and just apply that. So, containerization is not the point here. Automation of deployment and testing procedures is. But the OP was specifically attacking containerization (as if it were the problem), and I was answering him. But, containerization is generally useful here, because the "container image" is, generally speaking, a good, well-defined artifact. So the OP's example was especially bad - telling "machine X is vulnerable to SSL bug Y" is hard, requires specific machine instance inspection: what happens if the process/server wasn't restarted and, even though package is updated, it's still using an old ssl version? On the contrary, "this is using container image version X with openssl version Y which is not vulnerable" is a very precise True/False statement, easy to inspect and verify at scale.