Context
Container registry cleanup can reduce storage while quietly removing the image needed for recovery. The current application may keep running because its nodes already have the image locally. The failure appears later, when a new node tries to pull an old release during rollback or disaster recovery. Running containers are not proof that the registry still holds every required artifact.
Consider an illustrative platform that deletes untagged images older than a week. Production deployments use immutable digests, and some older digests no longer have tags. A routine node replacement then cannot start an infrequently used service. The cleanup policy followed its rules; the release retention model was incomplete.
Understand policy evaluation before enabling deletion
Artifact Registry cleanup policies support keep and delete conditions based on supported attributes such as tag state, prefixes, and age. Google provides dry-run evaluation and documents the interaction of keep and delete policies. Cleanup runs as background work, so policy changes and evidence are not necessarily immediate. Review the current behaviour for the repository format involved. 1
Write the intended retention rule in business terms first: current production releases, designated rollback releases, legal or support retention, and disposable builds. Then map those classes to attributes that the cleanup policy can actually evaluate.
Inventory the artifacts recovery depends on
Collect the deployed digests across clusters, environments, scheduled jobs, and dormant recovery configurations. Include worker images and migration tools, not only the main frontend. Record which historical releases the team promises it can restore and how long that promise lasts.
Inspect manifests and related image artifacts when the deployment uses multiple architectures. A human-readable tag is a pointer, while a digest identifies content. The retention design must preserve the content the runtime will request. Do not infer protection from a tag convention that the release pipeline no longer applies consistently.
Align release metadata with cleanup rules
Create a deliberate way to classify protected releases, such as supported retention tags or repository separation appropriate to the format and policy. Ensure the release pipeline applies the classification before a cleanup cycle can consider the artifact disposable. Record who can remove protection and under what conditions.
Avoid relying on manual tagging as an undocumented last-minute step. A release promoted at midnight should receive the same retention treatment as one promoted during office hours. Test the pipeline's failure path: if deployment succeeds but retention metadata fails, the release should be flagged for repair rather than silently treated as complete.
Inspect the full dry-run candidate set
Enable dry run and wait for the documented evaluation window. Collect the resulting candidate evidence and compare it with the protected digest inventory. Check pagination and repository scope so the review covers the full population. A screenshot showing a few harmless candidates does not establish that the important releases are excluded.
Investigate every protected digest that appears in the delete set before proceeding. Also inspect why large groups remain protected unexpectedly; a policy that retains everything may be safe but does not achieve the cost objective. Keep the reviewed policy version and candidate report together so the approval relates to a specific configuration.
Test recovery from a clean environment
Pull the current and designated rollback images on a fresh test node or another controlled environment without relying on a local image cache. Verify registry authorization, network access, platform architecture, and digest identity. Start the application in an appropriate test context and check the required configuration contract.
A rollback can still fail if the old application is incompatible with the current database schema. Keep artifact availability and application rollback compatibility as separate checks. The registry team can preserve an image perfectly while the release process makes that image unusable against the changed data model.
Activate cleanup with observation and ownership
Apply the reviewed policy through the normal configuration source. Observe registry growth, deletion outcomes, failed pulls, and release metadata errors. Keep an owner for the policy and another for the business retention promise if those responsibilities sit with different teams.
Understand that reverting the policy does not recreate artifacts already deleted. Recovery requires a trusted retained copy or a reproducible build that produces the required artifact under the organization's release rules. Rebuilding from the same source is not automatically the same digest when dependencies or build inputs have changed.
Reconcile retention as releases move forward
When a release leaves the rollback window, remove its protection through a deliberate lifecycle step. When a service becomes dormant, confirm whether its image remains required for periodic jobs or future reactivation. Cost optimization should follow the workload lifecycle rather than an arbitrary age applied to everything.
An illustrative decision might retain the active release and two tested rollback candidates for an agreed period, while deleting disposable branch builds sooner. The exact numbers are a product and operations choice, not a universal recommendation. The important requirement is a verifiable mapping from that choice to registry policy and deployment references.
Keep the acceptance record practical
Document the policy version, protected digest set, dry-run findings, cold-pull results, expected storage effect, and unresolved exceptions. A reviewer should be able to explain why a specific image will remain available after the next cleanup cycle.
A focused operator exercise: A rollback artifact acceptance example
Choose the active release and one designated rollback release from the deployment inventory. Resolve their exact digests and compare them with dry-run deletion candidates. Then pull both from a clean test environment using the same class of registry identity and network route that a replacement production node would use.
Repeat after the policy has completed an active evaluation cycle, following the approved rollout. Verify the protected digests remain available and the disposable candidates were handled as expected. Keep database compatibility checks in the release record as a separate item, because a successful cold pull proves artifact availability without proving the older application can use the current data schema.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Release inventory | Map active and rollback releases to digests | Protect required artifacts explicitly |
| Cleanup policy | Review keep and delete candidate interactions | Inspect a dry-run result |
| Cold recovery | Pull a protected digest on a clean worker | Verify rollback does not depend on warm cache |
Frequently asked questions
Are untagged images always unused? No. A deployment can reference a digest whose tag has been removed.
Clouvenix can review registry cleanup alongside release and recovery procedures, helping teams reduce storage without discovering missing artifacts during a production rollback.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.