Sonatype Nexus Repository Pro (Self-Hosted)

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.

I integrate the Sonatype Nexus Repository with AWS. The Sonatype Nexus Repository offers detailed file information such as SHA and checksum, which is useful for auditing and ensuring file consistency against unauthorized changes.

Hosting, proxying, and grouping repositories in Sonatype Nexus Repository have no impact on development process time and are perceived as very fast. It simplifies version management by storing a consistent library version, avoiding conflicts.

User policies and granular access control, though not integrated with LDAP or Azure  Entra, work well for specific action configurations.

We want to change the AWS credentials into an assume role instead of a fixed credential for authentication, but Sonatype Nexus Repository does not support this feature yet. This is a point of exploration for us.

We installed the Sonatype Nexus Repository using an open-source Helm chart but need to test it for credential-less AWS integration. We may seek support in the future.

One of the challenging aspects of the Sonatype Nexus Repository is understanding its procedures, as job scheduling is not fully explained in documentation and logs are cumbersome and unhelpful for issues such as troubleshooting push file errors.

We have been using the Sonatype Nexus Repository for nine months.

The setup was done using the Helm chart from Sonatype Nexus Repository. The setup itself is easy but configuring background jobs is difficult since they run at specific times and impact performance but cannot be tested easily.

We have been using the Sonatype Nexus Repository for nine months and it has not experienced any downtime or errors, which makes it a reliable solution for our needs.

Because we are using the open-source Sonatype Nexus Repository, it is limited to a fixed zone or region. It cannot be changed to support multi-region or multi-zone deployment. Currently, it does not provide high availability.

Before using the Sonatype Nexus Repository, we used Harbor  to store image files. For artifacts and binary files, we stored them on GitLab . After implementing the Sonatype Nexus Repository, our process became simpler and easier to understand, making it a better solution.

I performed the initial setup and deployment for the Sonatype Nexus Repository using the Helm chart. The setup process required reading extensive documentation about policies, users, storage configuration, credentials, login procedures, and metrics. These aspects were straightforward, but the background job setup was more challenging as we had to wait several days to observe the actions from the background jobs.

We evaluated several solutions including JFrog, ECR from AWS, and Black Duck . However, these options were too complicated and offered more functionality than we needed. The Sonatype Nexus Repository aligned with our vision, so we chose it after testing all alternatives.

I am a customer and end user of Sonatype Nexus Repository. We will examine the code more thoroughly and need to test it first. Since we installed the Sonatype Nexus Repository using an open-source Helm chart, we need to test its integration with AWS without credentials before potentially contacting support.

Our team pushes libraries to the Sonatype Nexus Repository to store them with fixed versions. Before using Sonatype Nexus Repository, we pulled from external sources, which sometimes caused issues with library versions changing and breaking code.

One of the notable features of Sonatype Nexus Repository is the detailed file information provided for stored files, including SHA and checksums.

I rate the Sonatype Nexus Repository 9.5 out of 10.

Public Cloud

Amazon Web Services (AWS)

What do you like best about the product?

I like that it is very easy to use. We are able to simple login to the repository as admins and view all the artifacts that are being used by various proxies and also by various teams. It is also helpful to upload binaries from any server and retrieve them using simple commands. We use Nexus Repository in our daily BAU activities in our devops team.

What do you dislike about the product?

I don't like the fact that there isnt a better UI for viewing logs. When you are logged in as admins and you would like to view and capture logs, we have to manually set the timer and keep scrolling rather than it being automated.

What problems is the product solving and how is that benefiting you?

We are able to centrally store artifacts and binaries required for our project. As a team, it is very easy to access these packages and also get version information effectively. Through this centralized repository, we are able to retrieve these artifacts and also their information and use it for developement or provide support to our project accordingly.

What do you like best about the product?

Fit all my needs for artifact management. Easy to use, flexible, and easy to integrate into our CI/CD processes.

What do you dislike about the product?

Sometimes, it's difficult to understand all the different options provided, and default pricing plans don't always fit any company's needs.

What problems is the product solving and how is that benefiting you?

Single source of truth for our artifacts.

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.

Primarily, the extensive support for a wide range of packages is a crucial factor. The effectiveness of new-age package managers is often determined by the breadth of packages they can handle. In this regard, Nexus Repository Manager 3 stands out for its comprehensive coverage, accommodating a vast array of packages widely utilized across the globe. This inclusivity enables easy access to a diverse range of packages, making it a pivotal aspect of its functionality.     

Particularly concerning OSF-type licenses, while they support a multitude of features, there's room for improvement in the single point transform, especially for grouping. It appears that currently, the grouping functionality is not robust, particularly for Docker images within a group. The support for this aspect seems to be contingent on the license type. For instance, with the Voss license type, there is a noticeable absence of support for this feature. This is an area that could benefit from enhancement in the upcoming updates.

I have been using Sonatype Nexus Repository for five months.

I am, personally, quite satisfied with the stability and would rate it 8 out of 10. 

I would rate the scalability of this solution a four out of ten. The reason being, it's not very scalable, and significant efforts are required to enhance scalability. There are noticeable limitations that need to be addressed for smoother scalability.Currently, there are approximately forty-eight users working with Nexus Repository in our company. As for future plans, I don't foresee a significant increase in the usage of Nexus Repository.

While it's true that there is no explicit support for various license types, the summer type seems to be highly favored and encouraged among users. It holds a prominent position, perhaps earning a rating of seven for its effectiveness and user adoption.

It is easy and I would rate it 8 out of 10.The entire deployment process, including installation, manual testing, and all implementation phases, typically takes around one week but only one person is usually sufficient to handle the entire deployment efficiently.

I can confidently recommend this solution. The main reason is its stability. In comparison to other competitors, especially when I consider alternatives like Project X, Nexus stands out as a stable and reliable choice. This reliability is a key factor that makes me feel comfortable recommending it to other users. Based on its performance, I would rate it 8 out of 10. 

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.

On-premises