Sonatype Nexus Repository Reviews

I have been working in the telecommunication industry for the last thirteen and a half years, so my overall experience is mostly in Information Technology, Cloud Computing, AI, Automation, and it is in the telecom industry.

I have been using Sonatype Nexus Repository for more than eight years, where it serves as our centralized artifact management tool in my organization to manage artifacts across our enterprise-based applications. It has been our central platform for hosting, proxying, and managing software artifacts while integrating seamlessly with our whole DevOps CI/CD ecosystem.

Our primary use case of Sonatype Nexus Repository is as a centralized artifact repository, which is used for a wide range of package formats including Docker images, Helm charts, Python modules, NPM modules, Java JAR, and WAR modules.

We maintain various types of repositories including hosted repositories, group repositories, and proxy repositories for our internal artifacts. Proxy artifacts are used to cache internal dependencies sourced from Maven Central or NPM JavaScript repositories. Once an artifact is downloaded, it caches locally and serves internally so that it can be used by various application teams, which also reduces external dependencies and improves performance. Sonatype Nexus Repository is integrated with various DevOps tools such as Jenkins, GitLab, and also with cloud-provided CI/CD tools, including Maven for enabling automated artifact publishing as part of our CI/CD pipeline. We use role-based access control (RBAC) to manage user permissions and policies to optimize storage. Overall, the main use case is to build a CI/CD pipeline and use CI/CD as a best DevOps practice, where we use Sonatype Nexus Repository to store all artifacts, both internal and external.

Sonatype Nexus Repository's most valuable features, which also represent the biggest strengths, include its ease of use, good stability, and seamless integration with CI/CD tools. I have worked with other artifact repositories previously, and I found Sonatype Nexus Repository more intuitive for day-to-day administration such as managing repositories, users, permissions, and different package formats, which is straightforward. Valuable features include hosted and proxy repository management, seamless CI/CD integration with CI/CD tools, RBAC-based secure access, SSL certificate support for secure communication, and comprehensive, well-organized documentation. The most valuable capability, in my opinion, is the proxy repository caching, which significantly reduces internet-based dependency for builds by caching external repositories within our network, meeting our organization's security compliance and policy, thus improving pipeline performance. Overall, we have reduced our artifact management overhead and build deployment time by more than 70%, indirectly helping to improve our release deployments of business use cases faster, which aids in productivity gains and lowers our infrastructure costs as well.

Proxy caching, specifically for various types of artifacts such as Docker images, NPM images, and Red Hat YUM repository package images, is one of our strongest assets. When my developers or the CI/CD pipelines download dependencies from sources such as Maven Central, npmjs.org, or Docker Hub, Sonatype Nexus Repository acts as the intermediary. Before using this proxy repository feature, each build needed access to external repositories, resulting in higher download times, increased bandwidth usage, and potential security concerns. With the Sonatype Nexus Repository proxy repository, the developer or CI/CD tool connects to the proxy repository, which in turn connects to the internet. If a package is not available in our proxy repository, it downloads it the first time and caches it locally. In the future, when the same developer or any new application team requests the same package, it serves directly from Sonatype Nexus Repository itself without connecting to the internet again. This caching leads to faster builds, reduced internet bandwidth, better reliability, enhanced security, and consistent builds by using the same cached artifacts. In summary, proxy caching has significantly improved our CI/CD performance by caching external dependencies locally, achieving more than 70 to 80% reduction of artifact retrieval time, positively impacting our workflow and performance.

Sonatype Nexus Repository positively impacts our organization by improving stability, as I have had an excellent experience in terms of stability and have not faced significant downtime or reliability issues during production use. The platform scales based on our environment needs as we run it inside Docker containers, allowing us to scale out our development and deployment without major challenges. Customer support has been proficient, especially during significant migrations, such as transitioning storage from the blob format or upgrading from one version to another, which has happened seamlessly. The governance aspect is noteworthy as it provides superior control over software artifacts. In terms of cost and operational savings, we have measurable operational benefits by reducing duplicate artifact downloads, bandwidth usage, and minimizing manual repository management. One significant benefit is the standardization across the organization, providing a centralized platform for managing various package formats across projects. Overall, it helps us establish a centralized artifact management view and strategy, improving collaboration between development and DevOps teams using a single trusted platform for different technologies while supporting various repository formats such as proxy and hosted features, RBAC, and repository governance, thus enhancing security and reducing management efforts.

