Sonatype Nexus Repository Reviews

We are using Sonatype Nexus Repository for capturing or creating our software bill of materials, such as Maven, Python, no NPM, and Node.js Repos. They are open-source packages that we've scanned and that we want to keep as is. Additionally, we use it for our snapshots and releases of our own binaries.

The most valuables features of the Sonatype Nexus Repository are you can block any uploads that you do not want. For example, from Maven. Even though someone will try to create a pump file with a package not currently in our repository, they can go and get it, but it won't store it into the Sonatype Nexus Repository and therefore won't be propagated across the enterprise.

Sonatype Nexus Repository could improve by making the experience working with CI/CD pipelines, such as GitHub Action or GitLab better.

I have been using the Sonatype Nexus Repository for approximately 

The stability of the Sonatype Nexus Repository is good, we did not have any performance issues.

I did not use technical support.

The initial installation of the Sonatype Nexus Repository is straightforward.

My advice to others wanting to implement the Sonatype Nexus Repository is to make sure that it supports the language they are developing in. If you're a .NET developer, that would be a difficult language to use. However, if you want to do docker images, make sure you know what kind of docker to do.

I rate Sonatype Nexus Repository an eight out of ten.

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.

Sonatype Nexus Repository is our content repository for the programs we are developing.

It has enhanced the pipeline. It's a critical part of the DevOps infrastructure.

While there are not many features, they're all useful, particularly the ability to store and retrieve content, and to proxy all of the features that an enterprise repository manager should have.

I would like to see multifactor authentication implemented.

The only thing that I would like to see is multifactor authentication. This is a critical feature that must be included.

I have been working with Sonatype Nexus Repository for a couple of years.

We are using the most recent version.

It is a cloud, but it is limited to our company and is hosted by AWS and Azure.

Sonatype Nexus Repository is stable. It's solid.

Sonatype Nexus Repository is scalable, we are able to scale both vertically and horizontally. We haven't had any problems either way.

My current program has about 100 users, but they are not users, but rather a pipeline. The primary user is the pipeline. This solution is used hundreds of times throughout the day by the pipeline.

It's a critical piece of our infrastructure.

Technical support is excellent.

If you have a support license, which we do, it's very good. They are extremely competent, and they know what they are doing.

We have corporate licenses, for  SonarQube and Sonatype Nexus Lifecycle.

I am not sure how long we have had corporate licenses. Sonatype offers several products, including Nexus, Nexus Repo, and Nexus IQ, which I have worked with for a few years,  perhaps two, or three years.

The initial setup is straightforward.

The complexity of the setup varies depending on the type. The LFS type was essentially a three. Other repo types were a ten.

The deployment process was very simple, taking only a few hours.

We are integrators. 

I completed the implementation. It's fairly simple to integrate.

Maintenance requires very little staff.

I can't quantify it, but we couldn't execute our pipeline without it.

It's a corporate license, but I'm not sure how much it will cost.

There were costs in addition to the standard licensing fees. The standard is free.

It was already in place, but I am satisfied with it.

It should be integrated and become a part of your pipeline as soon as possible. The earlier you start, the better.

I would rate Sonatype Nexus Repository an eight out of ten. A score of eight, because, the multifactor is critical. That's why it loses a couple of points.

We use Sonatype Nexus Repository as a proxy for external packages for internet users. It also helps us manage internal packages and works as a repository for container images.

The product helped our organization improve runtime efficiency. We do not have to connect third-party vendors while building external packages or storing container-approved images. It allows end-to-end life cycle accessibility.

Sonatype Nexus Repository has a valuable internal scanner feature. It automatically scans external artifacts, such as Fortify SAST, before storing them in the repository.

There could be more add-on features for the product. They should provide automation for adding container images and artifacts in compliance with security requirements.

We have been using Sonatype Nexus Repository for one year.

I rate the product's stability a seven out of ten. Sometimes, there are challenges in mitigating intermittent incidents. There might be factors such as network issues impacting communication.

We have 20,000 to 40,000 end users for the product. It is easy to scale. I rate its scalability an eight out of ten. We use it 24/7.

The technical support team takes time to respond and depends on the nature of the request. We have to keep contacting them. However, the process to create tickets is simple.

Neutral

I have worked on POCs for different products.

The initial setup is simple if you have access to container images. It is a seamless process for upgrading as well. Everything is well documented on the vendor’s official site. They form regular maintenance to comply with organizational requirements. They have a good maintenance process for updating and addressing issues. We have a team of 100 executives working on the current project to maintain components.

I use the open-source version of the product, which is free of cost.

I rate Sonatype Nexus Repository an eight out of ten. I advise others to update the business continuity plan for components regularly, i.e., semi-annually or quarterly. Use container images for the next migration or maintenance update. They should secure the user interface. Additionally, they should ensure a good storage process and plan a retention policy for all attacks.