Sonatype Nexus Repository Overview
What is Sonatype Nexus Repository?Nexus Repository is powered by Repository Manager, the same technology engine found in our OSS version deployed at more than 100,000 organziations world-wide. It is Built on the shoulders of Maven, Repository Manager supports all popular component formats and brings your entire development organization together. It includes staging and release functionality that provides support for operations and quality assurance processes prior to production and gives you instant insight into potential component security, license, and quality issues, enabling teams to take corrective action early and quickly.
Sonatype Nexus Repository is also known as Nexus Repository, Nexus Repository Manager.
Sonatype Nexus Repository CustomersGoldman Sachs, Toyota, Disney, Deutsche Bank
Sonatype Nexus Repository Video
Filter Archived Reviews (More than two years old)
- Highest Rating
- Lowest Rating
- Review Length
Showingreviews based on the current filters.
Senior Application Architect at a financial services firm with 10,001+ employees
Hosting libraries that can be used across multiple teams helps improve productivity
What is our primary use case?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.
Pros and Cons
- "The core features are the most important: We can host libraries, upload them, and they can be used across multiple teams."
What other advice do I have?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…
DevOps Practitioner at a financial services firm with 5,001-10,000 employees
We are able to manage multiple central repositories, but it lacks the ability to move repositories between instances
What is our primary use case?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.
Pros and Cons
- "The searching capability is good... and we are managing multiple central repositories."
- "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."
- "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."
- "They should have the ability to support multiple data centers. That is actual scalability and, in effect, high-availability."
What other advice do I have?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…
Architect at a consultancy with 1,001-5,000 employees
Sanitized our development lifecycle, we now know where people will store their software
What is our primary use case?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… more »
Pros and Cons
- "For us, the ability to do proxying and federations of repositories is very important. It gives us flexibility. We are the largest physics research laboratory in the world. With 12,000 people, we need to have good solutions to federate organizations inside our lab."
- "It 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."
What other advice do I have?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…
Chief, Enterprise Automated Deployment (EAD) Branch at a government with 11-50 employees
Helps ensure that developers utilize the safe open-source components we provide to them
What is our primary use case?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… more »
Pros and Cons
- "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."
What other advice do I have?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…
Senior Information Technology Specialist at a financial services firm with 5,001-10,000 employees
If there are any issues in build security, it picks them up right away
What is our primary use case?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.
Pros and Cons
- "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."
What other advice do I have?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…
Senior Software Engineer at SYSTEMA Systementwicklung Dipl.-Inf. Manfred Austen GmbH
Provides a central platform for storing build artifacts, saving us significant maintenance and hardware costs
What is our primary use case?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.
Pros and Cons
- "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 waiting for 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."
What other advice do I have?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…