How to Clean Up Old Container Images and Registries

Last updated: June 2026

An old container image is a stored image version that no current deployment, rollback target, or compliance hold still needs, yet keeps occupying registry storage and billing every month. They accumulate because continuous integration pushes a fresh image on nearly every commit, while deletion is left to nobody, so the repository grows without bound. This is the Cut step of FinOps applied to storage waste: clear the bytes that buy nothing before you ever pay for more capacity or commit to a reservation.

This article is part of our rightsizing and waste elimination cluster. For the full picture start with the complete guide to cloud rightsizing and waste elimination, the pillar this piece links up to. Stale images are one species of waste; an adjacent one is oversized compute, covered in how to rightsize memory-optimized instances safely.

Why do old container images cost so much money?

Old container images cost money because every stored image version occupies registry storage that bills per gigabyte every month, whether or not anything runs it. Amazon ECR charges 0.10 US dollars per GB-month for private repository storage, per the Amazon ECR pricing page, and Azure Container Registry and Google Artifact Registry bill storage on similar per-gigabyte models. The number looks trivial until you multiply it by reality: a CI pipeline that pushes ten image versions a day, each a few hundred megabytes of changed layers, across dozens of microservice repositories, quietly turns into hundreds of gigabytes of storage that nobody is watching. Multi-architecture builds and large base images make it worse.

What are untagged container images and why do they cost money?

An untagged container image is an image manifest that no longer has a tag pointing to it, usually because a newer build reused the same tag, such as latest or a branch name, and orphaned the old digest. The layers behind that manifest stay on disk and keep billing until they are explicitly deleted, because the registry never removes them on its own. Across frequent CI pushes to mutable tags, untagged images are commonly the single largest source of registry storage waste, which is why they are the first thing to target. Note that since shared base layers can be deduplicated within a registry, the storage you reclaim is the unique layers an image holds, not its full uncompressed size.

How do I clean up old container images, step by step?

Follow these six steps to remove old container images and keep registry storage from creeping back up.

1. Inventory every registry and repository. List all registries and repositories across regions and accounts, with total storage and image counts per repository, so you can see where the bytes actually sit before touching anything.
2. Find untagged and dangling images. Identify untagged manifests left behind by repeated pushes to the same tag. These are pure waste, hold their layers on disk, and are the safest first target.
3. Identify images no deployment uses. Cross-check stored image digests against what is actually running and referenced in your clusters and pipelines, so you only expire images nothing depends on for serving or rollback.
4. Write a lifecycle policy. Author a registry lifecycle policy that expires untagged images after a short window, for example one to fourteen days, and caps how many tagged images per repository you retain, for example the most recent thirty.
5. Dry run, then apply. Preview what the policy would delete, confirm no release image or rollback target is caught, then enable it so cleanup runs automatically rather than as a one-off purge.
6. Prevent the regrowth. Use immutable tags for releases, deduplicated base images, and a recurring storage report so growth is visible and the registry stays lean without manual effort.

What is a registry lifecycle policy and how do I write one?

A registry lifecycle policy is a rule set that automatically expires container images by age, count, or tag pattern, so old images are removed continuously instead of in occasional manual sweeps. Amazon ECR lifecycle policies, documented in the ECR lifecycle policies guide, let you expire untagged images after a set number of days and retain only the most recent images matching a tag prefix; Azure Container Registry offers retention policies and purge tasks, and Google Artifact Registry offers cleanup policies that do the same. A sensible default is to expire untagged images after a few days and keep a bounded number of tagged builds per repository, with release tags protected. The policy is the durable fix because it runs forever; a one-time cleanup just resets the clock.

Is it safe to delete old container images?

Deleting old container images is safe when you first confirm no running deployment, rollback target, or compliance hold references the image digest. The real risk is removing an image that a rollback or an audit still needs, so keep a retention window that covers your rollback horizon, pin release images with immutable tags so a lifecycle rule cannot expire them, and always dry run a policy before enabling it. Untagged images that nothing references are the safest to remove first, which is why the method targets them before touching anything tagged. The same detect, confirm, automate, and prevent pattern applies to other idle resources, such as in how to detect and remove orphaned load balancers.

Frequently asked questions

What are untagged container images and why do they cost money?

An untagged container image is an image manifest that no longer has a tag pointing to it, usually because a newer build reused the same tag and the old digest was orphaned. The layers behind that manifest stay on registry storage and keep billing until they are deleted. Across many repositories and frequent CI pushes, untagged images are often the single largest source of registry storage waste.

How much does container registry storage cost?

Amazon ECR charges 0.10 US dollars per GB-month for private repository storage, and Azure Container Registry and Google Artifact Registry bill storage on similar per-gigabyte models with tier or free allowances. Individually small, the charge compounds because CI pipelines push new image versions many times a day and rarely delete old ones, so a single active repository can hold hundreds of gigabytes of stale layers.

What is a registry lifecycle policy?

A registry lifecycle policy is a rule set that automatically expires container images by age, count, or tag pattern so old images are removed without manual effort. A typical policy expires untagged images after one to fourteen days and keeps only the most recent N tagged images per repository. It is the durable fix because it runs continuously rather than once.

Is it safe to delete old container images?

Deleting old container images is safe when you first confirm no running deployment, rollback target, or compliance hold references the image digest. The risk is removing an image a rollback or audit still needs, so keep a sensible retention window, pin release images with immutable tags, and dry run any lifecycle policy before enabling it. Untagged images that nothing references are the safest to remove first.

The short version

Clean up old container images by inventorying every registry, removing untagged and unused images first, and applying a lifecycle policy that expires untagged manifests fast and caps retained tagged builds. Registry storage is cheap per gigabyte but compounds across busy CI pipelines into real recurring cost. When you want every registry cleaned, the right policies in place, and storage kept flat, that is exactly what our rightsizing and waste elimination service delivers.

Written by Fredrik Filipsson and reviewed by Morten Andersen, applying the See, Cut, Lock, Run method. Independent and vendor neutral.