I would like to share my thoughts on the areas of improvement for Sonatype Nexus Repository. In today's enterprise landscape with the rise of AI-driven initiatives, it would be beneficial for Sonatype Nexus Repository to feature AI capabilities. This includes automated repository creation, user management, permission management, and storage optimization with cleanup suggestions. Another improvement is to expand the capabilities of the free edition, as the community edition is excellent for learning; adding more enterprise features with reasonable usage limits would help organizations evaluate performance more realistically as a proof of concept before purchasing the commercial version. Areas of improvement in AI-driven functionalities might include examples such as AI-assisted repository administration, automated repository creation, configuration of storage, and application of recommended policies based on users' natural language queries. Enhanced user management could suggest RBAC roles automatically and detect excessive permissions while highlighting potential security risks. Furthermore, AI-driven dependency optimization could help identify unused dependencies, detect duplicate artifacts, and predict storage growth for cleanup management. AI can provide predictive insights into repository usage and recommend cleanup strategies before storage issues arise, as well as aid in security governance by explaining vulnerabilities and identifying risk patterns.

I have been using Sonatype Nexus Repository for more than eight years.

Sonatype Nexus Repository is stable and scales based on enterprise requirements; I have not faced any significant downtime during production.

Sonatype Nexus Repository scales according to enterprise needs, and running on the public cloud allows us to scale up or down as necessary. I have encountered no challenges regarding scalability.

Customer support is very good. I have only needed it one or two times, particularly during a version migration from Sonatype 2.x to Sonatype 3.x when handling a substantial amount of data over two terabytes. The support team guided us through the process, which was very helpful.

Previously, every team managed artifacts locally, and with the industry's trend toward DevOps about eight to ten years ago, we explored various repository management options, including JFrog Artifact Repository. However, we did not find JFrog suitable because Sonatype Nexus Repository proved easier to maintain, administer, and integrate with CI/CD pipelines, making it best suited for our operational requirements.

We evaluated JFrog Artifact Repository but ultimately chose to use Sonatype Nexus Repository.

Proxy caching, specifically for various types of artifacts such as Docker images, NPM images, and Red Hat YUM repository package images, is one of our strongest assets. When my developers or the CI/CD pipelines download dependencies from sources such as Maven Central, npmjs.org, or Docker Hub, Sonatype Nexus Repository acts as the intermediary. Before using this proxy repository feature, each build needed access to external repositories, resulting in higher download times, increased bandwidth usage, and potential security concerns. With the Sonatype Nexus Repository proxy repository, the developer or CI/CD tool connects to the proxy repository, which in turn connects to the internet. If a package is not available in our proxy repository, it downloads it the first time and caches it locally. In the future, when the same developer or any new application team requests the same package, it serves directly from Sonatype Nexus Repository itself without connecting to the internet again. This caching leads to faster builds, reduced internet bandwidth, better reliability, enhanced security, and consistent builds by using the same cached artifacts. In summary, proxy caching has significantly improved our CI/CD performance by caching external dependencies locally, achieving more than 70 to 80% reduction of artifact retrieval time, positively impacting our workflow and performance.

