Sonatype Nexus Repository Reviews

We happily use containers as a way of scaling out microservices so we use Nexus Repository for the management of containers, as a kind of repository. That's about 50 percent of what we use it for. The other side is that it is used for application and development artifacts. We use it to track artifacts in a repository so we can deploy software code. It's not a code library because we GitLab as well. It's more for the compartmentalized aspect that fits in and we can redeploy those on-demand.

The way we deploy it is private cloud, ultimately. We have an internal cloud infrastructure that we operate and the Nexus platform sits inside it. We are looking at ideas around integrating this into AWS right now, because we are doing a huge kind of transformation project to move a lot of our on-prem services into public cloud. We're looking at that whole "bridge" between the cloud and on-prem and how we deal with that. That's something of a stepping-stone before we can take everything back into the cloud. I think Nexus Repository will eventually end up there.

The key benefit we get from it is speed to delivery. It has improved our overall time to get new applications out with new code. That's true whether from a platform perspective, where we are quickly deploying up-to-date Docker containers, or whether we are looking to deploy new code out to deliver a new application. That whole release cycle is vastly improved. The way we've automated a lot of our processing, particularly with us being very much a cloud-centric organization, it helps with our ability to deliver code and then scale out as we need to.

Initially, we did a deal with Sonatype to get a small number going to see what the general, intangible benefits were. The developers were certainly happy with the way our product was working. And then there was fact that we had more control of it, being on a computer on somebody's desk, that it was more centrally managed. I do have a really strong feeling that if we took it away, overall productivity would drop off. How much? I don't know but it certainly would drop off. We would probably lose people as well, since they like the tool.

We did a survey, a tool-chain analysis across the whole company, because we've got many different tools doing all sorts of similar things. At the top of the chart, in terms of people loving them, across the business — in particular the developers — were GitLab and Nexus. Nexus Repository is seen as a key, useful, strategic tool that we use here.

We've had some challenges around the database they use. We've had some big outages and it's due to the fact that we haven't found the database they use is all that stable. I think they've realized that themselves. We're probably not the only customer who has complained to them about that. They're realizing there is a problem with the proprietary database and hopefully they'll be giving customers options to move to different database types. We've had some really positive conversations with Sonatype around that and they've provided us with the support and special services to help us migrate off of that, onto another type of database platform which we have more control over.

The stability is okay. We've had some storage issues just recently, which wasn't anything to do with Sonatype. If the data is moved from one storage array to another storage array, it takes the database offline and, as a consequence, the application goes offline as well. And then it is labor-intensive to bring the service back. 

It all comes down to their database. It's very sensitive — you really have to talk to it nicely and do things in a very controlled way. We have a whole host of applications and databases running across our storage arrays, and this is the only product that really causes any real grief when we move data from one array to another. The real problem is their proprietary database. Once we got off that, the stability, I reckon, will be a whole lot better.

In the last 12 months we've had about four or five major outages. We had some in the evening, which you might think would be okay. Well, that's fine for the UK, but we operate in Manila, we operate in New Jersey, we operate in Las Vegas; we're pretty much all over the world.

We have been very clever in terms of how we take outages and get them communicated. It is one of those heavily used products and when it is down people are quick to shout.

We have about 500 people using it right now.

In terms of the scalability, we don't see any real impacts on our internal infrastructure or our internal networking. It runs really well. If we were to add another 500 users on there, I wouldn't see any challenges either. In terms of user accounts, from my perspective, you can scale it really well. We started with about 20 users when we were going through initial testing and piloting. Then we went straight from 20 to 500 and we didn't even notice.

Technical support is not perfect, but quite good. On a scale of one to ten, it's a seven or eight. They're generally responsive and knowledgeable.

They aren't a ten because it's not always easy to get ahold of them by telephone. In a lot of the cases things have to be logged by email. As much as they are very responsive, on occasions when we've had some real outages, we haven't had the response times that we would expect the vendor to provide for a mission-critical tool. When we do get on and start working with them, the knowledge and attention to helping resolve the problem is really good. In fact, that part is excellent.

We were using the open-source and free version of Nexus. Prior to that we weren't using a competing solution. 

We liked most of the things that we got with the free version. The extra capabilities we got were things like being able to support multiple data centers, a better support structure around high-availability. In addition, the whole aspect of having support at all was also among the main reasons we went for the product. 

The complexity behind the initial setup was due to the infrastructure that we had in place. The overall tool wasn't so bad. It was just adapting the Nexus product to be deployable across our internal cloud platform.

In terms of starting the project, getting it ready for deployment took about six to eight weeks overall. Getting people onboard and using it took a lot longer; to get people migrated across. But getting the platform up and running, from my point of view, didn't take that much time at all in terms of doing all the testing, disaster-recovery testing — everything that we have to do before we can commission a product to enter live service.

We've got it deployed across multiple data centers. Even though we use our internal cloud, we've got three data centers in the UK and one in Gibraltar. We have high-availability across all areas. It only operates out of one data center at any one time, but we've got the facility set up so that if we need to bring it up in another data center, we can.

In terms of the support we got from Nexus, they helped set things off and they did so mammothly. I use the word "training," but it wasn't like, "Come train us." It was more of an educational process. They took us through some scenarios of how we could migrate solutions across, how we would work in it. That was good.

We used the technical resources from Sonatype plus our own internal guys. There was one guy from Sonatype, and an architect and two systems engineers from our side.

We don't really measure the return of investment on this particular tool. It was put in as an essential-tool product. 

I do have a real gut feeling that if we didn't use Nexus Repository, it would affect the productivity of our developers across two cities in the UK, Leeds and London, as well as Gibraltar, Krakow in Poland, and the guys out in Manila, New Jersey and Las Vegas. Being able to have one product that we can scale globally, for developers across our organization, has been great.

One of the challenges we had around licensing was how to deal with anonymous requests. According to the letter of the contract, an anonymous request consumes a license. We had to do some work to get over the fact that any anonymous interactions with the Repository product had to be put back to an end-user account. We discovered this by chance when we were going through the whole licensing situation last year. We have plugged those anonymous gaps now, so we're okay. 

