Resources Blog It's Time to Upgrade to Nexus Repository 3

It's Time to Upgrade to Nexus Repository 3


With the sunsetting of Nexus Repository 2 on the horizon, it’s time to upgrade to Nexus Repository 3.  Nexus Repository 3.0 was released in early 2016 to be completely redesigned into a universal repository manager. We took lessons learned from Nexus Repository 2 to build a whole new platform from the ground up. The goals were to make an agnostic platform to support all our stakeholders that would be performant regardless of where it is deployed. Over the last few years, we have added support for a ton of features that we think you will love. If you haven’t made the switch yet, the Sonatype Customer Success and Support teams are available to help our Pro customers. Here are some reasons we think make it worth the effort.

Resilient Architecture

Binary repositories are central to your application development pipelines, so you will want your Nexus Repository available anytime you need to build. Nexus Repository 3 was built with cloud deployments in mind; with external database support, object storage and file-based storage, and fully automated helm chart deployment to Kubernetes.

External PostgreSQL Database

All cloud platforms support highly available managed PostgreSQL databases so it is very easy to set up and deploy. Moving to a dedicated external database in a multi-server environment reduces the load and resource requirements on your repository server; directly saving you money. Using an external database will also reduce startup/recovery times, allow you to back up any time, and will be key for scaling up your deployment.

Object Storage

Storage in the cloud can quickly get expensive so having other options is a must. Nexus Repository 2 required fast/expensive storage since the repositories and indexes were built directly on top of the file system. 

Nexus Repository 3 was built to abstract away your repositories from how it is stored. This allows you to use a number of alternative storage options such as less expensive S3 object storage for your binaries. Adding new storage, or blob stores is easy and can be dropped into the shared group without interruption. Staging and management moves are also super fast since components don’t need to be moved around on disk.

Automated Deployments

Nexus Repository 3 has a few methods for you to deploy automatically. We publish helm charts for each container release designed to deploy on Kubernetes directly. Monitor the health of your server using the Status Checks and Prometheus endpoints. The full-featured REST API is exposed through a Swagger interface making it easy to automate your configuration as code.

Universal Repository

Nexus Repository 2 was built on the Maven repository format which made supporting other ecosystems difficult or virtually impossible. With Nexus Repository 3 we took a different approach.  Starting with a generic raw format we build on support for many ecosystems such as Maven, Docker, npm, .NET Nuget, python, Yum, and many more. Nexus Repository 3 is also fully extensible so it is easy to create new formats for any language and unlike other tools, all languages are included by default.

Scaling Repositories

With all the new repository formats we are seeing many customers deploy purpose-built servers for different ecosystems. For example, they may have one system for Maven and npm, while having separate systems for Docker and Yum repositories. Another common model is a centralized system of truth with specific read-only or remote proxy instances for distribution. Even better are the hybrid cloud models where you have instances in every cloud your developers use while also maintaining an instance on-prem. The great thing about Nexus Repository 3 is your Pro license allows you to run as many instances as you need, where you need them, and still get the support you love.

Taming Repository Sprawl

In Nexus Repository 2, the only way to set access control for development teams was to create a new hosted repository. Group repositories allowed you to aggregate them together into a single endpoint however these ended up in long sprawling lists that were hard to manage and made namespace enforcement difficult.

Nexus Repository 3 gives you more flexibility to manage access to specific namespaces within a single repository using Content Selectors. Content Selectors provide more granularity with your access configuration while keeping your repositories manageable.

Take control of your Staging Lifecycle

Managing your component's staging lifecycle was limited to only Maven in Nexus Repository 2. While full-featured it was limited in that everything needed to be managed inside the repository. That did not align with how modern DevOps teams work. Nexus Repository 3 has an all-new staging suite of features that gives you more control in managing your component lifecycle from your build pipeline.  Staging environments can be built using stage-focused repositories and groups while artifacts are moved to the next staging using API calls from your CI. You may include as much information as you need to manage your build artifacts using Tagging.

Next Steps

Since the release of Nexus Repository 2, the Sonatype Customer Success and Support teams have helped many customers plan and go through the upgrade process, which does come with pain points. We want to limit downtime while redesigning the legacy infrastructure. There may be technical debt from old scripts which will not work on the new server, old builds that need to be reconfigured, and lots of data that needs to be moved or cleaned up. We put together an Upgrade Resource with many of our lessons learned. Reach out to your account team for help through the process; we are there for you.

Picture of Chris Good

Written by Chris Good

Chris is a Product Marketing Manager with Sonatype. Originally from Pittsburgh, PA, Chris studied Communications and Computer Science at the University of Pittsburgh. He enjoys working for Sonatype because of the culture here at the company -- it's diverse and promotes creativity. When he's not working with DevSecOps community, he loves snowboarding, cycling, and traveling.