Google Artifact Registry

What Google Artifact Registry actually is

Artifact Registry is Google Cloud's managed repository service for the artifacts your build pipeline produces and consumes: container images, language packages, and OS packages in one place. It is the successor to Container Registry, which Google shut down for writes on March 18, 2025 — every gcr.io project that has not migrated has already been forced onto Artifact Registry, which is one reason the service now anchors most GCP-based software delivery setups.

The service reached general availability on November 16, 2020, initially with container images plus Maven and npm repositories. Language repositories for Java, Node, and Python went GA in October 2021, and remote and virtual repositories followed on November 1, 2023. That last feature is the one we find most interesting operationally: a virtual repository fronts multiple upstreams (your own standard repos plus proxy caches of Docker Hub, Maven Central, npmjs, and others), so a single endpoint can serve an internal toolchain while caching external dependencies close to your builds. Remote proxying alone can justify the migration for teams that watch Docker Hub rate limits eat their CI time.

The format coverage is broad — Docker/OCI images, Maven, npm, Python, Go modules, RubyGems, and Debian and RPM packages — and everything sits under one set of IAM policies and one audit trail. Integration depth is the product's real strength: GKE pulls images from Artifact Registry without credential plumbing, Cloud Build pushes to it as a first-class step, Binary Authorization can gate deployments to signed images only, and VPC Service Controls can wrap the whole thing for regulated environments. Vulnerability scanning is built in for container images, and CMEK, per-repository IAM, and regional repositories have been standard since GA.

In our view this is a piece of infrastructure that is easy to underrate. Package management is unglamorous, but it sits directly in the software supply chain, and having identity, scanning, and deployment policy share one control plane with the rest of your cloud is worth more than any single feature.

Pricing: what you really pay

Artifact Registry bills for three things: storage, data transfer, and vulnerability scanning (the last one only if you enable it, priced under Artifact Analysis). Storage is $0.00 for the first 0.5 GiB per billing account per month, then $0.000136986 per GiB-hour, which works out to about $0.10 per GiB-month. The pricing is identical for regional and multi-regional repositories, and the free tier is aggregated per billing account, not per project — so twenty projects sharing one billing account share the same 0.5 GiB allowance.

Data transfer is where costs can surprise you, and the pricing page is worth reading in full. Inbound transfer is free. Traffic within the same location is free, as is region-to-multi-region traffic on the same continent. Cross-region traffic within the US and Canada is $0.01 per GiB, within Europe $0.02 per GiB, within Asia $0.05 per GiB, and between continents (excluding Oceania) $0.08 per GiB, with Oceania at $0.15 per GiB. Egress to the public internet follows Premium-tier network pricing. The practical rule Google itself recommends is simple: co-locate repositories with the runtimes that consume them, because a repository in us-east1 feeding a cluster in us-west1 bills $0.01 per GiB on every pull that misses a cache.

Vulnerability scanning is billed through Artifact Analysis when the Container Scanning API or On-Demand Scanning API is enabled — and note that enabling the API bills scanning across both Artifact Registry and Container Registry. There is no per-seat charge and no minimum commitment; new accounts get Google Cloud's standard $300 free credit. In absolute terms a small team's registry bill is usually cents per month. The bills that hurt are the ones with uncached cross-region pull traffic, which is a configuration problem more than a pricing problem.

Performance & infrastructure

Artifact Registry runs on Google Cloud's region fleet, and you can place repositories in any Google Cloud location — across North and South America, Europe, Asia, the Middle East, and Australia — or in multi-regional locations. That gives you the practical performance lever that matters for a registry: latency to pulls and push bandwidth. A regional repository next to your GKE cluster delivers images over the internal network with no internet egress, and Google's guidance to co-locate repositories with consumers exists precisely because pull latency and transfer cost both scale with distance.

Reliability is backed by Google's infrastructure rather than a dedicated Artifact Registry service level agreement — we could not find a published SLA specific to the product, which is worth noting for compliance-minded teams. Replication across regions is your responsibility via remote or standard repositories; there is no one-click cross-region replication switch. Operational controls are strong where they count: VPC Service Controls, CMEK, per-repository IAM conditions, audit logging, and Binary Authorization for deployment-time image attestation checks.

