I have been working with Sonatype Nexus Repository for more than five years to manage different artifacts in my project.

Sonatype Nexus Repository is used to maintain different private repositories. We create different private hosted repositories wherein we can maintain our artifacts including Java JAR files or WAR files. We create Docker repositories to maintain our Docker images. Helm repositories are created to manage our Helm charts. Additionally, we create Python repositories, pip repositories for managing Python packages, NuGet repositories for managing .NET artifacts, and NPM repositories for managing Node packages. We also use Sonatype Nexus Repository for creating proxy repositories to cache artifacts, so once any particular machine accesses a public artifact from maven.com or npmjs, those artifacts are cached inside Sonatype Nexus Repository, and then those artifacts are served to the different project machines.

These are the primary use cases to manage all the artifacts across different projects. We mainly create hosted repositories and proxy repositories. We integrate these repositories with different CI/CD pipeline tools, for example, Jenkins, and we also integrate them with build tools like Maven. Using the build tool lifecycle phases, we deploy the artifacts to the artifactories. Additionally, we create different users on Sonatype Nexus Repository and assign them specific roles according to the user and job requirements. By implementing RBAC or Role-Based Access Control, we control access to our Sonatype Nexus Repository repositories. We also ensure to set up cleanup policies so that our Sonatype Nexus Repository server does not run out of disk space.

View full review »

I use Sonatype Nexus Repository for downloading packages. My application was Java-based and Spring Boot-based, so I was downloading packages from Sonatype Nexus Repository and uploading the WAR file that was built during the CI process to Sonatype Nexus Repository.

In my CI/CD process, there was a Sonatype Nexus Repository upload stage that was executed after completing stages such as build, Sonar scan, Sonatype Nexus IQ scan, and testing. Once all these stages were completed and the WAR file was built, the Sonatype Nexus Repository upload stage would upload the WAR file of my Java application to Sonatype Nexus Repository. In the deployment stage, I would download those WAR files to the servers.

View full review »

My main use case for Sonatype Nexus Repository was as the repository for storing internally developed artifacts. As a developer while building applications, I pulled dependencies from Sonatype Nexus Repository. Dependencies such as Log4j, Spring Boot, and any other dependencies used in our applications would be pulled from Sonatype Nexus Repository.

View full review »

We use Sonatype Nexus Repository for our internal repository, for image caching, registry caching, and our custom registry. Sonatype Nexus Repository's repository function is definitely the most valuable feature I have found.

I did not test it extensively versus other options, but I can tell you that Sonatype Nexus Repository works in a stable manner. It allows us to have geographical disaster recovery, which was one feature that we needed.

We are using Sonatype Nexus Repository's granular access controls, and we needed to use them because we have several teams. Therefore, it is essential for us, and it is one of the features that we are using by design.

It is a requirement for managing Maven, npm, or Docker, so without it, we cannot do it. You need to have a product—this one or another—you need to have one.

View full review »

I am using the Sonatype Nexus Repository and it's working well with the corporation. I have not purchased the Sonatype Nexus Repository license. Currently, I'm using the free open-source version because its functionality fits the corporation's needs. We do not need to buy for now, but we will purchase it in the future.

I'm using the Sonatype Nexus Repository to store the artifact files, specifically the build files from my company. The project builds into many binary files and images, so I store all of that on Sonatype Nexus Repository. We have retention days for all artifacts. Whenever the server needs to get the binary file, it requests it from the Sonatype Nexus Repository and takes the correct file for deployment. Instead of ECR, AWS has something called ECR and some other services to store binary files, but the Sonatype Nexus Repository open-source is sufficient without any cost.

The Sonatype Nexus Repository is running on AWS Cloud, on EKS as a service. The current functions fit our corporation, and we're presently using it free without the need for a license. However, we plan to buy a license in the future.

View full review »

Our main use case for Sonatype Nexus Repository is managing artifacts and having them in a central repository that is accessible for all our software engineers on the team. In our day-to-day activities, we use Sonatype Nexus Repository for managing artifacts, and it gives us a centralized repository instead of pulling from public Maven NPM registries every time. Our organization has internal libraries hosted on Sonatype, so software engineers pull these libraries from Sonatype Nexus Repository, which solves the problem of engineers pulling libraries from Maven almost all the time.

View full review »

Our primary tool is Sonatype Nexus Repository Manager. We use it for NPM, Maven, and Docker repositories. Additionally, we utilize Nexus Firewall for repository governance. Looking ahead, I'm considering implementing Nexus Repository Manager 3 as an alternative. This would help us manage packages from Nexus IQ Server and support various package formats such as NPM, Maven, and Docker.

We rely on Sonatype Nexus Repository Manager as our main tool, employing it for NPM, Maven, and Docker repositories. In addition, Nexus Firewall plays a crucial role in our repository governance. As we plan for the future, I'm exploring the option of incorporating Nexus Repository Manager 3. This move would enhance our ability to manage packages from Nexus IQ Server and cater to different package formats like NPM, Maven, and Docker.

View full review »

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.

View full review »

It's our building background. We use it as a proxy repository to Maven, for example, and we use it to store our own good results and to bring them into production. So it's a turning point for this.

View full review »

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

View full review »

Our primary use case of this solution is for our CICD pipeline, to build and store our artifacts in the repository. I'm the principal engineer and we are customers of Sonatype. 

View full review »

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.

View full review »

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.

View full review »

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.

View full review »

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.

View full review »

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.

View full review »

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.

View full review »

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.

View full review »

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.

View full review »

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.

View full review »