Cleanup Policies

Only users with the admin (i.e., nexus:*) privilege can use the Cleanup Policy left navigation item. Any user with the privilege to edit a repository (such as nexus:repository-admin:maven2:maven-central:edit for the default maven-central repository) can adjust the policy a repository uses.

Permission to edit the cleanup task is either nx-tasks-update or nx-tasks-all

You can create and assign one or more cleanup policies to a repository under Administration → Repositories. You can assign cleanup policies to both proxy and hosted repositories.

Each policy's criteria will be ANDed together, removing only components that meet all of the specified conditions.

Name and Format are required fields and the name can not be edited after policy creation. You can also enter cleanup criteria to define the policy and can edit these fields later if desired as well.

Only letters, digits, underscores(_), hyphens(-), and dots(.) are allowed and may not start with underscore or dot.

The table below lists the available cleanup criteria and the formats to which they can apply:

¹ - Cleanup only evaluates tagged manifests for Docker. Untagged manifests are not considered components in the Nexus Repository. Cleanup is only complete when the Docker - Delete unused manifests and images task has run.

² - Bower functionality is for proxy repositories only.

hello/-/hello-0.0.1.tgz
hello/-/hello-0.0.2.tgzhello/-/hello-0.0.3.tgz

hello/-/hello-0.0.[2-9].tgz

hello/-/hello-0.0.1.tgz

org/example/test.jar
com/example/test.jar
test/example/test.jar

(org|com)/.*

test/example/test.jar

org/sonatype/team1/ui/5.0/ui-5.0.jar
org/sonatype/team2/format/1.0/format-1.0.jarorg/sonatype/team3/database/10.0/database-10.0.jar

org/sonatype/team[2-3].*

org/sonatype/team1/ui/5.0/ui-5.0.jar

pool/main/libc/libcap2/libcap2_2.25-1.2_amd64.debpool/main/z/zsh/zsh_5.4.2-3ubuntu3_amd64.debpool/main/z/zsh/zsh-common_5.4.2-3ubuntu3_all.deb

pool/main/z/zsh/zsh-common_5.4.2-3ubuntu3_all.deb

pool/main/libc/libcap2/libcap2_2.25-1.2_amd64.debpool/main/z/zsh/zsh_5.4.2-3ubuntu3_amd64.deb

Cleanup tasks remove components and associated assets from the database; however, as with other delete operations in Nexus Repository, the associated blobs (files) are not immediately removed from storage. Blob store space is reclaimed automatically if the Admin - Compact blob store task is scheduled. For those using H2 or PostgreSQL databases, the Admin - cleanup unused asset blobs task must also run before the Admin - Compact blob store task executes.

If you must immediately reclaim storage space, proceed with the following:

For Azure blob stores, the Admin - Compact blob store task asks the Azure blob store to perform a hard delete by calling the delete function on the Azure client. This function then marks the specified blob for deletion, and it is deleted during garbage collection on the Azure side. This may vary depending on whether or not you have the soft delete feature enabled as described in Azure's documentation.

The Admin - Compact blob store task is not used for S3 blob stores. Instead, Nexus Repository creates an AWS bucket lifecycle policy based on the blob store configuration to schedule blobs for deletion. (See our documentation on configuring expiration days for S3 blob stores.)

See Tasks for more general information on configuring tasks.

Docker has a unique way of managing components and assets (See Components and Assets in Docker) and therefore requires some thought when designing a cleanup strategy.

The following table outlines what tasks will soft-delete blobs in blob stores for Docker repositories:

The following table outlines what features perform a hard delete (i.e. free storage space) of soft-deleted blobs:

One very common use case for cleanup policies is to clean up components that have never been downloaded.

To do this, configure a cleanup policy using the Component Usage (Days) criterion. This criterion tells the cleanup policy to remove components that haven't been downloaded in a specified number of days.

If a component has never been downloaded, the policy will use the component's published or updated date instead. To further explain, Sonatype Nexus Repository identifies components for cleanup by looking at the most recent (maximum) blob created date from all assets on the component. For components with multiple assets, that can be considered the last updated time for the component.

So, if a component was not downloaded, created, or updated in the specified number of days, the policy will identify it for removal.