> don't routine security updates mean you're constantly rebuilding and redeploying these images? Yes and no; yes, because you should be rebuilding upon upstrea

> don't routine security updates mean you're constantly rebuilding and redeploying these images? Yes and no; yes, because you should be rebuilding upon upstream changes, but no, because there will be fewer upstream changes. You can reduce the amount of software that is baked into a Docker image, compared to a full traditional distribution, thus reducing your attack surface and reducing the frequency with which the image needs to be rebuilt. > And if so, how is that more efficient than just using Puppet / Chef / Ansible and a 'real' server? "Real" servers are always (exception: NixOS) stateful, even if they are only used to host stateless services. Uninstalled packages leave behind old service users, buggy packages depend on specific user/group IDs that conflict in production but not where they were built, conflicting ports that are already bound. Designing for immutable infrastructure makes it easier to reason about state in production and therefore makes production easier to manage.