Service 44

Artifact Registry

RegistryArtifacts

Artifact Registry is the modern artifact storage on Google Cloud. It holds Docker images, Maven and Gradle packages, npm packages, PyPI packages, Go modules, Apt and Yum repositories, and generic binary blobs. The catalog is broader than the "container registry" name implies — Artifact Registry is for everything a build produces or consumes, not just containers.

Artifact Registry replaces Container Registry (the older gcr.io service), which Google shut down on March 18, 2025. gcr.io requests are now automatically redirected to Artifact Registry's gcr.io repositories, so existing pull/push paths keep working, but the original Container Registry service is gone — any project that has not yet migrated should do so. The migration is mechanical for most teams — Google publishes scripts that copy images and update push targets.

Artifact Registry vs Container Registry

Container Registry was Google's first artifact service: Docker images only, hosted at gcr.io, with limited features around region selection and IAM. Artifact Registry is the second-generation product: multi-format, regional and multi-regional repositories, native CMEK support, fine-grained IAM, vulnerability scanning, and the Remote and Virtual repository types that Container Registry never had. Container Registry no longer exists as a standalone service (shut down March 2025), so all new work uses Artifact Registry; any project still pushing to gcr.io is relying on the redirect and should complete the migration.

Repository Types

Artifact Registry supports multiple package formats, each in its own repository:

Docker — container images, by far the most common use.
Maven / Gradle — JVM packages.
npm — Node.js packages.
Python (PyPI) — Python wheels and sdists.
Go modules — Go package proxy.
Apt / Yum — Linux package repositories.
Generic — arbitrary binary blobs.

One Artifact Registry project can host repositories of every type — there is no need for a separate service per package format.

Standard, Remote, and Virtual Repositories

Standardyour artifacts

Stores the images and packages you build and push. The normal repository.

Remoteupstream cache

Caches an upstream registry (Docker Hub, PyPI, Maven Central) so builds do not depend on it being up — or rate-limiting you.

Virtualone endpoint

A single endpoint that fronts several standard and remote repos, so clients pull from one URL.

Three repository modes:

Standard — stores artifacts your team produces. The default for outputs of Cloud Build.
Remote — proxy and cache for upstream registries (Docker Hub, npm, PyPI, Maven Central). Builds pull from the Remote repository; if the artifact is not cached, Artifact Registry fetches from upstream once, caches it, and serves from cache thereafter. Two benefits: insulation from upstream rate limits and outages, and a smaller supply-chain surface (the team controls what enters the cache).
Virtual — a single endpoint that combines multiple Standard and Remote repositories. The client sees one URL; Artifact Registry resolves which underlying repository holds the artifact. Useful when builds need to consume both internal artifacts and upstream packages through the same endpoint.

Container Analysis and Vulnerability Scanning

For Docker repositories, Container Analysis scans pushed images for known vulnerabilities (CVEs) in OS packages and language-level dependencies. Scanning runs automatically on push and on a recurring schedule for previously-scanned images, so newly-disclosed CVEs surface against existing images without re-pushing. Findings flow into Security Command Center and are addressable as CVE-by-image queries. Enable scanning on every production repository; the cost is small and the value is real.

Binary Authorization Integration

Binary Authorization is a separate GCP service that gates deployments — only images that meet a policy can be deployed to GKE or Cloud Run. Common policy: "this cluster only accepts images that came from this Artifact Registry repository and passed vulnerability scanning". Artifact Registry plus Container Analysis plus Binary Authorization together form a supply-chain enforcement story: only images that were built by your CI, stored in your registry, and passed scans actually reach production.

IAM and Access Control

Repositories are IAM resources. Common roles: roles/artifactregistry.reader for workloads that pull, roles/artifactregistry.writer for CI that pushes, roles/artifactregistry.admin for the team that manages the repository. Bind to groups, not individuals (the same rule that applies everywhere else). Public-read access is supported but rarely the right choice for production — prefer authenticated pulls with IAM-scoped service accounts.

Common Mistakes

