This is a single 'gitlab.example.com/docker/library' project. We use orphan branches, one per image, although other strategies are possible (like using the com

This is a single 'gitlab.example.com/docker/library' project. We use orphan branches, one per image, although other strategies are possible (like using the commit diff and directory name). Proxy images are versioned using branch names (e.g postgres vs postgres-9.6), images are pushed to gitlab.example.com/docker/library/postgres, and using version detection we generate docker image tags (e.g a 'postgres' branch will create postgres:latest, plus extracting version from postgres --version also pushes postgres:10 and postgres:10.1 images. See this .gitlab-ci.yml[0]. Yes, there is one per branch. This can be generalised further (especially with Gitlab's new import system for .gitlab-ci.yml) but works well enough in practice, it's very low maintenance, and updates are a mere commit+push away. In fact we use this not just for proxying images but for all "generalised", "utility", or "dependency" images that are not the result of a given full-blown app project in its own repo (those have their own CI/CD process in their respective repo) [0]: https://gitlab.com/snippets/1705998 https://gitlab.com/snippets/1705998