Going back to the scalability, when we had anonymous connections in there, we probably were running at about 5,000 and there were no issues.

I don't know whether we get a great deal or a bad deal compared to other companies. I've not done my research on that. But in terms of the price point that we're charged, I know the people who actually sign the checks for this and they're happy to pay — if anybody's ever happy to pay for anything at that particular level. So the pricing is fine.

If you run it through your own infrastructure that's the only additional cost. If they could do a software-as-a-service product, we'd probably take it, if it was something that could scale and integrate into our pipeline. We're certainly having a really good conversation with people at GitLab right now around that very thing, around software as a service, rather than having to build our own platforms and the whole management around that. We're cloud-first as a business organization, so if there was something that they could do better, it would be to provide that SaaS-based solution. I don't know if it's available in other countries, but it's certainly not available in the UK.

We didn't look at any of the competing products at the time because we were happy with what we're getting from the open-source product. And we were happy with the conversation that we had with Sonatype around their Repository enterprise product. So we went with that.

Talk to Sonatype about how flexible they can be around their licensing. We did purchase 500 licenses, but initially we were around 20. Rather than paying for the whole thing, I would say, "If we commit to the 500 over a particular period of time..." and have that conversation about what a realistic ramp-up would be. See if you can be charged for the number of users you have, rather than paying for 500 users but only using 20, which is what we did. It wasn't an effective use of money at that point. If I was doing it again, I'd have a better commercial conversation with them around how we could ramp up the costs over a defined period of time.

One of the biggest lessons we have learned is don't underestimate how much developers will potentially like the product. As soon as we started testing it, we had developers all over our organization really wanting to be part of it. And that's why we ramped up so quickly. We wondered whether we would cause all-out war at one point. We had a few minor speed bumps along the way but nothing really critical. A lot of it was about account permissions and those kinds of things. But other than that, it went really smoothly. The lesson learned is to make sure that you keep a touchpoint with your account management team.

And as part of any type of initial project, I would certainly get one of Sonatype's technical guys on point. We got somebody to work with us to give us that initial induction training and supporting us by checking out the solution definitions that we put together to deploy Nexus Repository across our own structure. We worked really closely with them and that is one thing I would recommend, unless you've got some great Nexus skills in your organization. We didn't look at other systems integrators to work with us. We went straight to Sonatype.

Initially, we had the open-source, freeware version and we had lots of different things like Docker repos around it. We've consolidated that down. We've got the enterprise version of Nexus now. We use it as a consolidated product for all teams across the business. We use Nexus IQ as well to provide that layer of security around it. We're not averse to using open-source repositories and pulling them down. But due to the level of requirements in the organization, we have to have adequate security controls in place, so we use that. I'm not a security tech expert by any stretch but it helps us when we use open-source.

In terms of the solution integrating well with our existing DevOps tools, I would say it does, but with a bit of caution as well. It's getting better. In terms of our pipeline that we use to deploy applications out there, we have integrated with Jenkins to help deploy through some kind of built pipeline. It takes a little bit of developing on our side to get that working properly and effectively.

As for maintenance, we keep things up to date. It sits inside what we call an infrastructure cloud tooling team. That team consists of about six engineers but it doesn't take six engineers full-time to maintain it. It takes about one day a month's worth of time to maintain at most. It's not high maintenance at all. It's when things fail then that it becomes a bit more intense. But overall, when things are running really nicely, then it's hardly any effort at all.

I would rate Nexus Repository at eight out of ten. Once we move it to one of our own internal databases, as opposed to using the proprietary database structure, that will probably move to a nine or a ten. It's an excellent product overall.

We are primarily using Nexus Repository Manager to store the components we are building and to share them among our teams. We are also using it to get a cache from older, available public repositories which we need to build our projects. 

Regarding Nexus IQ, we are using it mainly to scan our projects to see the security vulnerabilities that may be occurring in our products.

Regarding Nexus Repository Manager, using the product has allowed us to have an official and strong repository that is able to store and to manage access rights regarding the sharing of our components among the different teams. We have teams spread across multiple sites in multiple countries.

Regarding Nexus IQ, it has helped us a lot with the management of our OSS licenses and with our knowledge of the licenses and the vulnerabilities. It has also helped us with knowledge of the libraries that are embedded in our products and to build a bill of materials for our projects. In this regard it has been very relevant for us.

We have found the tools integrate well with our existing DevOps tools. In fact, we built our DevOps tools over the last two or three years now and, as both Nexus Repository Manager and Nexus IQ were already available when we started to build our development chain, we had the opportunity to integrate them fully into our build generation. It's been of high value for us. We have gained a lot of time by avoiding old installations and all the sharing management is provided by Nexus Repository Manager. As we already used the tools, we built our DevOps around them.

In terms of open-source intelligence and policy enforcement across our SDLC, before using Nexus IQ in particular, we were struggling to provide a bill of materials for our products. It was up to the development team to maintain the list of dependencies that were embedded in the projects. We know that, with the human factor, sometimes some libraries were forgotten in the list. We also had some problems identifying the licenses of the difference embedded libraries that were in our products. That could have resulted in legal problems when we deployed our products because we had some licensing problems. Since deploying Nexus IQ, we have deployed and customized the policies for our company.

We had a big gap, and then a big increase, in knowledge of our tools and also in our knowledge of the licenses that are embedded in our products. We have all the knowledge needed to be able to waive all the policies and programs that we may have on our products. It's really a big benefit for us deploying Nexus IQ.

Finally, it has increased developer productivity across several projects on the order of ten to 15 percent.

The most important feature of Nexus Repository Manager is the storing and sharing of components. For Nexus IQ, it's the scanning of projects and the rating of vulnerabilities and license violations that we may have in our products.

We have been using the two solutions two for several years now and we are quite satisfied with the data quality provided by the products.

One of our main concerns would be about plugging Nexus IQ into JIRA to be able to automatically raise issues whenever we have a policy violation in a scan.