Sonatype Nexus Repository positively impacts our organization by improving stability, as I have had an excellent experience in terms of stability and have not faced significant downtime or reliability issues during production use. The platform scales based on our environment needs as we run it inside Docker containers, allowing us to scale out our development and deployment without major challenges. Customer support has been proficient, especially during significant migrations, such as transitioning storage from the blob format or upgrading from one version to another, which has happened seamlessly. The governance aspect is noteworthy as it provides superior control over software artifacts. In terms of cost and operational savings, we have measurable operational benefits by reducing duplicate artifact downloads, bandwidth usage, and minimizing manual repository management. One significant benefit is the standardization across the organization, providing a centralized platform for managing various package formats across projects. Overall, it helps us establish a centralized artifact management view and strategy, improving collaboration between development and DevOps teams using a single trusted platform for different technologies while supporting various repository formats such as proxy and hosted features, RBAC, and repository governance, thus enhancing security and reducing management efforts.

In terms of measurable operational benefits, Sonatype Nexus Repository has significantly improved our software delivery life cycle. By implementing the proxy repository and using centralized artifact management, we have achieved more than a 60 to 70% reduction in artifact retrieval and build deployment pipeline times, which has minimized dependency download layers and internet bandwidth usage, ultimately yielding over a 70% improvement in build and deployment pipeline efficiency.

I advise organizations looking for a reliable, scalable, and easy-to-manage artifact repository management solution to consider Sonatype Nexus Repository. Organizations should take advantage of the proxy repository early in the implementation process, as it delivers significant benefits by caching external dependencies. Implementing proper repository governance from the start, including clear naming standards, RBAC and access policies, cleanup strategies, and lifecycle management best practices, is crucial. Overall, Sonatype Nexus Repository is a mature, stable platform that can greatly enhance the software delivery process. I highly recommend Sonatype Nexus Repository to any organization looking for a reliable, scalable solution, as it has greatly benefited me personally and my organization. I rate this solution 9 out of 10.

Public Cloud

Amazon Web Services (AWS)

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.

The integration with CI/CD tools is a standout feature for me in daily work. I also appreciate artifact management because compared to other artifact repositories like Jfrog, I find Sonatype Nexus Repository quite user-friendly in terms of its integration with different CI/CD tools and the different artifact management features. The security features are also quite useful; for example, you can install your SSL certificates to secure your Sonatype Nexus Repository. Additionally, the documentation of Sonatype Nexus Repository is quite comprehensive and very easy to follow. I find all the features quite user-friendly in Sonatype Nexus Repository.

Sonatype Nexus Repository has positively impacted our organization by configuring these proxy repositories, which have significantly reduced artifact management time. We have observed more than 50 percent time efficiency. Sonatype Nexus Repository allows us to maintain different hosted repositories within the company's network, which we would otherwise have to maintain over the internet. The internet push and pull for artifacts usually takes a lot of time, and our organization policies often do not allow accessing the internet for these kinds of artifacts due to security reasons. Sonatype Nexus Repository has significantly saved us efforts as well as time. We take a very good amount of control over our own repository management, which is something we really appreciate about Sonatype Nexus Repository.

I would like to explore the AI features in Sonatype Nexus Repository, such as the Sonatype MCP servers for automating the creation of repositories and user management. I have gone through some of the documents, but I have not explored this area much. I would be more interested in exploring these areas of Sonatype Nexus Repository now.

AI capabilities are an area for improvement, but I have not had the chance to work much with its AI features yet. Additionally, I think Sonatype Nexus Repository's free version could use more features. There are two versions of Sonatype Nexus Repository: a paid version and a free version. If the free version had more features, it could help people conduct effective proofs of concept, as the limited features often impact decision-making when evaluating tools against real-time use cases. If the free version includes more features while maintaining some usage limitations, it would greatly aid others in effectively validating Sonatype Nexus Repository for their actual needs.

If Sonatype Nexus Repository focuses more on integrating AI features to make usage more efficient, that would be great. User management and artifact management are all fine, but integrating AI capabilities effectively is something I would like to see in upcoming versions of Sonatype Nexus Repository.

I have been working in my current field for more than 10 years.

Sonatype Nexus Repository is very stable, and I have not experienced any issues with downtime or reliability.

Sonatype Nexus Repository is scalable. We have installed the repository inside Docker containers, and we have scaled those Docker repositories up easily without any issues.

