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.

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.

It works well together with the Nexus IQ. We can check our incoming artifacts from third parties with the help of the Nexus Secure server, which correlates with the Nexus support.

And we can provide good results or products to customers where they can download it from there and bring it into production on servers or something like that. So it's everything in this field.

The quality of documentation is good. I can find what I'm looking for every time. Except, there are some mistakes or errors in the backpacks. So, in this case I have to contact support.

It is not as well-suited for managing NPM packages as it is for managing Maven packages.

So, there are potential challenges in seamlessly integrating with non-Maven technologies.

I have been using this for five years. I am using Sonatype Nexus Repository version 3.48.

The product has been stable since the deployment. I would rate the stability a nine out of ten.

We are not using any scaling mechanisms which are provided with this product. We would just use more CPU, something like that. But it's okay. There's not much need for scalability here. Not so many people are accessing the repository right now. So it works fine for us.

There are over 130 end users using this solution.

The customer service and support are good because if there are some problems, we can open a ticket there. And usually, we get help within a day at the latest. Often much earlier.

They are good regarding their speed of response, and the staff is very good.

The initial setup was not challenging. We've changed from Nexus 2, which we have used earlier. So, this was a migration process, which was just a simple turn-on. Just that system is a step on, but however, it worked fine. So there was no real problem.

The deployment took around two months. Two to three people were involved in the process.

We have around five administrators for the solution.

The licensing cost is transparent and cheap. Overall, it is a very good price.

We pay for a license, and the support is connected to it. We regularly communicate with our customer success engineer. And we have the technical support and the documentation. So, there's no extra charge for the support included in the license.

Our company used JFrog.

I recommend examining your processes to determine if they align with this tool, as its history is heavily concentrated on Maven. If your operations involve Maven, this solution is likely the most suitable.

As we primarily focus on Java and Maven, I would give this solution a rating of nine out of ten in such cases.

However, if your emphasis shifts towards NPM products or NuGet, using Nexus is still feasible but may require more effort. The tool is more centered around Maven, making it a bit challenging to seamlessly integrate with NPM.

In such scenarios, opting for a different product might be more favorable. Nevertheless, if your environment revolves around Java or related technologies, Nexus stands out as a top-notch product in the market.