Artifactory Cleanup Best Practices

Enterprise+ users now have an enhanced cleanup feature. Learn more here.

Software development can be a messy business. Often, there will be many artifacts residing in Artifactory that will never be used. And even though Artifactory makes great use of checksum-based storage, this can’t replace your need to regularly perform artifact cleanup duties. For example, although CI/CD builds are configured to run based on source control commits, these snapshot builds are never actually downloaded once they are sent to Artifactory.

As data retention policies differ from company to company, it’s incumbent upon you to determine what data needs to be cleaned up. Thereafter, Artifactory’s built-in tools can help you to handle the majority of cases you’ll want to address.

In general, there are three kinds of techniques that are used to manage artifact storage in Artifactory:

• Clearing oversized caches
• Deleting unused artifacts
• Limiting the number of build snapshots that are retained

The purpose of the last of these is to ensure that release artifacts are promoted out of the snapshots repository before it is overwritten.

Artifactory supports the Max Unique Snapshots tag for six repository types:
 

As Artifactory uses a Repository Layouts system to track snapshots, you’ll need to adhere to a defined pattern when uploading artifact snapshots . For most clients, once these limitations have been programmed into the system, the rest will occur automatically and seamlessly. For example, the following Maven JAR file is recognized as a part of snapshot run number 3:
 

 

Most CLI clients will upload snapshots that adhere to specific checksum policies and snapshot version behaviors, which Artifactory's default layouts should be able to address. Otherwise, as required, you can customize repository type layouts to handle specific upload paths. To enable this customization option in Artifactory, update your local repository settings:

 

When this setting is enabled, during any given build run that results in uploads reaching the Max Unique Snapshots number you entered, older releases will automatically be deleted. The highest number will always be your latest release.
 

Clearing an Oversized Cache

Artifactory's remote repositories store downloaded files in a cache. It’s generally beneficial to retain the entire cache as it speeds up downloads. However, if the artifacts being used for a given project change, you might find it worthwhile to periodically clear out the cache. If you’d like Artifactory to execute automatic cache cleanups for you, go to the Advanced tab of the remote repository menu. There, under Cache, in the Unused Artifacts Cleanup Period (Hr) section, you can define how many hours must pass, after which unused artifacts will not be deleted, but simply tagged internally as unused.


 

To configure and/or trigger this type of cache housecleaning, the cron job can be found under Admin > Advanced > Maintenance in Artifactory 6.X and Admin > Artifactory > Advanced > Maintenance in Artifactory 7.X. The Cleanup Unused Cached Artifacts field will, by default, execute a cache cleanup once every day.

JFrog Cloud Users

JFrog manages regular maintenance operations for all instances of JFrog Cloud. If you are a JFrog Cloud user, the features described on this page are all monitored and optimally managed for you by JFrog Cloud administrators.

Deleting Unused Artifacts

Artifactory does not automatically delete stored binaries unless specific retention policies are configured. Regularly cleaning out artifacts that haven't been accessed for a significant period can save considerable storage space. The recommended approach for automating this cleanup is now through dedicated Artifactory workers, replacing older user plugins.
For general artifact cleanup across most repository types, the Artifact Cleanup Worker can be used. Its primary function is to delete artifacts based on their last download date, removing files that haven't been accessed within a configured time period (e.g., older than 'x' days or months). This worker is triggered via a worker event, typically using the JFrog CLI, and offers a dryRun mode for safe testing.

Note
 This general worker is not suitable for Docker repositories.


For Docker images, the specialized Artifactory Clean Docker Images Worker is the recommended solution. This worker cleans Docker repositories based on policies defined directly on the images themselves using standard Docker labels. You can set policies to limit the age of images (maxDays) or the number of versions retained (maxCount). This worker is also executed via a worker event using the JFrog CLI and allows cleanup based on image creation or download dates, along with a dryRun capability.