We did not get a chance to interact directly with Sonatype's support team because the documentation is so well laid out that we managed to resolve any issues by referring to it. I would really appreciate the documentation team of Sonatype Nexus Repository for their excellent work.

We previously used Jfrog, but we switched to Sonatype Nexus Repository due to its user-friendliness and being feature-rich. These are the main reasons, as Sonatype Nexus Repository is straightforward to set up, user-friendly, and more feature-rich.

The setup cost for Sonatype Nexus Repository is not much, and it is easy to follow. The licensing is also reasonable, and we have no complaints regarding the costs associated with Sonatype Nexus Repository. We are quite satisfied with it.

We have seen a return on investment by saving significant time, more than 50 percent of our build and deploy pipeline time, leading to a clear ROI. Additionally, we save money because we transitioned from maintaining a lot of private repositories over public artifactories to Sonatype Nexus Repository. The efficiency and saved time are substantial. We have saved more than 50 percent of our time and money by shifting all artifact management to Sonatype Nexus Repository.

The setup cost for Sonatype Nexus Repository is not much, and it is easy to follow. The licensing is also reasonable, and we have no complaints regarding the costs associated with Sonatype Nexus Repository. We are quite satisfied with it.

To be very honest, we did not evaluate other options before choosing Sonatype Nexus Repository. We were convinced that it would be the best solution to replace Jfrog, so we went ahead with it without looking into anything else.

I would give eight out of ten for Sonatype Nexus Repository. I chose eight out of ten because it is feature-rich, and you can create all kinds of repositories. The installation process is also very easy, and the documentation is comprehensive and user-friendly. The overall user-friendliness of all features, from user management to artifact creation, is something I appreciate, which led to my rating of eight.

I haven't explored the AI features of Sonatype Nexus Repository much, but I have heard about some AI capabilities around governance and security. I have not worked on these features, so I cannot comment on them currently. Once I try these features and implement them in my project, I would be able to provide feedback.

Regarding accuracy and reliability, I believe there should be a focus on ensuring accuracy while minimizing any potential hallucination. I would like to see AI capabilities particularly around user management and artifact factory management, expecting around 85 to 95 percent accuracy and reliability from the AI capabilities of Sonatype Nexus Repository.

I would definitely recommend Sonatype Nexus Repository as it is a stable and user-friendly product. I believe that other teams can also achieve similar returns on investment as we have after implementing Sonatype Nexus Repository.

We are quite happy with Sonatype Nexus Repository, and I hope the Sonatype team will continue to serve us as they have for many years. My overall rating for this product is eight out of ten.

On-premises

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.

Sonatype Nexus Repository was very helpful because currently, there are around 20 to 30 microservices in our application and my client was a big network provider in the UK with many projects. They used Sonatype Nexus Repository to store the JAR and WAR files of all their applications that were being built. This helped with efficiency because before using Sonatype Nexus Repository, everyone was using Jenkins and storing the JAR and WAR files on their local server where Jenkins was running. After implementing Sonatype Nexus Repository, we could have JAR and WAR files and all packages in a central place where they could be stored for a longer time. Additionally, files could not be accidentally deleted, and I could maintain different versions of the JAR and WAR files by tagging them with different names.

For version management in Sonatype Nexus Repository, I could have multiple versions of the same WAR file. For example, if an application was being built during the CI process, I could tag it with 'A-1' and upload it to Sonatype Nexus Repository. During another stage, I could upload it as 'A-2'. In this way, I could manage versioning and it helped with long-term storage. I could use the same JAR file after six to seven months, and if I had not deleted that WAR file and had not used any lifecycle policy, I could still access it.

The user interface of Sonatype Nexus Repository was fine and not too bad overall. However, some aspects of the user interface were not ideal because if a JAR or WAR file was uploaded, I might find it difficult to delete that particular JAR or WAR file, as it was somewhat embedded deep within the UI and required significant navigation to delete the WAR file. This was the UI problem I experienced. Otherwise, I have not encountered any other problems with the UI.

