Skip to main content
resource · gcp

Artifact Registry Repository

schedulable
no
category
containers-services

Does ZopNight manage Artifact Registry Repository?

Artifact Registry bills for every GB of stored images and packages per month, across Docker, Maven, npm, and Python formats. ZopNight lists repositories and their Docker images through the Artifact Registry API, attributes storage spend from the BigQuery billing export, and highlights repositories accumulating stale, unreferenced artifacts from old CI runs.

Rules that fire on Artifact Registry Repository

no live rules

No active rule family targets Artifact Registry Repository today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.

Browse every live recommendation for this platform →

Artifact Registry stores container images and language packages such as Maven, npm, and Python artifacts. Storage is billed per GB per month, and stale images from old CI pipelines accumulate silently.

Stored gigabytes are the whole meter

An Artifact Registry repository charges for the bytes it stores each month, plus network egress when artifacts are pulled across regions or out of Google Cloud. There is no per-repository fee and no compute component, which is exactly why the cost curve only ever climbs: every docker push from CI adds layers, and nothing removes them unless someone configures cleanup. As the successor to Container Registry, Artifact Registry inherits many projects’ entire image history during migration, often years of it.

Per-image visibility through the registry API

ZopDev discovers repositories via Cloud Asset Inventory and goes a level deeper through the Artifact Registry API, enumerating repositories and their Docker images so stale and unreferenced artifacts become visible rather than an undifferentiated blob of storage. Storage spend is attributed from the BigQuery billing export. Repositories have no off state, so scheduling does not apply; the savings lever is deletion, via cleanup policies and pruning of image tags that no running workload references.

How build pipelines inflate a registry

The dominant pattern is CI retention by default: a pipeline that builds on every commit pushes hundreds of images a month, while deployments only ever reference the latest few tags. A second pattern is multi-region duplication, where the same images are mirrored into several regional repositories and each copy bills separately. Third is the migration residue pattern: images carried over from Container Registry for safety and never touched again.

Inspecting repositories and cleanup policies

Google Cloud console → Artifact Registry → Repositories shows each repository with its format, region, and size. Opening a repository lists its images and tags; the Cleanup Policies tab reveals whether anything is pruning old versions. A multi-GB Docker repository with no cleanup policy and no recent pulls is the classic candidate for a retention rule.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·