The second main feature that is missing in Nexus IQ is the ability to explore the history of the different reports that have been generated for a given product. For the time being, in the Nexus IQ UI, we are only able to browse the latest reports that have been generated for a given product. It would be really useful for us to be able to go back in time by browsing through the reports and to have a tool that would give us the evolution of the metrics. 

Another one of our concerns, also regarding Nexus IQ, is about being able to manage the different versions of a given application within the web UI. For the time being, Nexus IQ is not able to manage the different versions of one application. We can define different applications that match the different versions of the product, but if we waive a policy for a given application, we are not able to spread this waiver across the different applications unless we scope it at the organization level. That is something we won't do for the time being because our organization does not permit us to do so. It would be a very helpful feature for us to be able to manage the versions of a different application within the web UI.

It's really stable. We have had no stability problems. The main problem we have is more the stability of our infrastructure rather than stability problems with the application.

For Nexus Repository Manager, we are currently in a process to scale it to different sites. When we first deployed the application, we only deployed it to one data center. Now we have the need, more and more, to deploy it worldwide in order for the teams to be able to use it locally. For us, deploying it worldwide is really simple because we deploy the different applications on the different sites and then we can proxy the different repositories.

For Nexus IQ, for the time being, we don't have any problems with scalability because we only have one server available for the whole company.

Technical support is very efficient. All the answers are provided very efficiently and very quickly. I have the feeling that support tickets are really of concern to their team and that they wish to provide the best support they can to the supplier. It's very comforting to know that there is a support team that is really listening to us and able to provide solutions very quickly for our problems.

We didn't have any solution before Sonatype.

The initial setup was really straightforward. The first setup of the product was done by me. We did some tests on a server and I was able to do it quite easily. Then I wrote an operating model to be able to repeat it and we provided it to our infrastructure provider. He was able, really easily, to provide a production server with our operating model. It's really straightforward and easy to set up.

For Nexus Repository Manager the process was done via a number of steps. First, we deployed a Nexus OSS and then we deployed Nexus Pro. For both steps, it took about one year to deploy it for the whole company. Regarding Nexus IQ, it also took about one year to be deployed because we started by selecting the tool from among the different tools that were available in the market. Once we decided on the tool, we took some time to test it deeply and then we deployed it.

We use a bottom-up implementation approach. We address the requests made by the business and R&D teams. Our implementation was done following this process, meaning that the development team raised a new requirement to be able to manage and share components. We then studied the different products that were available in the market. After the research, the implementation was to do it in an integration server to be sure that the application could be set up with our constraints and used properly by the teams. Once there was approval that the application could be used by all the teams, it was deployed into production. The implementation was the same for both Nexus Repository Manager and Nexus IQ.

We didn't use any consultants. We were directly in contact with Sonatype for the deployment. Sonatype helped us with the deployment of Nexus IQ, although not with that of Nexus Repository Manager.

The product team has seen some return on investment, because they have avoided some vulnerabilities thanks to Nexus IQ. They have avoided legal problems around the licenses that are embedded in our products, by raising policy violations during scans.

Nexus Repository Manager Pro is quite affordable because it's about €100, per user, per year. Purchasing licenses was not really a big issue for us. Regarding Nexus IQ, it's much more expensive. We purchased 250 licenses and they cost us about €120,000. We may increase the number of licenses, but we have to be careful about the number of licenses we are going to purchase because they are quite expensive.

For Repository Manager we did a comparison with Artifactory. Regarding Nexus IQ, we did a comparison with Palamida which is now Flexera. We also did a comparison with Black Duck.

Before deploying Nexus Repository Manager, really focus on the architecture that will be deployed. It will impact all the users who will have to use Repository Manager, especially if they are quite far from the central server. Think about deploying Nexus Repository Manager locally in order to help. Local users get their information faster and in a more efficient way. Regarding Nexus IQ, I would say the opposite: Try to be as central as possible and to have the fewest Nexus IQ servers to meet your needs, because the more you have, the more you will spread the information, and the less you'll be able to capitalize on it in only one server.

I would advise different ways of deploying them. For Nexus Repository Manager it is preferable to deploy a lot of servers locally to help the teams work faster, while for Nexus IQ, preferable to deploy only a few central servers.

For us, it's really difficult to say if the solution has improved the time it takes to release secure apps to the market. What is important is the cost of the quality, or the cost of the lack of quality, in a product. Calculating it would require calculating the cost of the maintenance of the different projects if we hadn't deployed the application. It's really difficult to put a number to this question.

For the time being we are not using grandfathering because we just upgraded to release 64 a few days ago. In addition, the Success Metrics are used by projects. I know that they are quite useful, but I have no feedback on this as I'm responsible for the deployment and the routine maintenance and support of the application. I'm not directly involved with the project lifecycle. The solution does not yet block undesirable open-source components from entering our development lifecycle because we do not use the auditor feature. We may use it in the future if we manage to have stronger policies regarding our OSS libraries. We are not yet at the stage of automating open-source components. We are still doing it manually, but we are working to make automation available soon with other tools such as JIRA, etc., to raise and to address all of the management policies that we have to handle in our products.

For Nexus IQ we have purchased 250 licenses and we currently we have about 200 users worldwide. We have purchased 450 licenses of Nexus Pro and, for the time being, we have about 200 users. For Nexus OSS, taking into account all the users, we have about 2,000 or 2,500 users. We are currently increasing our infrastructure worldwide for Nexus Repository Manager. And for Nexus IQ, we may have to increase our number of licenses in the coming years to be able to address all the needs of the team. Nexus IQ has more and more success because it's very relevant and the team is more and more eager to use it in their day-to-day jobs.

For deployment and maintenance, I am in charge. I am helped by our infrastructure provider, which has a team that is dedicated to all our applications. For about 90 percent of the job I'm the one, and when I need to do upgrades or involved maintenance, there are two people.

I would rate both Nexus Repository Manager and Nexus IQ at seven out of ten. We're still missing some features in Nexus IQ which would really benefit us. In Nexus Repository Manager there are some features and some repository formats that are still not supported by Nexus, but which could be supported by Nexus. That would help us a lot in our development. That's why I don't rate them at eight or nine out of ten.

