In software delivery pipelines, teams depend on registries to store and distribute artifacts such as Docker images, packages, and binaries. As organizations grow, the number of these registries, and the traffic flowing through them, can become a bottleneck for builds, deployments, and developer productivity in general.
Let’s look at how registries and repositories work, and what happens when you try to scale them.
Docker provides a concise definition of the difference between a registry and a repository (see Docker’s documentation):
This model applies to many artifact types beyond Docker images. Registries such as JFrog Artifactory, Sonatype Nexus, and Cloudsmith are often described as Universal Repository Managers because they host repositories for multiple formats. Container images, Maven packages, npm modules, and more, all under a single access control and management layer.
A Virtual Repository adds another layer of abstraction. It’s a logical grouping of repositories that appear as a single endpoint. Artifacts in a virtual repository are typically of the same type, and can come from both public and private sources. Administrators use this to unify access, simplify URLs, and apply custom access rules. Platforms like Artifactory, Nexus, and Google Artifact Registry all support virtual repositories for exactly this reason.
While universal repository managers centralize control, that same centralization can create operational pain. If one CI/CD job starts pulling large Docker images, other teams might see their Maven or npm downloads slow down. The bottleneck is usually the database behind the registry. Scaling it horizontally is difficult, and distributing it across regions introduces even more complexity.
Even with horizontal scaling in place, the registry often remains a logical single point of failure. To achieve redundancy across regions, you’d need to replicate entire registries and keep them in sync, which can be a costly and error-prone process.
All registries have a breaking point at which it becomes impractical to scale due to complexity and cost. This is why public registries like DockerHub tend to have strict rate limits and why it is so hard to create a universal repository manager that can scale to meet the needs of large organizations.
A Virtual Registry Manager addresses these limitations by decoupling registry access from the registry itself.
It functions like a content delivery network (CDN) for registries, caching and serving artifacts close to where they’re needed, which could be inside a build cluster, on-prem, or at a remote office. There’s no central database to scale or replicate. The system can run on any Linux host, forming a distributed, redundant layer in front of existing registries.
When operating in front of a private registry, a Virtual Registry Manager doesn’t bypass security. Instead, it delegates access control to the origin registry by querying it for user permissions before serving any cached content. This preserves existing security policies while offloading most of the traffic from the origin.
Just as a virtual repository presents multiple repositories as a single repository, a Virtual Registry presents multiple registries as a single logical registry.
This enables several key capabilities:
The result is a faster and more resilient artifact delivery layer that scales vertically, horizontally, and geographically without redesigning the core registry infrastructure.
The concept of a Virtual Registry is starting to gain traction, and as build systems, CI/CD pipelines, and software supply chains become more distributed, the need for high-performance, vendor-neutral registry acceleration will only increase.
Varnish Artifact Delivery applies these same principles using the Varnish caching engine as the foundation for a Virtual Registry Manager. Varnish already excels at high-throughput, low-latency content delivery. By extending that model to registries and build artifacts, it provides a distributed caching layer that sits transparently in front of systems like Artifactory, Nexus, GitHub Packages, and container registries. Deployed near CI/CD runners or within private networks, Varnish can:
In this role, Varnish becomes a Virtual Registry Manager: a scalable, redundant, cache-aware layer that brings artifact delivery closer to where the work happens. It complements existing repository managers rather than replacing them, ensuring that build and deployment processes stay fast, efficient, and secure, regardless of where teams or workloads are located.