Skip to main content

A tale of two repository managers: Nexus and Artifactory compared and contrasted

Posted by johnsmart on January 3, 2010 at 8:29 PM PST

There are several Maven repository managers on the market, but the two most prominent and most powerful are without doubt Nexus and Artifactory. Both these products are open source, with commercial versions containing more advanced features. Both are fine products, with many similar features. In many cases, however, Nexus and Artifactory respond to similar user needs, but in quite different ways.

In this article, I will try to give a general picture of a few of the main distinguishing features of these two tools, from the point of view of how you might want to setup your enterprise repository in a real organization.

Installation and general use

Both Nexus and Artifactory are easy enough to install. Nexus does use a lot less memory (around five times less according to my unscientific trials). A full build for a medium-size project on my workstation ran roughly 15% faster with Nexus.

Artifact searching

Searching for artifacts can come in handy from time to time. Nexus provides a simple, Google-like search interface for searching both your cached repositories and the remote repositories (you can actually configure whether you want a particular remote repository to be included in local searches). Nexus also supports Open Search, so you can integrate the Nexus search function directly into your browser (see below). The Nexus search feature also lets you search artifacts by other criteria, such as classname, GAV (group/artifact/version) or metadata.

Figure 1: The Nexus search in action.

Artifactory uses a different approach to searches. The search screen is quite detailed: as well as searching by keyword, classes, GAV, you can even search on Pom file contents using XPath. Searches however are limited to artifacts that are stored in the repository. This might be due to the fact that Artifactory documentation recommends using searches and metadata for build promotion strategies. You can search for metadata (called 'Properties in Artifactory') and save search templates in the commercial edition of Artifactory.

Figure 2: The Artifactory search screen.


If you work in a large organization, you probably don't want developers from other teams being able to deploy snapshots and releases for your project. Both Artifactory and Nexus have flexible flexible security models, build around users, user groups, and repository targets. With both, it is easy to limit the rights of a particular user or group to a particular part of a repository, for example, though the use of regular expressions in Nexus gives it more flexibility in this area. The Nexus model is more fine-grained and more powerful, but at the cost of a slightly more complicated user interface.

Figure 3: Configuring users and permissions in Artifactory.

Figure 4: Configuring users and permissions in Nexus.

Organizations often need to integrate with an LDAP repository. Artifactory comes with support for LDAP authentication out of the box, though this does not include advanced features such as mapping LDAP groups to Artifactory groups or permissions. The upcoming open source version of Nexus (1.4.2) comes with powerful integrated LDAP support, including authentication, mapping LDAP users directly to Nexus permissions, and mapping LDAP groups to Nexus roles. This sort of feature is highly prized by larger organisations with large existing LDAP repositories. The commercial edition (Nexus Pro) promises even more advanced LDAP features such as support for multiple LDAP servers and enhanced caching.

Build promotion strategies

Build promotion strategies basically involve moving artifacts from one repository to another depending on their stage in the build promotion process. You can implement such strategies manually, but a bit of automation can really make your life easier.

Artifactory supports build promotion to some extent in its commercial version, using a combination of repository metadata and a process of manually copying or moving groups of artifacts between repositories.

Build promotion is one of the areas that Nexus Pro really shines. You can set up a Staging profile, which intercepts certain artifacts (for example, release artifacts for a particular project) and places them in a special, dynamically-created repository. Once all the required artifacts are deployed, a build administrator can make these staged artifacts available for further testing (in a UAT environment, for example). Involved users can be notified when a build is staged and promoted, so that they can go to the relevant environment and run their own tests. When the tests are finished, the artifacts in the staging repository can be promoted to their final destination (for example, a special Production Releases repository). You can also associate rules with this promotion process, to check things like the validity of the pom file or the presence of javadocs in the artifacts. These rules are highly configurable: you can even use them to kick of an automated deployment process when the staging is done, for example.

Figure 5: Promoting a build to production in Nexus Pro.

Deploying Maven web sites

