Understanding interals of docker dependency proxy

We want to use the dockerhub dependency proxy (on our self-hosted gitlab) to avoid problems with the docker rate limit.
We have projects in different groups that regularly pull the same images from dockerhub. Concerning the rate limit, does it make a difference, if I force all my projects to use the dependency proxy associated with one fixed group?

Technically phrased: Is there actually one cache for docker images per group or is there one cache for docker images for the whole gitlab instance and the groups only manage access to those images and to the knowledge which group was used to pull certain images?

Hello,

You’re on the right track with using the GitLab dependency proxy to address Docker Hub rate limits. Here’s how it works concerning groups and caching:

Caching Mechanism:

The GitLab dependency proxy uses a single, unified cache for Docker images across your entire GitLab instance. This means there’s not a separate cache per group.

Group Management:

Groups control access to images in the cache, not the physical location of the cached image.
A project in one group can leverage images pulled by another group, as long as the project has the necessary permissions (pull access) to that image in the dependency proxy.
Benefits of Single Cache:

Efficiency: Reduces redundant pulls from Docker Hub for the same images across projects.
Reduced Rate Limit Issues: Mitigates hitting rate limits by utilizing the cached images.
How Project-Group Relationship Works:

Project Pulls Image: When a project attempts to pull an image, the dependency proxy first checks its cache.

Cache Hit: If the image exists in the cache, the project can use it directly without contacting Docker Hub.

Cache Miss and Pull: If the image is not in the cache, the dependency proxy fetches it from Docker Hub and stores it in the central cache.

This initial pull might count towards the Docker Hub rate limit depending on your authentication status.

Group Permissions: Other projects within authorized groups can then access the image from the cache without additional Docker Hub interaction.