On support, you get Google Cloud's standard support tiers — paid plans with response-time commitments, community and documentation support otherwise. The documentation is extensive and generally accurate, and the migration tooling from Container Registry (including gcr.io domain support in Artifact Registry) has matured to the point where the transition is mostly a configuration change. We find the format documentation and IAM examples particularly well done; the pricing documentation is thorough but scattered across the Artifact Analysis pages for scanning.

Where it falls short

The first constraint is the obvious one: this is a Google Cloud product with Google Cloud identity, billing, and IAM welded in. You can serve images to external consumers and run remote repos against outside registries, but the management plane lives in GCP. If your organization is multi-cloud by policy, a neutral registry (Harbor, Artifactory, GitHub Packages, GitLab) keeps your options wider. Even the gcr.io compatibility story only helps if you were already in the Google ecosystem.

Second, the billing model has two axes that interact, and the second one is invisible at setup time. Storage is cheap and predictable; data transfer depends entirely on where your repositories and consumers sit. Teams that spread repositories casually across regions can turn a cents-per-month product into a noticeable line item without any change in behavior. The mitigation is boring and effective — same-region placement, artifact cleanup policies for stale layers — but it has to be deliberate.

Third, scanning and storage are separate bills with separate APIs, and enabling container scanning lights up billing for both current and legacy products. And while the vulnerability scanning is genuinely useful, it is aimed at container images; if you need deep binary analysis, license compliance, and policy enforcement across every artifact type, the enterprise registries do more. There is also no dedicated product SLA, which we weigh against it in our rating.

Who should pick this

Our pick for teams already building on GCP. If your workloads run on GKE or Cloud Build, if your IAM lives in Google Cloud, and you want one registry for images and packages with scanning and deployment policy attached, Artifact Registry is the default we would choose — not because it is exotic, but because the integration cost is close to zero and the per-unit price is low enough that nobody has to think about it.

We would look elsewhere in two cases. Multi-cloud shops that want registry portability should evaluate Harbor or Artifactory first. And organizations whose core requirement is deep artifact governance — license scanning, build-info provenance, promotion pipelines across dozens of repos — will find JFrog's tooling further along, at a much higher price. Small teams with a single Docker registry and no GCP footprint may be better served by GitHub Container Registry or a self-hosted Harbor instance. If you want to compare registries and container platforms side by side, see /category/container-platforms and our /benchmarks pages.

The hybrid worth mentioning: remote repositories in front of public sources while standard repositories hold your own artifacts. It costs a few cents in storage and pays for itself the first time Docker Hub throttles a CI run.

Key takeaways

• Artifact Registry is Google Cloud's managed multi-format repository — Docker/OCI images, Maven, npm, Python, Go, RubyGems, Debian and RPM packages — GA since November 2020 and the successor to Container Registry (writes shut down March 18, 2025).
• Storage is $0.00 for the first 0.5 GiB per billing account per month, then about $0.10 per GiB-month ($0.000136986 per GiB-hour), identical for regional and multi-regional repos.
• Data transfer is the cost axis that surprises teams: free within a location, $0.01–$0.15 per GiB across regions and continents — co-locate repositories with consumers.
• Remote and virtual repositories (GA since November 2023) let one endpoint proxy and cache public upstreams like Docker Hub and Maven Central.
• Vulnerability scanning is built in but billed separately via Artifact Analysis; there is no product-specific published SLA.
• Our pick for GCP-centric teams; multi-cloud shops wanting portability should weigh Harbor or Artifactory first.

Sources

• https://cloud.google.com/artifact-registry/pricing
• https://cloud.google.com/blog/products/devops-sre/artifact-registry-is-ga
• https://cloud.google.com/blog/products/application-development/node-python-and-javarepos-are-generally-available
• https://cloud.google.com/blog/products/application-development/artifact-registry-remote-and-virtual-repositories-are-ga
• https://docs.cloud.google.com/artifact-registry/docs/transition/transition-from-gcr
• https://docs.cloud.google.com/docs/geography-and-regions
• https://cloud.google.com/artifact-registry