Use the garbage collection feature of Container Registry (ACR) Enterprise Edition instances to clean up unused image versions and reclaim storage space in Object Storage Service (OSS) buckets.
Before you begin
Before running a garbage collection task, carefully read these instructions and the prompts in the console, and make sure the information is correct. Deleted image data cannot be recovered, even if OSS versioning is enabled. Ensure critical images can be rebuilt and pushed if needed.
Do not directly delete or modify data in the ACR-associated OSS bucket through the OSS console, including during and after garbage collection. Doing so makes ACR unavailable. To free up storage space, always use the garbage collection feature in the ACR console.
To reduce the risk of accidental deletion, consider configuring OSS cross-region replication for geo-redundant backup, or enabling Cloud Backup for scheduled OSS backups.
Step 1: Enable the garbage collection feature
To enable the garbage collection feature, submit a ticket.
Log on to the Container Registry console.
In the top navigation bar, select a region.
In the left-side navigation pane, click Instances.
On the Instances page, click the Enterprise Edition instance that you want to manage.
In the navigation pane on the left, choose .
On the Garbage Collection page, click Execute .
In the Confirmation dialog box, click Submit Ticket to enable the garbage collection feature.
ImportantIf this is your first time performing this operation, click Submit Ticket in the Confirmation dialog box to add your account to the whitelist. This is a one-time operation.
Step 2: Create a garbage collection task
Garbage collection runs at the Enterprise Edition instance level. Each task removes invalid image versions from all image repositories within the instance, excluding chart repositories. You cannot clean up individual namespaces separately. To clean up a specific namespace, first use a version retention policy to delete unnecessary image versions in that namespace, then run an instance-level garbage collection task to reclaim unreferenced layer data.
No preview of items to be cleaned is available. After you click Execute and confirm in the Confirmation dialog box, the system immediately compares repository images with OSS data and starts the cleanup process.
Clients can continue to push and pull images during a garbage collection task.
Log on to the Container Registry console.
In the top navigation bar, select a region.
In the left-side navigation pane, click Instances.
On the Instances page, click the Enterprise Edition instance that you want to manage.
In the navigation pane on the left, choose .
On the Garbage Collection page, click Execute . Read the notice in the Confirmation dialog box. After you confirm, select Confirm to clean up and then click Confirm.
Execution results
In the navigation pane on the left, go to . On this page, view or cancel the task.
After the garbage collection task completes, OSS bucket storage does not decrease immediately. Cleanup occurs in two phases: first, invalid image version markers are removed; then, physical storage is released based on the bucket lifecycle policy. The default delay before release is 15 days.
The ACR backend automatically manages this lifecycle policy, which applies only to invalid image data marked for deletion and does not affect other image data. No manual configuration in the OSS console is required; manual changes are overwritten by ACR defaults during the next garbage collection. If no lifecycle rules appear after the task completes, wait for backend verification to finish, then check again.
FAQ
What is the difference between version retention policy cleanup and garbage collection tasks?
Version retention policy cleanup deletes image tag references only. It does not reduce the physical storage used in the OSS bucket, so OSS storage usage does not decrease after cleanup.
To actually reclaim OSS storage occupied by invalid image versions, you must run a garbage collection task. The task triggers physical deletion through the bucket lifecycle policy, with a default delay of 15 days before space is released.
If you have already cleaned up image tags through a version retention policy, run a garbage collection task to reclaim the associated OSS storage.
| Version retention policy | Garbage collection task |
What is deleted | Image tag references | Physical layer data in OSS |
OSS storage reduced | No | Yes (after lifecycle policy delay) |
Scope | Namespace level | Enterprise Edition instance level |