We are using Nexus Repository as a Java repository for our libraries.

We cannot host proxy libraries because we don't have access to the internet. We're downloading libraries manually and then uploading them to our Nexus repositories. That's the current approach. We not only upload open-source libraries but also our own libraries that we developed.

On the hosted repository, if a team inserts a version of a library, say a Spring library, it becomes available across the organization. If our organization has between ten and 20 development teams, if you upload one library it becomes available to everyone. That helps the speed of development.

Or, for example, with the infrastructure, we have to bring our software version to a certain level. Let's say decision a decision has been made that every everybody is moving to Spring version 5.0. Our DevOps team uploads the library to Nexus and then it's available across the organization.

It improves productivity.

The core features are the most important: We can host libraries, upload them, and they can be used across multiple teams. The hosted repository is the primary feature we're using.

When it comes to the library uploads, for Java libraries it's very easy. You choose the .jar that is to be uploaded. But when it comes to uploading NPM libraries, JavaScript dependencies libraries, it is a little bit of a convoluted process. They need to improve uploading libraries for NPM-type repositories. There is good room for improvement there.

It's pretty reliable. Again, just the way the organization is set up, we do not have access to the internet. We don't pull the libraries from outside, through the proxies. We are uploading them manually. But it has been pretty reliable. The only issue we had was our infrastructure setup. With the disk allocation, we have run out of space. That's the only problem we had. But as far as the reliability of the product goes, it is fine.

It's scalable. For our organization's needs it's fine. We have not run into any issues where it caused performance degradation.

There were a couple of issues that we needed help with, that we raised with Nexus customer care, but the response was pretty fast. It was an excellent experience.

We did use Artifactory, it's a competitive product. Before, our division was part of a different organization and that organization had the ability to use outside, hosted repositories. So we could go to Maven hosted repositories outside of the network; truly open-source. Artifactory was only used certain solutions. It was a different scenario.

Nexus provides more capabilities when it comes to hosted and proxy repositories. This was the primary reason we switched.

The initial setup was pretty straightforward. We worked with the Sonatype customer care team. I was not involved specifically in the installation process. Our infrastructure team and DevOps teams were involved in it. But it was fine. It was not a big issue. We had to use the Nexus setup, provided by default, and that was a good feature. As we matured our process, we brought it under our own security management system, as far as the management roles and responsibilities go.

I was involved in the implementation strategy, but not in the physical installation, running the files. I was involved in the selection of the product and the features that were going to be used and how it was going to be set up initially. Our DevOps and infrastructure teams took it from there.

It's all about productivity. There is tangible productivity there. The speed of development is faster.

Also, if you develop a new team and all of them need the same library, you don't want every developer going to get this library. It's uploaded once and it's being used everywhere.

There were not that many competitors in this space. It was between Nexus and Artifactory. It was a pretty straightforward decision.

Try to leverage most of the feature set. The security scans are a great feature. When the open-source libraries are downloaded, Nexus can provide an automated solution to certify them for use. It might be a good idea, as well, to make this product part of the build pipeline, so you don't have to build every time.

In terms of managing binaries, build artifacts and release candidates across the DevOps pipeline, we are not using Nexus for checking our artifacts in the build pipeline. 

We do utilize Nexus if I create a utility library in a project and this library needs to be used across ten other projects, ten control systems. If it's code developed by us as a reusable component, then yes, we will develop the code so that it will be checked out by the source control system, and the produced .jar will be uploaded into Nexus. It will become available across the organization, but only as a reusable component. In that case, the reusable component becomes available as part of the build pipeline downstream system.

We don't use the solution for open-source governance.

Right now my role is an application architect so I'm part of the development team. In the capacity which we are using Nexus Repository it's doing the job. The area in which I was involved in as a developer, I needed certain libraries. I first had to check if they were in Nexus. If they weren't there I would have the problem that I need to get them in there.

Still, it's a good product. There are a lot of features our organization is not using. Many of them are security scans as you set up open-source governance. As you upload libraries, Nexus offers to scan them and certify the dependencies. We don't have that. But we're covering this by the static code analysis, outside of the Nexus. That's where we are compensating.

In our organization, about 100 people are using the solution. Most of them are developers. We have projects where we specify our Maven or NPM dependencies. Most of our people are clients of the system. Then we have our DevOps team which is comprised of five people who are actually managing the content that's being uploaded to Nexus. It requires very minimal maintenance, which is done by our DevOps team. And we have our infrastructure team that does the hosting. It's pretty stable and reliable and there is not much involved in the maintenance.

It's a great product. I give it a nine out of ten. There is always room for improvement.

We are using this tool for our Java, .NET, AngularJS and Node.js. Apart from that, we have recently built a solution to utilize this tool for Docker images as well.

The first good feature is the searching capability. They have recently really improved it. When I started using it, their search was quite slow. They have improved in that area very effectively, and I really like it.

The second valuable feature is that in a single tool we are managing multiple central repositories. The more support we have, the more the tool will be effective because we are able to manage multiple requirements from multiple domains in a single tool.

Initially, when I started using this tool, I was mainly using it for Java. Then I onboarded .NET, then I onboarded JS. And about six or eight months back, I onboarded Python. And I am about to onboard Docker. The availability of integrations allows me to do this.

Of course, we use this solution to manage binaries, build artifacts, and release candidates across the DevOps pipeline. I can't say how our company is doing so, that's company information, but we are using it to manage artifacts across our pipeline, starting from the lower environment and ending in production.

One feature that needs changing is their pricing model. They are charging a huge amount. The way they charge it's too much.

In addition, they should have some feature where we can move a specific repository from one instance of Nexus to another instance of Nexus. As of now, this feature doesn't exist. With the recent upgrade, when they moved from 2.x to 3.x, they made a couple of changes in the backend regarding how data is saved. That, again, makes it a bit difficult to move the changes. So the feature that I would suggest is the capability to move repositories that people have configured in their systems from one instance to the other. If they had this feature, it would be very effective.

