Advantages of storing configuration in container registries rather than git
Storing configuration files and packages in git is pretty common. Sometimes they are committed alongside source code, sometimes they are stored alongside other configuration packages, and sometimes they live in their own repositories.
Storing deployment configuration with source code initially seems convenient, but leads to a number of challenges at deployment time, such as coupling permissions and git triggers for source and configuration, conflicting branching and promotion strategies across environments, orchestrating multi-component deployments, and so on. When storing configuration on its own, the toil of performing edits to configuration in git becomes more obvious: clone, branch, edit, add, commit, push, create change request, review, merge, tag.
Either way, in order to deploy a bundle of configuration files, such as with helm, it is sometimes copied to an object store, artifact registry, or container registry, typically from a CI process, but automatic builds or mirroring might also be possible in some cases. Such repositories meet scalability, performance, reliability, network access, security, and data residency requirements of production deployment systems, and especially useful for certain scenarios, such as edge deployments. Images can be also cached, replicated, and distributed peer to peer.
