Artifact registry retention: what keeping every build costs

Quick answer

Registry cost is storage multiplied by retention, and retention is usually infinite by default. A team pushing 40 image builds a day at 300 MB of unique layers each adds about 360 GB a month, roughly 36 dollars at 0.10 dollars per GB, growing every month. A retention policy that keeps all tagged releases, the last 10 builds per branch, and nothing untagged over 14 days typically removes 70 to 90 percent of stored bytes with no practical loss.

Nobody decides to keep every build forever. It happens because registries default to keeping everything and deleting things feels risky, so the cleanup task sits in a backlog while the bucket grows.

Two or three years in, the registry holds hundreds of thousands of tags nobody can identify and a storage bill that grows every month without any change in the team's behavior.

How fast it grows

Push rate	Unique layers per build	Monthly growth	Monthly cost added
10 builds a day	150 MB	About 45 GB	About 4.50 dollars
40 builds a day	300 MB	About 360 GB	About 36 dollars
100 builds a day	300 MB	About 900 GB	About 90 dollars
100 builds a day	800 MB	About 2.4 TB	About 240 dollars

The important word is added. These are increments on top of last month, so the 40 builds a day row is about 36 dollars in month one, 72 in month two, and about 430 dollars a month after a year of accumulation. Compounding is what makes registries surprising.

Unique layers, not image size

Registries deduplicate layers, so a 1.2 GB image built from a base that never changes may add only 40 MB of genuinely new content per build. That is why layer ordering matters so much: put dependencies in a layer above rarely changing base content and below application code, and most builds add only the application layer.

Invalidate that ordering, for example by copying the whole source tree before installing dependencies, and every build writes the full dependency layer again. The same rebuild becomes 400 MB instead of 20 MB, and the growth rate multiplies by 20.

A retention policy that is safe to run

The policy that works almost everywhere has four rules. Keep every image referenced by a released or tagged version indefinitely, or at least for the support window. Keep the most recent 10 builds per branch. Delete untagged manifests older than 14 days. Delete branch images whose branch no longer exists.

That set removes 70 to 90 percent of stored bytes in a typical registry with essentially no risk, because anything a rollback might need is either a release tag or recent. Run it in dry run mode first, look at what it would delete, then enable it.

Do not forget the non container artifacts

Language package registries, build outputs, test reports, coverage data, and binaries accumulate the same way, often in object storage with no policy at all. Test artifacts are particularly bad, since a CI run may upload hundreds of megabytes of logs and screenshots that are interesting for a day and useless after.

Apply lifecycle rules there too: 30 days for test outputs, 90 days for build artifacts not tied to a release, indefinite only for release binaries. Moving older release artifacts to an infrequent access or archive tier cuts their storage rate by 45 to 80 percent with retrieval latency nobody will notice, as described inlifecycle policy savings.

Pull traffic can exceed storage

Storage gets the attention, but egress often costs more. Pulling a 900 MB image 400 times a day from a registry in another region or across the internet is roughly 10.8 TB a month of transfer, which at 0.09 dollars per GB is close to 970 dollars.

Keep the registry in the same region as the clusters and runners that pull from it, replicate to each region you deploy in rather than pulling across, and use a pull through cache for external base images. In many estates this single change saves more than every retention policy combined.

Make retention part of the platform, not a chore

Retention rules belong in the registry's Terraform definition alongside the repository itself, so every new repository is created with a policy rather than acquiring one later. Put the rules in the golden path module and the problem never starts.

Since that configuration is code, c3x can estimate the registry and storage cost from the plan with no cloud credentials, which makes a pull request that adds a new repository or changes a replication setting show its monthly impact. Combine that with a quarterly look at the largest repositories by stored bytes and registry cost stays a small, predictable line rather than a compounding one.

FAQ

How fast does an artifact registry grow?

At 40 image builds a day with 300 MB of genuinely unique layers each, roughly 360 GB a month, about 36 dollars at 0.10 dollars per GB. The catch is that this is an increment: the same rate produces about 72 dollars in month two and roughly 430 dollars a month after a year of accumulation, which is why registry bills surprise people.

What retention policy is safe for a container registry?

Keep every image referenced by a released or tagged version for the support window, keep the most recent 10 builds per branch, delete untagged manifests older than 14 days, and delete images for branches that no longer exist. That typically removes 70 to 90 percent of stored bytes with essentially no risk, because anything a rollback needs is either a release tag or recent.

Why do some builds add far more registry storage than others?

Layer ordering. Registries deduplicate layers, so if dependencies sit in a layer above the rarely changing base and below application code, most builds add only the small application layer. Copying the whole source tree before installing dependencies invalidates that, making every build write the full dependency layer again, turning a 20 MB increment into 400 MB.

Does registry pull traffic cost more than storage?

Often yes. Pulling a 900 MB image 400 times a day across regions or the internet is roughly 10.8 TB a month, close to 970 dollars at 0.09 dollars per GB. Keeping the registry in the same region as the clusters and runners that pull from it, replicating per deployment region, and using a pull through cache for external base images usually saves more than retention policies do.

Where should registry retention rules live?

In the registry's Terraform definition alongside the repository, and in the golden path module so every new repository is created with a policy instead of acquiring one years later. Because that configuration is code, C3X can price registry and storage changes from the plan with no cloud credentials, so adding a repository or changing replication shows its monthly impact in the pull request.

What to do next

Keep registry growth predictable. C3X prices storage and registry changes from your Terraform plan. See the quickstart.