It's reliable, of course. That's why we have been using this tool for the last eight years.

It is stable, but one thing that's a drawback is that, whenever they release a new major version, like 3.12 or 3.14 or 3.15, what generally happens is that we wait for at least a month or so before upgrading to that version. Recently-released versions are definitely not stable, and they definitely have room for the improvement there.

The scalability is effective, but it's not as effective as other tools available. Currently, they are only supporting a single data center. They should have the ability to support multiple data centers. That is actual scalability and, in effect, high-availability.

For example, if I have three different instances and I want to maintain high-availability and the scalability of my tool, it needs to be scalable across my DCs, rather than on a single DC.  If that single DC goes down for some reason, then my tool goes down.

If I have ten servers being maintained in a DC, I have to maintain ten others in DC2 and ten more in DC3. If DC1 goes down, I have to bring DC2 up with all ten servers. That means I'm managing 30 servers, where I could be managing ten.

And they should have the capability for automation to refresh from one instance to the other.

Technical support is effective.

This tool was here when I joined the team.

The setup was very easy. The deployment took somewhere between 30 minutes and one hour. The install takes about 30 minutes and the rest is the upgrade process. The time for upgrading depends on the data, if there have been multiple changes. But the deployment process should not take more than a half hour, and that's on the high side.

We did it by ourselves. We just went ahead with the documentation and tried to understand it. If we had any queries, we just raised them with their support team, got them clarified, and then moved ahead with the upgrade. Our internal team was comprised of three people, including me.

It's expensive, so the return on investment is not that much.

One thing about this tool that I found difficult is that it's quite expensive. They are charging around $110 or $120 per user, per year. It's quite expensive in comparison to the other tools available in the market, not just for these requirements but for other requirements as well.

Those tools are very extensively used but they are charging much less compared to Nexus. And there are a couple of more tools that Sonatype has that are even more costly when compared to Sonatype Nexus. Those should be available by default in the tool or available at a much cheaper cost if we're already using one of their tools.

There are a couple of solutions that I have used in the past, before using Nexus. They're as effective as Nexus. When I joined the team, they were already using Nexus and it was being used very effectively in the company, within our team, and across all the different users. I didn't see any reason to ask that we go ahead and switch a different tool.

If you have the ability to implement this tool within your team by yourself, go with the open-source solution that they have, rather than going ahead with the paid solution.

I started with the 2.2 version but two weeks back I upgraded to 3.15. Before that, I was using 3.14 and prior to that I was on 3.9.

The clean-up policies have been improved: How we manage our changes, how we manage our artifacts, how much we need to keep, and how much we want to remove. That has effectively improved. In addition, slowly they have onboarded multiple technologies. As I mentioned, I started just with Java and I am now supporting six technologies on this. Three of them have been onboarded in the last one-and-a-half years.

They are improving a lot in almost all areas. With every release they have made a couple of changes. Searching was the main capability that they needed to improve and, recently, with the latest upgrade that I did done one month back, they improved it a lot. They have really made the search very fast.

We have a license for about 200 users and we have around 100 to 150 users. We have a spare of fifty so that if we increase we can cater to that. I am not able to share the roles of our users. Usage is quite extensive and is increasing day by day, as more and more technologies are being onboarded.

We are amazingly maintaining it within my team, which consists of six people. But a single person is maintaining it, not the entire team. We have multiple instances of this tool running in our company. Most of the instances are open-source. One instance is a paid instance and that is being managed by my team. That instance is a benchmark for the entire company. The rest of the teams are utilizing the open-source version.

I would rate this solution at seven out of ten. It needs the ability to be available across DCs, across geographies. In addition, it needs the capability to do an auto-sync between the between different centers or there should be some automated trigger for that. They need the capability to move repositories from one instance to the other instance, as well. Last but not least, they should have a bit lower pricing.

At the moment we use it as storage, as a repository, the proxy to internet repositories, and for internal storage of our binaries. 

But we are looking seriously into using it for compliance to policy, for open-source dependencies that may have security issues or contradictory license usage. If certain dependencies do not comply with our licensing policies, then we want to be able to identify them. We are very interested in it to ensure the traceability of our open-source dependencies, to make sure that we are not using dependencies that could cause problems in the future, that could cause intellectual-property issues with the rest of our software. I wouldn't stretch it as far as calling it open-source governance. It's more of a safety check, to make sure that we don't make any mistakes that could cause legal problems later.

It has really sanitized our development lifecycle because we know where people will store their software, and we have a clear naming convention for this. Before that, people would store software in various places, on network drives, on random computers, and it was not obvious where things would be.

For us, the ability to do proxying and federations of repositories is very important. It gives us flexibility. We are among the largest physics research laboratory in the world. With thousands of developers, we need to have good solutions to federate our teams. Those are the perfect features for us, the ability to proxy and to federate. 

It also has very good enterprise integration, so we are able to integrate it with the rest of our infrastructure for authentication, for role management. That is very useful.

We feel that if the product could be configured more easily through configuration files, instead of API calls and databases. That would make it easier to integrate with other DevOps tools. This is one of the hurdles that we encountered when we tried to integrate Nexus 3 with our OpenShift installation. The need to manipulate a dedicated Nexus database, instead of being able to generate configuration files, was a bit problematic.

The inclusion of repositories that are currently supported by the community would be helpful, if possible. In particular, I'm thinking of Debian repositories.

Otherwise, we don't have any request for large features because it's already a well-featured product. Everything else is included already. We are quite happy with the feature set.

We are very satisfied with the reliability. 

With Nexus 2 we have been very happy. For Nexus 3, which we deployed on top of OpenShift, we've had some issues with the storage, but I strongly suspect this is not due to Nexus itself. It's mostly due to the infrastructure we used underneath. It could also be that the product is not tested and the quality is not verified on cloud infrastructures like OpenShift. To be honest, I haven't read about it. But for us, I believe the problem is due to the infrastructure, not so much the product.

