One issue is that Nexus Repository doesn't have an end-to-end solution that helps developers easily sign an image and store it or to deploy that image if it's not signed. We're looking for other tools to help us with that. We'll continue to use Nexus but only for storing our artifacts. It would be great if Nexus had some features to help us maintain our container images as well. The solution could be more intuitive.

We are using goharbor for our container registry. It has a feature that helps us to define a pattern and other features that have allowed us to configure the container images more easily. In that sense, Nexus is not as feature-rich. I'm hoping that the features we use on goharbor will be integrated into Nexus and then we won't need as many tools to run our infrastructure. 

We've had some challenges around the database they use. We've had some big outages and it's due to the fact that we haven't found the database they use is all that stable. I think they've realized that themselves. We're probably not the only customer who has complained to them about that. They're realizing there is a problem with the proprietary database and hopefully they'll be giving customers options to move to different database types. We've had some really positive conversations with Sonatype around that and they've provided us with the support and special services to help us migrate off of that, onto another type of database platform which we have more control over.

They could improve the user interface and REST APIs. I found that JFrog has multiple features as compared to Nexus Artifactory. JFrog is more advanced, so it has many good features. The REST API is good. The CLI and the integration with other build tools are quite good in JFrog, so comparatively I found the Nexus has to improve a lot.

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.

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.

One of our main concerns would be about plugging Nexus IQ into JIRA to be able to automatically raise issues whenever we have a policy violation in a scan.

The second main feature that is missing in Nexus IQ is the ability to explore the history of the different reports that have been generated for a given product. For the time being, in the Nexus IQ UI, we are only able to browse the latest reports that have been generated for a given product. It would be really useful for us to be able to go back in time by browsing through the reports and to have a tool that would give us the evolution of the metrics. 

Another one of our concerns, also regarding Nexus IQ, is about being able to manage the different versions of a given application within the web UI. For the time being, Nexus IQ is not able to manage the different versions of one application. We can define different applications that match the different versions of the product, but if we waive a policy for a given application, we are not able to spread this waiver across the different applications unless we scope it at the organization level. That is something we won't do for the time being because our organization does not permit us to do so. It would be a very helpful feature for us to be able to manage the versions of a different application within the web UI.

When it comes to the library uploads, for Java libraries it's very easy. You choose the .jar that is to be uploaded. But when it comes to uploading NPM libraries, JavaScript dependencies libraries, it is a little bit of a convoluted process. They need to improve uploading libraries for NPM-type repositories. There is good room for improvement there.

I'm looking forward to getting things like automatic governance done, but the bigger priority I'm waiting for is a feature to have hot publication between several Nexus instances. That's more important for me right now because in our company we have several locations distributed all over the world, and each location is producing its own artifacts, sometimes for the same project. I really would appreciate a scenario where the developers could provide their data to the local repository and it would be hot-replicated to the other repository instances. That would be the most important feature for me right now. As far as I know, it's not available, but it's on the roadmap.

There are also some minor usability features which are changing from version to version, but that's always progress in the correct direction. They recently added the group artifact version (GAV) search. That was something my users really requested for some time.

The next big feature my users request is a remote search so if you have a proxy repository the search can be performed within the local Nexus instance. That would be a major improvement. 

I think these requests are already known to the Sonatype and already on the roadmap.

Also, the code snippets for integrating different artifacts: Currently, they are available for Maven dependencies. We really would appreciate it if they were available for other build systems. That was available in Nexus 2 and it is already on the roadmap, but I'm not sure what the priority is.

I would like to see multifactor authentication implemented.

The only thing that I would like to see is multifactor authentication. This is a critical feature that must be included.

Sonatype Nexus Repository could improve by making the experience working with CI/CD pipelines, such as GitHub Action or GitLab better.

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.

One feature that needs changing is their pricing model. They are charging a huge amount. The way they charge it's too much.

In addition, they should have some feature where we can move a specific repository from one instance of Nexus to another instance of Nexus. As of now, this feature doesn't exist. With the recent upgrade, when they moved from 2.x to 3.x, they made a couple of changes in the backend regarding how data is saved. That, again, makes it a bit difficult to move the changes. So the feature that I would suggest is the capability to move repositories that people have configured in their systems from one instance to the other. If they had this feature, it would be very effective.

We feel that if the product could be configured more easily through configuration files, instead of API calls and databases. That would make it easier to integrate with other DevOps tools. This is one of the hurdles that we encountered when we tried to integrate Nexus 3 with our OpenShift installation. The need to manipulate a dedicated Nexus database, instead of being able to generate configuration files, was a bit problematic.

The inclusion of repositories that are currently supported by the community would be helpful, if possible. In particular, I'm thinking of Debian repositories.

Otherwise, we don't have any request for large features because it's already a well-featured product. Everything else is included already. We are quite happy with the feature set.

I would like to see them build in some scanning features out-of-the-box, as opposed to only getting them by buying the add-ons of Nexus IQ Server. I would like to see some level of ability to filter in the tool itself, through scanning the binaries in there.

We had some issues with the container platform, but we raised a support ticket and it was sorted out for us.