I was experiencing some network connection issues with Sonatype Nexus Repository because of high RAM usage. However, I was not certain whether that was the issue with Sonatype Nexus Repository or internal errors. Otherwise, I have not experienced any other issues with Sonatype Nexus Repository. Overall, it was a very good product.

I used Sonatype Nexus Repository for around 3.5 years.

Everyone was using Jenkins and storing the JAR and WAR files on their local server where Jenkins was running.

Time saved is what I can highlight with Sonatype Nexus Repository. There was no need for additional employees because that could be managed by a CI/CD pipeline. Typically, one or two people are needed for Sonatype Nexus Repository management.

Money saved is not significant because a license needs to be purchased. However, if choosing the free license, some money can be saved with Sonatype Nexus Repository.

Sonatype Nexus Repository is good for storing packages such as JAR and WAR files. I have not used it for other packages such as Python or other programming languages. However, for Java and Spring Boot JAR and WAR files, there is flexibility in using Sonatype Nexus Repository. It can also use a small amount of storage if there is a small company. If there is a big company, NFS can be used and Sonatype Nexus Repository can also be installed on-premises or on the AWS side. Both paid and free versions of Sonatype Nexus Repository are available.

I used Amazon Web Services for AWS deployment purposes.

I am not certain about the pricing and licensing details because that was not handled by me. My overall review rating for Sonatype Nexus Repository is 7.5 out of 10.

We have other tools we use integrated into the pipelines, so when we run the pipeline, part of it is the scanning.

The benefit of Sonatype Nexus Repository is that you get an idea about open source or third-party libraries vulnerabilities.

The Health Check feature for repositories is for identifying vulnerabilities, and vulnerabilities normally come from the tool itself. I use the Health Checks to identify whether a vulnerability really applies to what we have or not.

Sonatype has features for managing NPM, Docker, and Maven, which helps with development environments by connecting with those third-party libraries.

Having it centralized in Sonatype Nexus Repository is a major benefit for any organization, as it helps maintain a secure environment.

I see a great feature that allows waving vulnerable components that cannot be fixed immediately due to various limitations.

It would be great if notifications were implemented for waivers, as currently we rely on users to inform us or check manually.

Sonatype Nexus Repository is on the high side regarding price, especially for components such as Firewall.

I have been using Sonatype Nexus Repository for more than two years now.

Sonatype Nexus Repository is reliable, and I believe it is scalable, but I do not have personal experience with scaling.

My impression of Sonatype's customer support and technical service is positive.

I have not worked with other competitors yet, so I cannot compare it right now, but I know they are one of the top ones in the market.

The installation process for Sonatype Nexus Repository is managed by a team that is not involved with security directly, so I am not sure how complex it is.

Time definitely is saved by using Sonatype Nexus Repository, as security is a requirement.

I am still using the same products, maybe different versions of it. Last time it was OpenText Fortify. They contacted me regarding this.

I have not worked with OpenText Contact Center Analytics for customer data analysis, though I have heard of it.

I am also using Sonatype Nexus Repository now.

I get the vulnerabilities, and you get what it is doing.

Recently, they acquired something called Firewall, which is another component on top of this, so you can block things and allow things, which is very useful for security.

They stand out in their field.

Sonatype Nexus Repository is doing our purpose well. My overall review rating for this product is 9.

On-premises

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.

As a big organization, Sonatype Nexus Repository positively impacted us by providing a centralized repository for storing all internally developed artifacts and third-party artifacts. Apart from speed and productivity, Sonatype Nexus Repository helped with security, which was possibly the main reason or outcome.

When I was using Sonatype Nexus Repository, I found the storage and pulling of dependencies to be really fast, and it was definitely a reliable tool.