That being said, I feel that Nexus 3 is generally less stable than Nexus 2. It's more picky with, for instance, authentication. If you're not authenticated anymore, the user interface is not very friendly to you, and it tends to kick you out or lose your data. More could be done in that area. For instance, with Atlassian products, when you get kicked out due to authentication expiry, you still have a chance to recover what you were working on. Maybe the same could be looked into for Nexus 3.

If you deploy a single instance, it scales very well due to the storage options that it offers. I can't comment so much on the performance because we have never had more than 100 users using it.

But to scale up, to build a federation of Nexus instances, like we do here - we have a big organization - I don't feel that it's very easy for the same reason I mentioned earlier: the lack of configuration through configuration files; that you have to call an API and manipulate the database to configure Nexus instances. I get the feeling from our admins that it's not easy to scale up. They don't feel confident instantiating tens of these or hundreds of these.

Sonatype's technical support is excellent: Very fast response time, they're very knowledgeable. They know exactly what to advise us. They're very good.

In our team, we did not use another solution. Before adopting Nexus we used just static websites that we copied files to and indexed manually. There was no other solution before that.

In other parts of the organization they used Artifactory. They're switching because Sonatype is just more manageable. It offers more types of repositories that may not be supported in Artifactory, and the search facilities are better in Nexus.

The initial setup is simple if you are a small organization, if you're setting up one instance.

If you want to make this reproducible, for instance, you want to make templates to be able to offer the ability for an entire community to deploy their own instances on demand, then it becomes much more complex. One of my colleagues had to deal with this, and he has written a paper about the problems that he encountered that he wouldn't have encountered with other products like GitLab or other commercial products. 

For a single instance, it's a perfectly easy and comfortable process. If you want to scale up it's more difficult.

Our deployment took a year, but it was not due to technical problems. It was more like scheduling delays and organizational changes. In total, it took three or four weeks to get something working and be ready to offer it to the organization.

In terms of an implementation strategy, we rely on OpenShift. It's a Red Hat product, and now I think it has been acquired by IBM. But it enables your community to request a new service on demand. Our strategy was to make a template out of Nexus 3 for OpenShift, so that we could then make it available to all our users and developers for their own purposes. Then we had to ensure that it integrated well with our enterprise resources, authentication servers, or single sign-on facility. That took some effort.

After that, when we talk about strategy, OpenShift dictates, more or less, the strategy you have to adopt to make it available to your users. You're quite well-guided by OpenShift to on what to do next. Now the template is available to all users. They can just go to the catalog of templates, click on Nexus 3, and they get an open-source instance.

We had an internal team dealing with it.

It's hard to quantify because we didn't have any processes before. We started from zero. We spend less time chasing software, and that translates into more productivity, but I don't have a KPI to share.

We are quite lucky because the founder of Sonatype visited us in 2008 and granted a permanent free license to us as an organization, because it's a laboratory that does a lot of research, and it's in the public domain. He felt it was a good gesture that they could extend to us. I can't comment on the pricing.

My advice would be to think about the scalability. I would really advise everybody to go for it, to go for having repositories in their organization, to make their software and even hardware development more organized. Go for it, adopt one.

We are using the latest version of Nexus 2. We are in the process of rolling out Nexus 3 on a much wider scale.

In terms of using the solution to manage binaries, build artifacts, and release candidates across the DevOps pipeline, I would say yes, we're doing so. We're not as well-developed in terms of DevOps as other organizations, but we are certainly working that direction, and we use it for the DevOps lifecycle.

We use GitLab and we also use Jenkins CI, and with these two products we are able to very simply deploy to Nexus Pro and perform staging operations, to make sure that, before we release to production, we can ascertain the quality of our software. We don't necessarily automate the deployment to production now, it's still a manual process. But we are working very hard to complete the DevOps loop.

In terms of open-source governance, we should be much more proactive. Nexus is definitely a tool that makes this possible in an organization - to be proactive about your open-source choices. It's less critical in our organization because all our research is open. We try to stay away from intellectual-property problems. But on occasion we still have to pay attention to that and Nexus, with its advanced governance features, would have been a real time-saver if we had it at the time, so we are looking into it now.

The number of developers using it right now is about 200 to 300, but because we're rolling it out to the rest of the organization, making it a much more easy service to afford with OpenShift. The audience could be up to a couple of thousands of developers.

In terms of deployment and maintenance, for a single instance, we need about 10 percent of a full-time person. There are moments where it's very quiet and others where we encounter a problem and we have to take some action. But I it's a very lightweight solution compared to what other commercial products or open-source products could cost, in terms of maintenance.

I'd give Nexus Repository a nine out of ten. A perfect ten would have better support for configuration, for templating on the cloud infrastructure.

Our primary use case is as a manager and storage location for open-source software components. We utilize the Nexus repository to store safe open-source components that our developers can utilize in their applications, as opposed to their going out to the internet and getting potentially unsafe versions of the open-source components.

We use it to manage binaries both in the IMR and in staging. Our biggest use of the software, as stated before, is to store open-source software components for user applications. The second biggest use is as a staging repository. We'll stage binaries for changes that are ready for deployment across to a production environment. We'll stage them there so we know they're centrally located. If we want to do any scans we can do them right there before they're deployed to our enterprise.

It has improved the organization in that it has helped us ensure that developers are utilizing the safe, open-source components we provide to them. We know who they are, through the use of the Nexus software, when they took them, and where they're being used. It has helped us to increase the security of our applications.

One of the most valuable features is the variety of permissions you can use on the repository. That helps us protect access to the information inside of the repository.

I would like to see them build in some scanning features out-of-the-box, as opposed to only getting them by buying the add-ons of Nexus IQ Server. I would like to see some level of ability to filter in the tool itself, through scanning the binaries in there.

Thus far, the reliability has been good. I haven't seen any problems with the Nexus software breaking down.

It's very scalable.

Tech support is fine, they're very responsive.

They were using SharePoint sites, file folders on servers. We still using them to some degree. They switched to Sonatype because they wanted to get the increased security portion of Sonatype, known as Nexus IQ Server, but they had to purchase the repository first. They're just now getting the money for the rest of it.