Still relying on Container Registry (gcr.io) in 2026. The service was shut down in March 2025; you are running on the redirect to Artifact Registry, and the migration should already be done.
One enormous repository for the entire organization. Blast radius for compromise is the whole company, IAM bindings become unmanageable, and image tags collide between teams.
Public read access enabled by accident. Internal-only images become discoverable externally; competitive intelligence becomes a Google search away.
Vulnerability scanning disabled. CVEs in production images go unflagged until the next external pentest, which is the worst possible audit signal.
No image retention or cleanup policy. The Artifact Registry bill grows linearly with build count forever; old images that no one will ever deploy sit in storage indefinitely.
Builds pull directly from Docker Hub or PyPI in production. Rate limits, supply-chain compromise of upstream, and outages on upstream take your production down. A Remote repository fronting those upstreams is the right pattern.

Best Practices

Migrate any remaining Container Registry usage to Artifact Registry. The cost of running the migration is small compared to depending on the legacy redirect for a service that has already been shut down.
Per-team or per-environment repositories. Production, staging, and dev get separate repos with separate IAM and separate retention rules.
Vulnerability scanning enabled on every Docker repository, with findings reviewed during release cycles.
Binary Authorization for production deployments. Only signed, scanned images from your registry reach production.
Cleanup policies on every repository — keep the last N versions per tag pattern, delete untagged images after a grace period. Storage cost stays bounded.
Remote repositories for all external dependencies — Docker Hub, npm, PyPI, Maven Central. Direct pulls in production are a single point of supply-chain failure.

Comparable services AWS ECR + CodeArtifact Azure Container Registry + Artifacts Third party JFrog Artifactory

Knowledge Check

What is the relationship between Artifact Registry and Container Registry?

Container Registry is the newer multi-format service that Google launched to replace Artifact Registry, which is the older Docker-only product now being phased out and redirected to the newer endpoint
Artifact Registry is the modern multi-format service that replaced Container Registry, which was shut down in March 2025; any project still pushing to gcr.io should complete its migration
They are two regional aliases for the same underlying service — Container Registry serves US and EU multi-regions, Artifact Registry serves Asia
Artifact Registry holds non-container artifacts like npm and Maven packages, while Container Registry remains the supported home for Docker images

What does a Remote repository in Artifact Registry do?

Replicates the repository asynchronously to a chosen remote region on every push so that a fully synchronized second copy survives a regional outage, giving the repository built-in cross-region disaster recovery
Proxies and caches an upstream public registry (Docker Hub, npm, PyPI, Maven Central) — builds pull from your Remote repo, which fetches each artifact from upstream once and serves it from cache thereafter
Exposes the repository to named external partners over the public internet with anonymous read access for sharing released artifacts
Stores artifacts in a chosen partner's data center rather than Google's own storage, satisfying data-sovereignty compliance requirements

Why use a Remote repository to front Docker Hub instead of pulling from Docker Hub directly?

Google blocks all outbound traffic to Docker Hub at the VPC edge by default as an egress-security measure, so a Remote repository is the only supported path that can reach the upstream registry at all once a build runs inside a Google project
Direct pulls expose production to Docker Hub rate limits, outages, and supply-chain compromise of upstream; a Remote repository caches images, controls what enters the cache, and isolates your build from upstream's availability
Remote repositories are billed at a lower per-pull rate than direct Docker Hub access, so fronting the upstream is mainly a way to cut the registry bill
Remote repositories scan and rewrite Docker Hub URLs inside your Dockerfiles automatically, so image references never need to be edited by hand

How does Binary Authorization use Artifact Registry?

Binary Authorization continuously scans every artifact stored in Artifact Registry on a schedule and permanently deletes the images it does not trust before they can ever be deployed to a cluster anywhere in the project
It enforces deployment policies — a cluster can be configured to accept only images that came from a specific Artifact Registry repository and passed vulnerability scanning, so untrusted images never reach production
Binary Authorization is the encryption-at-rest layer for Artifact Registry, wrapping each stored image in a customer-managed key before it is written to disk
It generates an SBOM (software bill of materials) attestation for each pushed image and attaches it to the repository for later audit

What happens to storage cost in Artifact Registry without a cleanup policy?

Storage is billed as a fixed flat fee per repository regardless of how many gigabytes it holds, so the monthly line item stays exactly the same no matter how many image versions accumulate over time
Artifact Registry automatically deletes untagged images after 30 days and old tagged versions after 90, regardless of whether a cleanup policy exists
The bill grows linearly with build count forever — old images that no one will deploy sit in storage indefinitely, and the team only discovers the cost during a bill review
Artifact Registry pauses all further pushes once a repository reaches its default 10 GB free-tier ceiling, capping the cost automatically

You got correct