Sonatype Nexus Repository was supposed to be one single storage area for internally developed artifacts. Developers had to pull their dependencies from Sonatype Nexus Repository. Since internally developed artifacts were from Sonatype Nexus Repository, we ensured that only vetted and approved artifacts were being pulled by all developers across the enterprise.

Based on what we had used at that time, I was not sure whether what we had was the full version of Sonatype Nexus Repository, but what we had at that point in time was primarily focused on pulling dependencies. I know Sonatype Nexus Repository now has firewall capabilities and scanning capabilities as well, scanning dependencies for vulnerabilities. At that point in time, it was only the pulling and storage of dependencies.

At that point in time, I was not exposed to all the features that Sonatype Nexus Repository offers today. The firewall feature, which is Nexus Firewall, and overall software supply chain security features that are now there with Sonatype Nexus Repository were not available back then. I believe Sonatype Nexus Repository has most of these features now.

I used Sonatype Nexus Repository for more than two years.

Sonatype Nexus Repository is stable.

Sonatype Nexus Repository was scalable.

One thing at that point in time was that Sonatype Nexus Repository was on-premises, so it did not require authentication. I am not sure how the SaaS model works right now, and I hope authentication and authorization using keyless authentication or workload identity federation is a part of Sonatype Nexus Repository today.

My advice to others looking into using Sonatype Nexus Repository is that if it is an enterprise as big as mine, definitely ensure that enterprise support is covered because a good volume of artifacts is going to be stored in the tool, so enterprise support is definitely recommended.

On-premises

Other

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.

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.

I think what can be eventually improved is to introduce as a standard the additional security features that Sonatype Nexus Repository offers, which are basically plugins for the repository itself.

I have been using Sonatype Nexus Repository for 10 years.

I rate how stable and reliable Sonatype Nexus Repository is at a 10. We have had zero issues since we installed it, so it is wonderful.

We have had zero issues with Sonatype Nexus Repository, so I do not see any reason for it not to receive a 10 based on my entire experience with it.

I rate how scalable Sonatype Nexus Repository is at a 10 out of 10.

I often communicate with Sonatype's technical support and customer service. They are very good. I was mainly in touch with the pre-sales team, but they were always able to adjust to the needs that we had. They are absolutely excellent.

Positive

We used Sonatype Nexus Repository in the open-source version, which had some limitations.

I participated in the initial setup process of Sonatype Nexus Repository. It was very smooth because the pre-sales team of Sonatype did a very nice job, so it was easy to implement.

I used help from the vendor.

I would say that considering the environment and everything, for one person, I managed to save approximately one hour a month with Sonatype Nexus Repository. However, you need to scale this for the number of people that you have in the company. The bigger your organization is, the more benefit you get.

It is an adequate price for the features that you get.

We did not use the repository health check feature.

I have been working with Sonatype Nexus Repository since 2020, and I have continued working with it since 2022. Moving to the pro version of Sonatype Nexus Repository reduced our time to accomplish what we needed to some extent. My main focus is on the Geo-DR part because it is complex and not commonly offered. Most products handle it using external infrastructure, but Sonatype does not. It is self-contained and really helpful in order to move us to where we need to be.

On-premises

Other

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)

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.

One of the features I love about Sonatype Nexus Repository is storing the company's internal artifacts along with version management and release/snapshot separation, where we have separation between release files and snapshot files. There is access control for internal and external artifacts, and combining multiple repositories into one logical endpoint is something I appreciate about Sonatype, along with how Sonatype Nexus Repository handles large artifact stores and disk space optimization.

Role-based access in Sonatype Nexus Repository allows us to control who can read, write, or deploy artifacts. Developers can read artifacts and deploy snapshots, while CI/CD systems have specific credentials for automated deploys, and administrators have full access for maintenance. Contractors and interns have limited read-only access if needed, which helps prevent unauthorized changes, as only authorized people can push production releases. Sonatype Nexus Repository logs who deployed what and when, which is crucial for compliance.

