You’ll want to make sure that you run your repository manager on a server that is up to the task. The last thing you need is for Nexus to run out of space during a critical release because it is running on inadequate hardware. Disk space is cheap, broken builds are not.
In this post, I focus on storage requirements for Nexus. I discuss general recommendations and point you at resources we’ve developed to help you come up with accurate estimates for how much disk space you’ll need.
Disk Space
Disk space is going to be the critical parameter for a Nexus installation. At its core, Nexus is simply a collection of files and a set of services to index and serve these files. If you integrate Nexus into your development process and come to depend on it as a collaboration mechanism, you can easily consume hundreds of gigabytes (or even terabytes) of space.
Coming up with a simple guideline for storage requirements is difficult as it depends on a number of factors: How many projects do you have? How large are the artifacts being deployed to Nexus? How frequently are these artifacts deployed? and How long do you keep your releases? How much open source are you consuming from Central? How often do you update external dependencies? and How many 3rd party artifacts do you need to upload?
If you deploy artifacts to Nexus, your internal, hosted repositories are what will end up consuming the most space over time. At a large organization with hundreds of projects and frequent releases, it is very easy to create systems that consume a surprising amount of space. If you are interested in diving into the details and coming up with an estimate for your organization, watch “Getting Scientific about Sizing Nexus”.
While some of our engineers like to aim high with an initial recommendation of 250-500 GB, I like to aim a little lower. Sure, if you are rolling Nexus out to a 5,000 developer installation with thousands of projects, you may very well want to start with 1 TB. On the other hand, if you are gradually rolling Nexus out to a department or two, you should start with a more reasonable number: 50 or 100 GB.
I recommend starting with 50 or 100 GB, and I also recommend being prepared to expand that number as needed. Starting with this smaller number avoids the problem of procuring a huge chunk of disk space only to watch it sit idle for the months (or years) it will take you to consume all this space. Aim low, plan to expand.
Your initial estimate for disk space consumption is going to be just that, an estimate. Having set up scores of Nexus instances for organizations of all sizes, my experience has been that you’ll want to do some ballpark estimates and then multiply that estimate by a factor of two or three. When you connect systems like Hudson to Nexus and deploy snapshots from every integration build, you’ll appreciate the extra space.
As you start to use Nexus, you’ll have to tweak your scheduled jobs to make sure that you are periodically removing old snapshots and regularly keeping an eye on storage. If you expand the number of projects or developers using a Nexus instance, you’ll want to revisit some of these initial estimates and make sure that your system has enough storage to keep track of all the artifacts it is caching and storing.