Nexus Repository Best Practices: Cleanup Policies

Sonatype Nexus Repository Best Practices
, ,
1

Quiz time: imagine a Nexus Repository instance used by a Javascript team that builds once every two weeks. How can an administrator remove components from the repo that aren’t being used? And how long should a component sit in the repo before it’s queued for deletion?

Thought about it? Okay, then read on!

It’s no secret that the bulkiest part of your Nexus Repository deployment is your blob storage. 10 TB is typical for large deployments. Some of our customers self-report as having blob storage closer to 50 TB, and that’s not the most extreme we’ve seen.

Regardless of whether you’re running in the cloud or on-prem, that can get expensive. Some back-of-the-envelope estimation shows that 10 TB of storage in an AWS S3 bucket costs around $230 a month. And that doesn’t include the cost of data transfer, backups, lost performance, etc.

Remember, your blob storage will grow if you ingest new components faster than you delete old components. Any effort to delete old components will help keep your blob storage controlled.

For that reason, an obvious best practice for anyone using Nexus Repository is to use cleanup policies to control your blob storage. At a minimum, consider a cleanup policy for components that haven’t been downloaded for a certain number of days. 90 days is a very generous starting point. 30 days is stricter but still reasonable for most production environments. That’s our standard recommendation for repos for apps that are actively developed.

If you want to be even stricter, set the cleanup policy to slightly longer than your average build cadence. For example, a repo for a legacy app built once every three months should have a cleanup policy for components older than four months. A repo for a team building snapshots once a week should have a cleanup policy for components older than 10 days.

And remember! Cleanup policies only soft delete the components. To actually reclaim the storage space, you need to run the Admin - Compact blob store task.

There’s a lot more to say about cleanup policies – stay tuned for further advice.

Resources:

Nexus Repository Administration Best Practices

Cleanup Policies

Staging Concepts

Storage Planning

1 Like
2

You also need to consider the type of repository. For a Maven repository storing snapshots, you can have a much more aggressive cleanup policy than for your release repository.

3 Likes
3

This is 1 way of doing it. Arbitrary timestamps. Another way would be to actually know what is running in production and clean up N-3 versions from the repository. That way you ensure you can always rollback from N to N-1 and N-2.

2 Likes
4

Absolutely. Repositories storing snapshot artifacts are a great place for aggressive cleanup policies, especially because of how rapidly they’ll grow without them. A nightly snapshot, multiplied by 365 days in a year, multiplied by the number of apps you’re developing = huge growth.

Maybe our next best practices post should be specifically about repositories for build artifacts?

1 Like
5

Thanks, Ingmar, that’s a good point. Being able to roll back to n-2 or n-3 is important, especially if you’re talking about release candidates. A good staging setup can help you be aggressive in cleaning up while still protecting your ability to rollback. Maybe I’ll bring this up in our next best practices post.

1 Like
6

@jzora looking forward to it

7

@ingmar.vis and @jeff.wise - we continued this discussion in this post - would love to know your thoughts!