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.
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.
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.
Our primary use case of this solution is for our CICD pipeline, to build and store our artifacts in the repository. I'm the principal engineer and we are customers of Sonatype.
We are using Sonatype Nexus Repository for capturing or creating our software bill of materials, such as Maven, Python, no NPM, and Node.js Repos. They are open-source packages that we've scanned and that we want to keep as is. Additionally, we use it for our snapshots and releases of our own binaries.
Project Manager at a recreational facilities/services company with 10,001+ employees
Real User
2019-10-06T16:39:00Z
Oct 6, 2019
We happily use containers as a way of scaling out microservices so we use Nexus Repository for the management of containers, as a kind of repository. That's about 50 percent of what we use it for. The other side is that it is used for application and development artifacts. We use it to track artifacts in a repository so we can deploy software code. It's not a code library because we GitLab as well. It's more for the compartmentalized aspect that fits in and we can redeploy those on-demand. The way we deploy it is private cloud, ultimately. We have an internal cloud infrastructure that we operate and the Nexus platform sits inside it. We are looking at ideas around integrating this into AWS right now, because we are doing a huge kind of transformation project to move a lot of our on-prem services into public cloud. We're looking at that whole "bridge" between the cloud and on-prem and how we deal with that. That's something of a stepping-stone before we can take everything back into the cloud. I think Nexus Repository will eventually end up there.
We are primarily using Nexus Repository Manager to store the components we are building and to share them among our teams. We are also using it to get a cache from older, available public repositories which we need to build our projects. Regarding Nexus IQ, we are using it mainly to scan our projects to see the security vulnerabilities that may be occurring in our products.
DevOps Practitioner at a recreational facilities/services company with 11-50 employees
Real User
2019-02-24T10:18:00Z
Feb 24, 2019
We are using this tool for our Java, .NET, AngularJS and Node.js. Apart from that, we have recently built a solution to utilize this tool for Docker images as well.
Senior Application Architect at a financial services firm with 10,001+ employees
Real User
2019-02-24T10:18:00Z
Feb 24, 2019
We are using Nexus Repository as a Java repository for our libraries. We cannot host proxy libraries because we don't have access to the internet. We're downloading libraries manually and then uploading them to our Nexus repositories. That's the current approach. We not only upload open-source libraries but also our own libraries that we developed.
Our primary use case is as a manager and storage location for open-source software components. We utilize the Nexus repository to store safe open-source components that our developers can utilize in their applications, as opposed to their going out to the internet and getting potentially unsafe versions of the open-source components. We use it to manage binaries both in the IMR and in staging. Our biggest use of the software, as stated before, is to store open-source software components for user applications. The second biggest use is as a staging repository. We'll stage binaries for changes that are ready for deployment across to a production environment. We'll stage them there so we know they're centrally located. If we want to do any scans we can do them right there before they're deployed to our enterprise.
The primary use case is to store good artifacts our company has produced and proxy external artifacts to help reduce the outgoing traffic and to filter specific components which are known to be vulnerable.
Senior Information Technology Specialist at a financial services firm with 5,001-10,000 employees
Real User
2019-02-13T08:34:00Z
Feb 13, 2019
We use it as a repository for build artifacts. We have 300 developers and most of them use Nexus Repository to do their builds. They are mostly stream-mode applications, as well as front-end Angular applications. We definitely pull down most of the main dependencies, binaries, build artifacts, and release candidates.
At the moment we use it as storage, as a repository, the proxy to internet repositories, and for internal storage of our binaries. But we are looking seriously into using it for compliance to policy, for open-source dependencies that may have security issues or contradictory license usage. If certain dependencies do not comply with our licensing policies, then we want to be able to identify them. We are very interested in it to ensure the traceability of our open-source dependencies, to make sure that we are not using dependencies that could cause problems in the future, that could cause intellectual-property issues with the rest of our software. I wouldn't stretch it as far as calling it open-source governance. It's more of a safety check, to make sure that we don't make any mistakes that could cause legal problems later.
Nexus Repository is powered by Repository Manager, the same technology engine found in our OSS version deployed at more than 100,000 organziations world-wide. It is Built on the shoulders of Maven, Repository Manager supports all popular component formats and brings your entire development organization together. It includes staging and release functionality that provides support for operations and quality assurance processes prior to production and gives you instant insight into potential...
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.
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.
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.
Sonatype Nexus Repository is our content repository for the programs we are developing.
Our primary use case of this solution is for our CICD pipeline, to build and store our artifacts in the repository. I'm the principal engineer and we are customers of Sonatype.
We are using Sonatype Nexus Repository for capturing or creating our software bill of materials, such as Maven, Python, no NPM, and Node.js Repos. They are open-source packages that we've scanned and that we want to keep as is. Additionally, we use it for our snapshots and releases of our own binaries.
We happily use containers as a way of scaling out microservices so we use Nexus Repository for the management of containers, as a kind of repository. That's about 50 percent of what we use it for. The other side is that it is used for application and development artifacts. We use it to track artifacts in a repository so we can deploy software code. It's not a code library because we GitLab as well. It's more for the compartmentalized aspect that fits in and we can redeploy those on-demand. The way we deploy it is private cloud, ultimately. We have an internal cloud infrastructure that we operate and the Nexus platform sits inside it. We are looking at ideas around integrating this into AWS right now, because we are doing a huge kind of transformation project to move a lot of our on-prem services into public cloud. We're looking at that whole "bridge" between the cloud and on-prem and how we deal with that. That's something of a stepping-stone before we can take everything back into the cloud. I think Nexus Repository will eventually end up there.
We are primarily using Nexus Repository Manager to store the components we are building and to share them among our teams. We are also using it to get a cache from older, available public repositories which we need to build our projects. Regarding Nexus IQ, we are using it mainly to scan our projects to see the security vulnerabilities that may be occurring in our products.
We are using this tool for our Java, .NET, AngularJS and Node.js. Apart from that, we have recently built a solution to utilize this tool for Docker images as well.
We are using Nexus Repository as a Java repository for our libraries. We cannot host proxy libraries because we don't have access to the internet. We're downloading libraries manually and then uploading them to our Nexus repositories. That's the current approach. We not only upload open-source libraries but also our own libraries that we developed.
Our primary use case is as a manager and storage location for open-source software components. We utilize the Nexus repository to store safe open-source components that our developers can utilize in their applications, as opposed to their going out to the internet and getting potentially unsafe versions of the open-source components. We use it to manage binaries both in the IMR and in staging. Our biggest use of the software, as stated before, is to store open-source software components for user applications. The second biggest use is as a staging repository. We'll stage binaries for changes that are ready for deployment across to a production environment. We'll stage them there so we know they're centrally located. If we want to do any scans we can do them right there before they're deployed to our enterprise.
The primary use case is to store good artifacts our company has produced and proxy external artifacts to help reduce the outgoing traffic and to filter specific components which are known to be vulnerable.
We use it as a repository for build artifacts. We have 300 developers and most of them use Nexus Repository to do their builds. They are mostly stream-mode applications, as well as front-end Angular applications. We definitely pull down most of the main dependencies, binaries, build artifacts, and release candidates.
At the moment we use it as storage, as a repository, the proxy to internet repositories, and for internal storage of our binaries. But we are looking seriously into using it for compliance to policy, for open-source dependencies that may have security issues or contradictory license usage. If certain dependencies do not comply with our licensing policies, then we want to be able to identify them. We are very interested in it to ensure the traceability of our open-source dependencies, to make sure that we are not using dependencies that could cause problems in the future, that could cause intellectual-property issues with the rest of our software. I wouldn't stretch it as far as calling it open-source governance. It's more of a safety check, to make sure that we don't make any mistakes that could cause legal problems later.