Varnish Virtual Registry Core

Modern software delivery no longer runs at human speed. CI/CD pipelines, Kubernetes clusters, build farms, AI agents, and GPU workloads pull dependencies, containers, source, and model assets continuously. Every install, container pull, and dependency update adds latency, saturates backends, and runs up cloud egress. The more concurrency and the larger the artifacts, the more pressure lands on the registries underneath. The usual answer is to scale the infrastructure beneath the traffic: a bigger Artifactory or Nexus, more backend capacity, more egress. Yet every pull still hits the backend. Latency, egress, and spend keep rising with demand.

Varnish Virtual Registry takes a different position. It sits in front of the registries you already run as a single, vendor-neutral access layer. Acceleration happens at the point of consumption: a cache lookup, a single upstream fetch, and repeated pulls served without touching the origin. Performance scales without the systems behind it. Control and resilience stay with you, not your repository vendor. It caches container layers, package files, binaries, Git LFS objects, and AI model artifacts, while revalidation keeps metadata, manifests, and indexes fresh. Private artifact traffic is accelerated without bypassing registry security: requests are validated against upstream authentication, and approved users share cached private artifacts. Varnish Virtual Registry does not bypass registry authentication, entitlements, or metering - it reduces the number of redundant requests your registry is asked to serve. In production, teams have seen 90%+ reductions in backend repository traffic, 50%+ lower server load, and 40%+ faster dependency resolution. The result is faster builds, lower cloud egress, and less backend infrastructure to scale. Deployed alongside Varnish Artifact Firewall, the same access layer can also enforce package policy at request time.

Virtual Registry works in front of JFrog Artifactory, Sonatype Nexus, Cloudsmith, GitHub Packages, GitLab Package Registry, Docker Hub, npm Registry, PyPI, Maven Central, Amazon ECR, Google Artifact Registry, Azure Container Registry, and S3-backed artifact stores, and it accelerates Docker/OCI images, Helm charts, npm, PyPI, Maven, NuGet, Cargo, Go modules, Ansible, Conan, Debian, RPM, Git, Git LFS, and other HTTP-delivered immutable assets.

This listing is the Core tier of Varnish Virtual Registry, designed for single-region deployments. It includes the complete caching, routing, and observability feature set, and covers 450 TB of delivered traffic per year in one region. The Core tier does not include cache clustering or failover between regions; both are available in the Pro and Enterprise tiers, along with additional regions, higher traffic entitlements, and Standard or Premium Support. To find the right fit for your workload, contact sales@varnish-software.com .

What counts as a region. A region is one place you run Virtual Registry to serve artifacts - an AWS region, another cloud region, a data centre, or a site. Run as many nodes in it as you need: node count is not limited and is not counted. Your Kubernetes and container clusters are not regions and are never counted separately. Additional regions are available in the Pro and Enterprise tiers, each bringing its own traffic entitlement.

How delivered traffic is measured. Delivered traffic is the volume of data Virtual Registry serves to your clients, measured on a trailing twelve months. Uploads, transfers between your own regions, and stored data are not counted, and there is no storage limit. Exceeding the entitlement does not interrupt or throttle service: it is reviewed at renewal and never billed retrospectively.