I wasn't here when they did the initial setup, but they did it in a slow manner. They started off with a proof of concept. It took at least a year. It was easy to install on the servers, but the politics and building up users took six months.

It looked like the implementation strategy they came up with was to do the proof of concept, then get some projects to start, and grow it slowly until the value was seen. And then they forced everybody, so they had no choice but to use it.

They used a consultant. 

Using it for the IMR we have a sense of security now that we control what goes out to changes in our enterprise.

It seems like a fair price, based on other software solutions I've purchased.

There were other options. Veracode was one of them.

Make sure you know how you want to use it, and set up your rules, processes, and policies before you implement it.

Their customer service is pretty good. Their software does what it says it does. They've got another component add-on we're looking to purchase that will assist us. Sonatype has business relationships with other companies which sell their software, and their name is known in the DevOps world. They're a stable company and have a stable product.

In terms of the number of users using our Nexus Repository, just about every developer who programs in Java has to use one portion of it, and we have about 500 of them. At least 300 users in the IT community use it. For deployment and maintenance of the solution I've got three people. One of whom is on contract. They're involved in maintaining the software, keeping it up to date, configuring it for better security, training users, etc.

We are looking to increase usage up to 500 people when we get the next component.

I'd give the product an eight out of ten. If they want a ten, they should cut their price in half and they should increase the security capabilities out-of-the-box.

We use it as a repository for build artifacts. We have 300 developers and most of them use Nexus Repository to do their builds.

They are mostly stream-mode applications, as well as front-end Angular applications. We definitely pull down most of the main dependencies, binaries, build artifacts, and release candidates.

We use it for open-source governance, that's one of its every day uses. We have so many applications and so many services.

If there are any issues in build security, it can pick them up straight away.

We had some issues with the container platform, but we raised a support ticket and it was sorted out for us.

So far we haven't had any issues. But when we go into the container world we might, because we haven't gone into the container world yet.

We've had no issues, as of now, with the scalability. We have been licensed for 250 users for the Repository and we haven't found any issues. The users' roles are DevOps, pure developers, and some of them are testers. As for deployment and maintenance of the solution, that comes under DevOps. Some of the DevOps guys are supporting the platform as well as doing the builds and setting up the pipelines, etc.

I talk to Camden from Sydney, and he's been helpful. I've never had any issues with him. Amar has been a very good support resource as well, including help with the documentation.

They were using Artifactory before, and they were not happy.

Nexus is pretty straightforward. It's not complex. We didn't have any issues. The deployment took a couple of hours from start to end.

In terms of an implementation strategy, we started off pretty simply, just setting up a server, making sure that the server was connected to the internet. We then pulled everything from down from the internet and set up the Nexus server. We then gave proper access to the developers who wanted to use it.

Our deployment was entirely internal.

We just got a license for 250 at the end of December, so people have just started using it recently. Previously, the guys who were using it were using the open source license. So we don't have any evaluation of ROI yet.

I'm not sure if they evaluated other products. But people have used Nexus a lot and they are quite comfortable with it.

It's definitely worth looking into as a DevOps tool, which can be integrated into the build pipelines.

We use the Nexus Repository but now we are definitely planning to increase the usage.  We are looking at the Lifecycle and Firewall products as well. This is the first time we have started looking into this aspect of Dev Lifecycle Ops. That's in the process of evaluation and, once all the evaluation is done, we will consider it. The build Repository is definitely the main application but to make sure whatever we do is secure and compliant, the Lifecycle is looking to be more important.

I rate the product at eight out of ten. The two points are because it's still somewhat unknown, we haven't used it intensively.

The primary use case is to store good artifacts our company has produced and proxy external artifacts to help reduce the outgoing traffic and to filter specific components which are known to be vulnerable.

First of all, we now have a well-documented process on where to find any build result produced within the last two years. This documentation has been made available to the whole company. Previously, we had several platforms. The results were sitting in some continuous integration system while build results for other teams were hosted on a shared drive, etc.

It has helped us reduce the effort in maintaining several systems. That is a huge benefit. We only have to maintain one system and we can use this system concisely across several locations. It has saved time tremendously. As a rough approximation, I would say we only use 20 percent of the administration time we used previously, so it's saving us 80 percent. And storage management has been simplified so we have been able to reduce hardware resources and backup processes. On the hardware side, as a guess, we have saved 30 to 40 percent compared to what we used previously. It's very substantial.

The primary feature is that I now have the ability to provide a central platform for storing build artifacts; a concise way for any project team to store its build with us.

I'm looking forward to getting things like automatic governance done, but the bigger priority I'm waiting for is a feature to have hot publication between several Nexus instances. That's more important for me right now because in our company we have several locations distributed all over the world, and each location is producing its own artifacts, sometimes for the same project. I really would appreciate a scenario where the developers could provide their data to the local repository and it would be hot-replicated to the other repository instances. That would be the most important feature for me right now. As far as I know, it's not available, but it's on the roadmap.

There are also some minor usability features which are changing from version to version, but that's always progress in the correct direction. They recently added the group artifact version (GAV) search. That was something my users really requested for some time.

The next big feature my users request is a remote search so if you have a proxy repository the search can be performed within the local Nexus instance. That would be a major improvement. 

I think these requests are already known to the Sonatype and already on the roadmap.

Also, the code snippets for integrating different artifacts: Currently, they are available for Maven dependencies. We really would appreciate it if they were available for other build systems. That was available in Nexus 2 and it is already on the roadmap, but I'm not sure what the priority is.

I haven't had any negative impact so far, so I'm very confident using Nexus in terms of its reliability. Everything that has been a system issue has been some misconfiguration on our side. Nexus is a very robust system in my opinion.

Currently we run with a hot failover system in each location, which is provided by a load balancer. We only have single-node instances running in each location with the one hot failover node, in case of hardware issues. But we haven't had any problems in the last two years we used Nexus Pro. It's just for our peace of mind, to give some robustness to the system, some additional availability.

