Can I delete releases from Nexus after they have been published?

Releases are forever, right? Once you’ve pushed an artifact to a hosted release repository it is etched in stone, and changing it is a bad practice. That’s what we’ve been saying since we launched Nexus, but there are situations that call for old releases to be deleted. In fact, there are situations that require the deletion of old releases? Otherwise, you’d be paying for terabytes of useless data storage.  

Sometimes Releases are Disposable

For example, consider a company that creates a large web-based system. They may deploy new versions of components to production multiple times a day. If this seems unrealistic, know that system administrators for popular services like Facebook,, and Flickr have talked openly about how frequently code is pushed to production systems. A few times a day isn’t odd in some of these environments, and with a large system, you’d consume terabytes of space to keep all of those old releases around.

Last time I worked at a large consumer-focused web site, pushing something to production once a day wasn’t uncommon, and even the idea of rolling back to anything other than yesterday’s build was laughably impractical. If you identified a bug in a CMS or a production database, you’d just craft the fix it and move on. This is especially true of larger, web-facing systems in which the only reality is the code that is running in production today. A site like Flickr gains nothing from being able to roll back to a release from last September.

The Other Side of the Coin: Releases are Forever

Compare this to the production release schedule of a critical, supported product and it’s like night and day. If you are coding some serious banking system you might be lucky to have a release once a month. In all likelihood you might be looking at a quarterly release.  When you are working on critical applications, ship software, or have infrequent release cycles then the ability to roll back to previously released binaries is very important. When you work somewhere fast-paced with a very short release cycle, there’s not much value in retaining older releases.

For this reason, we’re clarifying this point: if it makes sense for you to delete release artifacts from a hosted repository, go for it. Just remember to re-index the server once you’ve manipulated the storage folder.

We put together the following video to share more of our thoughts on this topic.

Removing Releases

If you decide that you do want to remove old releases Nexus makes this easy.  As of version 2.5 there is a new task you can add, "Remove Releases From Repository".

This scheduled task allows you to trigger the deletion of release components, supporting these use cases and taking care of meta data updates and removing the need to manually delete the components or use an external system to trigger the deletion.

To configure the task you specify the repository in which release components are to be deleted as well as the number of component versions to keep for a specific groupId and artifactId coordinate. The task generates a list of all versions of a component for each groupId and artifactId coordinate combination and sorts it according to the version number. The ordering is derived by parsing the version string and supports sematic versioning with additional semantics for specific classifiers. Further details can be found in the documentation for the implementing class GenericVersionScheme.

Have more questions? Submit a request


  • 0
    Gray Watson

    So are they forever or not?  I'd love to be able to remove some released with bad paths from the central repo.  Where do I find out about that?

  • 0
    Grégory Joseph

    What's your stance on volatile, unsupported released ? I'm thinking alphas, betas and other RCs that we make available to our customers, but really aren't supported. I'd like to get rid of these after a certain grace period. (at least move them somewhere where they don't use expensive storage space)

  • 0
    Brett Ryan

    Does anyone have a script that can reliably delete old versions while keeping x versions for a given group/artifact?

  • 0
    Brett Ryan

    Forget that, I see that the most recent version ( 2.6.4-02 ) actually contains a scheduled task to do exactly this.

  • 0
    Alexander Ashitkin

    Some feedback

    Although the 'remove releases' was promised to be improved in 2.11.3, in practice is still not usable for some reasons:

    1) on a big repository it tends to cause OOM in nexus. encreasing heap to large numbers doesnt help.

    2) on a big repo or slow file system it could run for days without wiping out a single byte (and finishing with OOM)

    3) Semantical ordering causes unexpected versions removal. if you have mixed future releases (ie 2.12.5) and actively maintained releases (1.28.4) in the same repo, you will finish with cleanup of active 1.* releases instead of 2.* versions. In fact you will not be ableto deploy a single 1.* version after the number of 2.* artifacts breached the limit

     In my opinion feature need to be improved in following way:

    1) Introuduce snapshots-like option 'Remove immediately' to have some cleanup progress in any case. That will allow to bring big repo to maintainable state in several runs. Currently it is possible only with find | rm

    2) Introduce option for time based removal instead of semantic ordering based

    thank you

    Edited by Alexander Ashitkin
  • 0
    Régis Evrard


    I don't find the task "Remove Releases From Repository" in Nexus OSS3.

    Is it planned to re-introduce this task in this version?


  • 0
    Rich Seddon

    We're going to be revisiting release cleanup in Nexus 3.x, we've found that most users need a more flexible approach than the one we took in Nexus 2.

  • 0
    Peter Lynch

    We are closing this article for comments.

    If you have a support license, please contact us by submitting a support ticket.

    If you do not have a support license, please use our Nexus Users List or our other free support resources.

Article is closed for comments.