Sonatype Nexus repository [Private Offer Only]

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.

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.

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.

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.