One other neat feature available in Nexus Pro is the ability to deploy Maven sites. This gives you a convenient central server where you can deploy and consult the Maven web site for each of your projects with a minimum of fuss and effort.

Repository Maintenance

Both tools provide good support for repository maintenance, but with a very different feature set. Artifactory proposes to actively tidy up pom files that it downloads, by removing any declarations of remote repositories in them. It also lets you limit the number of snapshots per artifact for each repository. In Nexus, you can also schedule maintenance tasks such as deleting old snapshots, backing up configuration files and so on. You can also configure Nexus to delete all the snapshots for a particular artifact when it is release, which can save quite a bit of space for large projects.

Figure 6: Configuring scheduled maintenance tasks in Nexus.

So which repository manager should you choose?

This comparison is far from complete. Both Artifactory and Nexus are solid, feature-rich products, and the competition is good, as it keeps both product teams on their toes. My personal recommendation however goes to Nexus, as in my opinion it has better support for the requirements of larger organisations, and is nicer to work with in the context of build pipeline automation. Here are a few reasons why you might prefer Nexus:

  • Nexus Pro has many powerful features, such as staging and procurement, well-suited to the needs of large organizations
  • Nexus is rock-solid and extremely well battle-tested: is widely used on many very large-scale repositories (including,, and many other open source repositories)
  • Nexus is superbly documented - a very well-written book (Repository Management with Nexus) is freely available online.
  • User Interfaces are very much a matter of taste, but for me Nexus has very a clean, fast user interface with just the right amount of AJAX.
  • Nexus Pro includes support for OSGi bundles (OBR) and Eclipse P2 repositories - very cool if you need that sort of thing.
  • Lightweight and efficient (runs in only 28m)
Related Topics >>


Nexus and Artifactory: Comparing apples and apples...

Regarding the performance

Regarding the performance gained by eager fetching, we evaluated eager fetching of JARs in early Nexus versions but decided to rank it low on our priority list for a couple of reasons:
  1. It only benefits the first user requesting a set of artifacts. Typically the bottleneck is the external bandwidth and thus if the first user needs to download 25mb of jars, the order of the requests would only marginally affect the overall download time. However, if you're copying from another system on a high speed LAN (as you would likely use for benchmarks to control variation in network congestion) then the network wouldn't be the bottleneck and things would in fact test out faster.
  2. Maven makes requests for POMs during the resolution process that may ultimately be evicted from the graph. Fetching these jars is potentially wasteful and could result in build slowdown as valid requests have to contend with bandwidth from pre-fetched JARs which will not be used. Maybe that's not an issue if you process it as a background process, but if that's the case, I wonder how often the eager fetching is requesting JARs before Maven does.
  3. Recent versions of Maven are able to make parallel requests for artifacts, and are pretty effective at saturating the available network when needed, I would imagine this would cause some interactions with pre-fetching.

In short, I'm sure certain benchmarks in a completely clean system proxying a lan may run faster, but I would expect real world performance to be "typically negligible." Therefore in our view, the risk of complexity for the reward of small gains didn't pan out, but hey that's where choice for the user is better, I think it's just important to have perspective on the gains in real scenarios.

Regarding the POM cleanup implementation, I also have pretty serious concerns about the implications of rewriting poms (not to mention the implied subtext of that blog title). I won't go into the details here but I would classify this also in the low upside, high downside category.

Regarding the importing and exporting of the repository configuration, this seems like a moot point when you have a full REST API. In Nexus, everything is done over REST, so that means you can import and export all the configuration, not just the repository config via wget if you feel like it.

In addition to the REST, Nexus supports the repository-metadata.xml standard used on Maven Central, where key information about a repository is available right inside the repo. This means that if so configured, anyone can discover the canonical urls for proxies, other known mirrors, what repos are contained by a group, and the release and snapshot type. This has been supported by Nexus since 1.3. Take a look here for a few examples of this metadata:

I also added comments about differentiating features here: