Repository Manager Pro Features

We recognize that Sonatype Nexus Repository is often mission-critical for your business. Be ready for the unexpected by using a high availability (HA) or resilient deployment option that can protect your business and your data in the event of disaster or outages. With comprehensive backup and restoration tasks and a growing list of deployment architecture examples and guidance, Nexus Repository Pro can help you reduce your Recovery Time Objectives and Recovery Point Objectives.

Sonatype Nexus Repository Pro allows you to use an external PostgreSQL database. By externalizing your database, you can take advantage of a number of benefits:

Sonatype Nexus Repository Pro integrates with SAML Identity Providers to allow identity, authentication, and authorization to be managed centrally. Using SAML, Sonatype Nexus Repository acts as a service provider which receives users' authentication and authorization information from external Identity Providers. Administrators can manage users and roles in one place, and users can sign in with Single Sign-On credentials.

When using Apache Maven with Sonatype Nexus Repository Pro, the user credentials for accessing the repository manager have to be stored in the user’s settings.xml file. Like a pom.xml your settings.xml is file that contains your user preferences. The Maven framework has the ability to encrypt passwords within the settings.xml, but the need for it to be reversible in order to be used limits its security.

Other build systems use similar approaches and can benefit from the usage of user tokens as well. Sonatype Nexus Repository Pro’s user token feature establishes a two-part token for the user. Usage of the token acts as a substitute method for authentication that would normally require passing your username and password in plain text.

This is especially useful for scenarios where single sign-on solutions like LDAP are used for authentication against the repository manager and other systems and the plain text username and password cannot be stored in the settings.xml following security policies. In this scenario the generated user tokens can be used instead.

Teams today rarely work from a single location, so why should artifacts be stuck in one? Content replication allows you to make artifacts readily available across distributed teams. With content replication, you can manage what binaries are copied from one instance and pre-emptively pulled via HTTP to other instances. Here's how it works:

In modern software development, it is imperative to thoroughly test software before it is deployed to a production system or externally accessible repository. Mostly commonly a release candidate will first be deployed to a staging system which is a close copy of the production system so it can undergo a series of rigorous tests before a decision is made to promote it to production or return it to development.

The staging functionality in Sonatype Nexus Repository Pro supports promotion of software components matching your organization's software development life cycle phases by moving those components between repositories. This allows the creation of isolated release candidates that can be discarded or promoted to make it possible to support the decisions that go into certifying a release.

Typical Staging Workflow

Tagging provides the ability to mark a set of components with a tag so they can be logically associated to each other. The usage of the tags is up to you but the most common scenarios would be a CI build ID for a project (e.g. project-abc-build-142) or a higher level release train when you are coordinating multiple projects together as a single unit (e.g. release-train-13). Tagging is used extensively by the Staging feature.

Import/Export provides the capability to copy components between repositories or Sonatype Nexus Repository instances.

Some common use cases to utilize Import/Export include:

These tasks keep track of the last run results and if run again, they will skip files that were processed previously. These tasks work with HA-C setup.

A temporary file system location is needed for these tasks to export to and import from. Please also ensure the Sonatype Nexus Repository instance running the task has sufficient disk space for export and blob storage for import before running this task to avoid disk full issues.

A group blob store combines multiple blob stores together so that they act as a single blob store for repositories. Members of the group can be added or removed. Fill Policies are selectable algorithms that determine to which group member a blob is written. These features significantly increase the flexibility customers have in using and upgrading their storage. More information can be found in the Storage Guide.

Below is an example of a group blob store:

Group deployment allows developers and CI servers to use a single URL, the URL of a group repository, to both push and pull content.

Without this feature developers have to use two URLs; one for pushing content, one for pulling content. For some formats, these URLs can't be saved to configuration and have to be manually entered.

When a group repository is being configured an administrator will be able to select a hosted repository that the group can delegate push requests to. When content is pushed the group repository will automatically route that content to the delegated hosted repository.

Sonatype Nexus Repository users can now automatically identify open source security risks at the earliest stages of their DevOps pipeline. Specifically, the RHC feature empowers software development teams into important capabilities:

Change repository blob store is a task that allows changing the blob store of a given repository. It moves the blobs from the chosen repository to a different blob store.

Some common use cases to utilize the Change Repository Blob Store task:

The Azure Blob Store allows assets to be stored in an Azure Storage Account container. Sonatype Nexus Repository Pro can take advantage of the storage features that Azure provides such as replication, configurable performance profiles, and access control when running from within the Azure cloud.

Atlassian Crowd is a single sign-on and identity management product that many organizations use to consolidate user accounts and control which users and groups have access to which applications. Atlassian Crowd support is a feature preinstalled and ready to configure in Sonatype Nexus Repository Pro. Sonatype Nexus Repository contains a security realm that allows you to configure the repository manager to authenticate against an Atlassian Crowd instance.

Sonatype significantly invests in each customer through our Customer Success team. This team is unique in that they will proactively and continuously collaborate with you to ensure you derive ongoing value from your Sonatype investment.

To start, they always recommend customers invest in workshops and training, which they deliver. These accelerate time-to-value and provide a solid foundation for long-term success. What's more, at no additional cost, they will coach you from the beginning. They will create and collaborate with you on a joint roll-out plan. They will provide you with best-practices, curate relevant materials for you, help you with designing architecture, and continue to monitor your progress towards your goals. And they will do this throughout your lifecycle as a Sonatype customer.

Sonatype Nexus Repository Pro users also get access to our World Class Support organization. This highly skilled group will work with you to resolve issues encountered while using the product. Detailed support information can be found at https://www.sonatype.com/usage/software-support-policy.