Initially, we started off with about two gigabytes of RAM. Based on the size of our system we had to increase that to the current configuration of eight. But it's really not a system that consumes high resources. That's one thing I like about the Nexus installation. I used to evaluate Nexus versus Artifactory and, in my opinion, Artifactory consumed much more resources.

Technical support is very prompt. If we have a question we get the answer within a few hours. Within less than two hours I usually have a thorough answer. If it's a case where we need to do a conference call, they are very polite and helpful at that point as well.

The last issue I had was an authentication issue. It was a basic question on how to perform some login strategies for our customer accounts. I wrote to my technical contact there and, within a few hours, I got a reply. We scheduled a phone call just to reduce the amount of time writing emails. I like the way they get to the root cause of any issue customers have and solve the issue with their best efforts.

We started off with several, local, self-deployed strategies like shared devices and web servers hosting some results. We even stored build results on a source code management system.

When I started with Nexus, I thought the setup was complex, but nowadays I think it's quite straightforward.

When I first implemented it, I really needed to gather the basic idea of the repository server, and the guys at Sonatype were quite supportive, getting the system set up initially. Now that I know the mechanics, it was quite easy to first perform the migration from version 2 to 3, and I'm really confident that it wouldn't be that hard to perform another setup or to even get any other operator here in our company. I'm really confident in the use and setup of the system.

The initial deployment started off with reading the documentation and then getting things done. It took about two to three days to get to production-ready deployment, including getting all the machines running here our company and IT requests, which were simply waiting time.

When we upgraded from 2 to 3, it was a journey of three hours or so.

For the initial deployment, our strategy was to first have it in our main location. We wanted to provide a demo setup with one instance and this became the de facto leading, master repository. Later on, we recognized that due to some inefficiencies and VPN problems, it would be better to create local instances of the Nexus installation. We then ported the leading system to the other locations and provided a proxy between all those instances. Right now we have three separate instances in different locations and they all proxy each other, so if one of the VPN connection fails, the other two should still be available.

The deployment required me, as the application owner and, for some operational stuff, like repository creation and artifact maintenance, about four backup persons who are capable of replacing me.

The maintenance takes about two hours a month. Upgrading from one version to another takes a few minutes. I really would appreciate a live update with zero downtime, but that's currently not on the roadmap, as far as I know. It will be there eventually.

We had a contact at Sonatype who answered questions when they occurred. I had a talk with him for about 15 minutes when I thought about the transition process to the other locations. We basically operate the system on our own but get instantaneous support from Sonatype if needed.

We haven't really evaluated ROI, but we recognize that the time for maintaining systems and providing solutions for the use case of storing and retrieving artifacts has been reduced by about 80 percent, as I said earlier. And we have reduced several hardware systems for storage of artifacts. 

In my opinion, the most important part is that we can use the setup of this Nexus repository server to get our developers to learn new build systems. There has been an educational purpose as well which, in the end, empowers them to have knowledge of new technologies, and to get started quite quickly. If you think of migrating some thousand lines of Ant code to a Maven project, once this is done the project will run for several years. Maintaining several thousand lines of Ant releasing might become a burden eventually.

In my opinion, the pricing is very fair and very customer-oriented. It's much better than any other tool I have used so far.

We began to evaluate different Maven-based repository managers, so we had Artifactory, Nexus, Archiva from Apache, and IBH SYSTEMS. After an evaluation period of three to four months, we decided to go for Nexus, as it is one of the most important players in the field. We also had a vision of incorporating Docker images and the like, which was only supported in Nexus at that point of time.

Another difference between them is that Nexus provides Enterprise Support. That is available with Artifactory, but the biggest argument for Nexus was that you could use stuff like Docker proxying, Docker repositories, proxying NPM repositories, etc. We needed a system that's not only for the Java toolchain, but also for C#.

Our company is about 25 years old. When we started developing stuff in Java, we didn't have much tool support and, as we are a company that integrates other systems, we basically built our own tools. That's quite nice if you can do it, but it is always a burden to maintain. That was another aspect we had in mind. We wanted to reduce the maintenance of self-created systems and to get our administrators to use a standardized toolchain. That really helped to reduce their efforts and keeps us up to date with current developments in the business.

As you know, software development is something that is changing every now and then, so every month you have to be up to date with some new framework. It's really hard to keep that up if you try to build your own build-and-development chain. So it's very nice to have several things that are already done by other companies. The storing and distributing of artifacts was really one burden that didn't provide any practical business value but required loads of effort. This is one thing that the Nexus Repository Manager addresses very well.

We use Nexus Repository to manage binaries, build artifacts, and release candidates across the pipeline. We used to do it with Nexus Repository Management 2, using their staging system. Nexus Repository 3 didn't introduce staging until one of the most recent releases, so we started off with a staging repository where we would publish our "to be released" artifacts, and then provide a release repository so that we could push them using some continuous integration pipeline configured in Jenkins CI system. I'm going to be using the tagging feature they added recently to provide the staging functionality we used to have in Nexus 2.

We don't use it right now for open-source governance because that would require us to rely on the IQ Server and we do not have any licenses for the IQ Server. I do some manual filtering - based on CVE advisories. I exclude some packages from being downloaded, ones I'm aware of that are vulnerable, but that's more or less a manual effort to configure those right now. The governance part is not fully automated, right now, but we are working on that.

We currently run with about 240 accounts on Nexus. There are several developers and several system accounts, but we have a daily login rate of about 160 users.

We are currently trying to force more teams to use the system. There are still some older systems relying on very old infrastructure, which are currently not connected to the CI pipeline. This should change within the next one to two years, and then we will have no system that's not connected when using any dependencies for Maven or NuGet or NPM or Docker. They are the four repository types we are currently running. There is a business rule that no system shall get its artifacts directly from the web. Everything shall be proxied by Nexus. Eventually, everybody in the company will be forced to use the Nexus.

Overall I would rate it at nine-plus out of ten. I'm very pleased using Nexus Repository Manager. And I'm also looking forward, based on the experience that I have had with them and their technical and business department, to adding to our toolchain regarding IQ Server and lifecycle products. That is something I have to sell internally, but I think this will come eventually.