Google Artifact Registry

Google Artifact Registry is a managed service on Google Cloud for storing, managing, and distributing build artifacts and dependencies, including container images, language packages, and operating system (OS) packages. It succeeds Container Registry, which is now shut down. Writing images to Container Registry became unavailable on March 18, 2025.

Key Capabilities

• Multi-format storage: The service supports Docker (container images and Open Container Initiative (OCI)-format Helm charts), Maven (Java, built with Maven or Gradle), npm, Python, Go, Apt (Debian), Yum (RPM, managed with Yum and DNF), Ruby, Conda, Kubeflow pipeline templates, and generic artifacts. Ruby and Conda are marked Preview in the documentation. Container Registry handled only container images.
• Repository modes:
  • Standard repositories store the artifacts and packages an organization creates.
  • Remote repositories cache dependencies from upstream sources such as Docker Hub, Maven Central, npmjs, PyPI, and Debian and Ubuntu mirrors. They can also use other Artifact Registry repositories or a custom HTTPS URL as the upstream. The first request for a version downloads it into the cache, and later requests are served from the cache even if the upstream goes offline.
  • Connector repositories proxy upstream sources without caching.
  • Virtual repositories expose standard and remote repositories behind a single endpoint, with a priority on each repository that sets search order. Ranking private repositories ahead of remote ones guards against dependency confusion, where a malicious public package is chosen over a private one.
• Location and access control: Teams can create multiple repositories per project in a region or multi-region. Identity and Access Management (IAM) permissions and conditional access apply per repository. Container Registry offered four multi-regional hosts with bucket-level controls. Repositories can be placed inside a VPC Service Controls security perimeter.
• Encryption: All content is encrypted at rest by default. A repository can instead use a customer-managed encryption key (CMEK) from Cloud KMS, including keys from Cloud External Key Manager. The key is chosen at repository creation and cannot be changed afterward. The key's location must match the repository's location. Disabling or destroying the key makes artifact data inaccessible, although users with reader roles can still see metadata such as names, versions, and tags. Organization policy constraints can require CMEK for new repositories.
• Vulnerability scanning: Artifact Analysis scans container images automatically on push and keeps results current as new vulnerabilities are published. The documentation says Artifact Registry includes application language package scanning. Findings aggregate in Security Command Center and can be exported to BigQuery. Artifact Analysis also stores metadata as notes and occurrences, which Binary Authorization can use for deployment policies.
• Cleanup policies: JSON-defined delete and keep policies automate retention on standard repositories. Conditions are tag state, tag prefix, version name prefix, package name prefix, and age (olderThan, newerThan). A keep policy can also retain the N most recent versions. Keep policies override delete policies. Dry runs write BatchDeleteVersions entries with validateOnly set to true to the Data Access audit logs. Policies take about a day to take effect, and they do not delete tagged artifacts in repositories with immutable tags.
• Logging and API: The service provides audit logging, a REST and RPC API, and Docker Registry API support. Container Registry had neither audit logs nor an API.
• Runtime integration: Cloud Build stores build artifacts in the registry. GKE and Managed Service for Apache Spark can pull images with image streaming, which prewarms images to reduce cold-start latency. Cloud Run, Compute Engine, and App Engine flexible environment deploy from it. The service also offers Cloud Run source deployment and per-user quotas.

Audience & Use Cases

• Audience: Platform and DevOps engineers, application developers, and security teams on Google Cloud.
• Use Case: A single private registry for container images and language packages across CI/CD pipelines.
• Use Case: Caching public dependencies in a remote repository, with scanning, so builds do not depend on upstream availability.
• Use Case: A virtual repository that merges private and public sources, with priorities set to block dependency confusion.
• Use Case: Retention automation with cleanup policies to control repository growth.
• Use Case: Moving off Container Registry. Teams can keep existing gcr.io URLs, which Artifact Registry repositories now serve. They can also move to pkg.dev repositories and switch gcloud container images commands to gcloud artifacts docker. The pkg.dev route requires creating the repository first, because pushes to pkg.dev do not create it.

Technical Specifications

• Hostnames: pkg.dev for native repositories and gcr.io for repositories created to preserve Container Registry URLs.
• Clients and tools: Docker clients, Helm 3, Singularity, Maven, Gradle, npm, Apt, Yum, DNF, RubyGems, Bundler, and the Vertex AI KFP client.