Google Container Registry After Shutdown: What GCR Was and How Migration Works
Why legacy Container Registry is no longer the service to design around, what remains true about gcr.io URLs, and how to move safely to Artifact Registry.
Google Container Registry stored container images behind hosts such as gcr.io, with image data backed by Cloud Storage buckets and access often tied to bucket permissions. It has been superseded by Artifact Registry. Google states that writes to Container Registry became unavailable on March 18, 2025 and that Container Registry became unavailable on June 3, 2025. Artifact Registry is the supported destination.
A hostname does not always identify the backend
The migration is easy to misunderstand because gcr.io URLs can continue to exist while Artifact Registry serves them through compatible gcr.io repositories. Seeing a working gcr.io/project/image pull does not prove the legacy Container Registry service is still active. Teams must inspect repository configuration and migration status, not infer it from the string in a Kubernetes manifest.
Google’s transition tooling can create Artifact Registry repositories corresponding to legacy host regions and redirect gcr.io traffic. This compatibility is valuable for large estates, but it separates the visible image name from the service storing and authorizing the artifact. Billing, IAM, audit events, cleanup policy, encryption, and repository administration follow Artifact Registry after redirection.
Why Artifact Registry is different
Artifact Registry creates explicit repositories with repository-level IAM, region or multi-region placement, audit logging, vulnerability-analysis integrations, and support for multiple artifact types. It also offers standard, remote, and virtual repository modes. The administrative model is therefore not a one-for-one rename of a storage bucket.
Repository location is a design decision. Place images near their consumers while accounting for residency, availability, replication, and transfer cost. Do not assume a new repository inherits every Cloud Storage permission previously used by GCR. Grant the narrow Artifact Registry reader, writer, or repository administrator role to the correct service identities and remove transitional access only after evidence shows it is unused.
Migration is an identity and supply-chain change
Search more than deployment manifests. Cloud Build, GitHub Actions, GKE node identities, Cloud Run and other runtime service accounts, local credential helpers, Terraform, vulnerability scanners, promotion scripts, Binary Authorization policies, mirrors, caches, and external customers may all reference old hosts or permissions.
Inventory image digests as well as tags. Copying a mutable tag without comparing its source and destination digest can promote different bytes under the same name. Preserve required multi-platform manifests, signatures, attestations, SBOMs, and retention metadata, then run pulls from each real execution identity. A successful administrator pull is not proof that production nodes have access.
Migration controls
Inventory producers and consumers, including CI identities, GKE nodes, Cloud Run services, deploy scripts, admission policies, and external mirrors. Establish Artifact Registry repositories in the intended locations, map least-privilege roles, copy or redirect content using Google’s documented workflow, and verify every critical digest before cutting over. Data residency and transfer cost can change when repository location changes.
Freeze or serialize publication during the final comparison so an image cannot change between inventory and redirect. Test rollback of the configuration—not a return to the retired service—and retain an approved recovery copy of critical artifacts. Monitor denied requests, missing manifests, unexpected cross-region traffic, repository growth, cleanup actions, and vulnerability scanning after transition.
Keep compatibility redirects only as long as they serve a deliberate purpose. New systems should use Artifact Registry concepts and commands directly rather than accumulating another generation of gcr.io assumptions.
Avoid destructive cleanup shortcuts
Legacy GCR storage buckets can contain artifacts that are difficult to reconstruct. Do not delete them merely because a sample pull succeeds through Artifact Registry. Complete Google’s migration and verification workflow, confirm retention obligations and consumers, preserve rollback evidence, and obtain explicit ownership approval before removing data or permissions.
Likewise, cleanup policies can delete images automatically. Start with a dry-run or review phase where supported, protect release and rollback digests, and verify the effect against the repository inventory. Migration is complete when every producer and consumer, permission, policy, and recovery path works against the supported backend—not when the first docker pull returns successfully.
Related: Google Artifact Registry: Repository Modes, IAM, Cleanup, and Deployment Integration · Google Cloud Run: Services, Jobs, Revisions, and the Container Runtime Contract
Sources: Transition from Container Registry, GKE Container Registry transition notice, Artifact Registry access control, Artifact Registry locations