In our team, the development team can push snapshots and pull any artifact for development. The release manager can promote snapshots to releases, and the CI/CD pipeline setup has a special service account with limited permissions to only pull artifacts. New interns have read-only access until they are fully onboarded, and external partners can only access specific repositories that we share.

Before using Sonatype Nexus Repository, developers waited for Maven Central downloads on every build, leading to inconsistent build times depending on internet speed. Builds failed if Maven Central was down or slow, and working offline was almost impossible. When we started using Sonatype Nexus Repository, build times improved by 30 to 40 percent through artifact caching with consistent, predictable build performance. Offline builds became very easy for us because we have cached artifacts locally, which increased team productivity immediately, saving approximately 50 to 150 minutes of developer time daily. This recovery of hundreds of hours allows developers to focus on actual development work instead of waiting for downloads.

Before Sonatype Nexus Repository, different developers had different versions of the same library, leading to the "it works on my machine" syndrome that caused frustrated troubleshooting. With Sonatype Nexus Repository, we now have a single source of truth for all artifacts, ensuring all developers use identical versions and enabling reproducible builds across all machines. This speeds up debugging and reduces versioning inconsistencies, allowing the team to trust that if it works for one person, it works for everyone.

Onboarding also improved significantly, as new developers previously spent hours configuring Maven settings and understanding multiple repository URLs, leading to mistakes in setup and blocked starts. After implementing Sonatype Nexus Repository, new team members are productive in minutes due to a single repository URL to configure in the settings.xml files and documented, foolproof setup. This frees senior developers for actual mentoring and reduces ramp-up time for contractors and interns.

Sonatype Nexus Repository also provided cost optimization since it eliminated the need for local repository caches on each developer's machine, centralizing storage and reducing overall storage by 70 percent, resulting in lower bandwidth usage through shared caching.

In terms of improvement for Sonatype Nexus Repository, the user interface and user experience need attention, as navigation can be confusing for someone who is just starting out. I suggest implementing a search command palette similar to VS Code's, perhaps with functionality similar to Ctrl+K, or modernizing the UI with contemporary design patterns. Introducing dark mode options would also be beneficial.

Regarding performance, bulk operations can be slow, and deleting a thousand or more old artifacts takes a very long time, making the system sluggish during cleanup. There is no way to perform background deletion and cleanup policies cannot be optimally scheduled. I suggest the team implement asynchronous bulk delete operations that can happen behind the scenes, improving background job processing. This ensures cleanup operations do not block normal artifact access, as well as providing granular scheduling for maintenance tasks and progress tracking for long operations.

I have been using Sonatype Nexus Repository for almost two to three years.

On my team, we actually have Sonatype Nexus Repository installed on all engineers' computers locally, and one of the issues we have with that is the initial setup complexity, leading to disk space management issues whenever we onboard a new engineer into the team. Because of these problems, we have to look for a way to solve this problem, which is actually moving from local to remote server deployment, enhancing team collaboration and shared repository, eliminating redundancy with no duplicates on multiple machines, simplifying dependency management across the team, and having a single source of truth for all of our artifacts, resulting in consistent builds across members, reduced bandwidth, easier onboarding of new team members, and better security.

I recall a day when a developer was onboarded, and I had to help with setup. The new engineer needed to configure Maven, open the M2 settings, the M2 folder, the settings.xml files, add repository URLs, authentication credentials, and all of that. In the afternoon when he tried his first build, it failed due to artifact not found, leading him to run back to me in frustration. Eventually, we discovered he was using the wrong repository order in the settings.xml, making me spend another 30 minutes debugging. At the end of the day, after finally getting this new developer's build working, he expressed that the setup was confusing with multiple URLs to remember, making him feel an unease about whether he was doing something wrong, causing frustration.

After improving the onboarding process by moving to Sonatype Nexus Repository, the setup became much smoother and this new developer stated that setup was super simple, requiring just one URL and one command to get everything working, making him productive within the first hour, which was way better than expected.

For others looking into using Sonatype Nexus Repository, I would advise considering how it can streamline their development processes.

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