Skip to main content

Content Replication


Only available in Sonatype Nexus Repository Pro. Interested in a free trial? Start here.

What is Content Replication?

Content replication allows you to publish artifacts to one Nexus Repository Pro instance and then have other instances pre-fetch them via HTTP to provide faster artifact availability across distributed teams.

Content Replication builds on Repository’s on-demand proxying feature, and is a good choice for use cases that are sensitive to latency. For example, if you need to distribute large binaries to a second Repository instance, Content Replication can move those binaries there before they are requested by end users. This reduces latency by eliminating the time it takes to move the binary between Repository instances.

How it Works

With content replication, you can manage what binaries can be replicated (copied and pre-emptively pulled by an instance) between two or more instances. The following diagram illustrates the content replication process, which is also described below:

  1. New assets are published to the Nexus Repository source instance

  2. The replication task runs on the target instance on a schedule (each minute) to identify new assets

  3. The replication task issues proxy requests for each new asset to replicate them to the target instance

  4. Users on the target instance now have access to newly added artifacts on the target instance


There are multiple ways you can use content replication, including having multiple targets proxying one source, bi-directional content replication, or replicating a subset of content.

What Content is Replicated?

After content replication is enabled on an instance, all new assets will be replicated as if requested through the proxy. Pre-existing assets and Nexus repository metadata (downloaded date, uploader IP, etc.) are not replicated.

What that looks like can vary between formats. For example, for Maven, components' assets (e.g., jars, hash files, pom files, etc.) as well as the maven-metadata.xml files will be replicated.For npm, that means the dependency archives (.tgz) as well as the npm metadata.

In general, if you can see it in the browse tree as something to download, it will be replicated.

If you delete an item on the source repository that has already been replicated to the target repository, the item will still exist on the target repository; deletion is not replicated.

Note also that content replication can impact the effectiveness of your cleanup policies. For example, component downloads from the target instance will not update the last downloaded date on the source instance. This could result in a component being unexpectedly removed from the source but not the target.

What are the Supported Formats for Content Replication?

Content replication requires that the source repository be a hosted repository and the target be a proxy repository. The following formats support both hosted and proxy repositories and are suitable for content replication:

  • APT

  • Docker

  • Helm

  • Maven

  • npm

  • NuGet (V3)

  • R

  • Raw

  • RubyGems


In order to use content replication, you must meet the following prerequisites:

  • Content replication is only available for Nexus Repository Pro customers; you must have a valid Nexus Repository Pro license to proceed.

  • Ensure you are on the latest Nexus Repository Pro version and that both the source and target instance are on the same version.

  • Both instances must be using a PostgreSQL database.

  • The source repository must be a hosted repository.

  • The target repository must be a proxy repository.

Is Content Replication Appropriate for My Use Case?

Content replication is primarily used to make content readily available to distributed teams. When enabled, content replication fetches content before you ask for it, reducing latency.

For distribution use cases that are not sensitive to latency, Sonatype Nexus Repository’s standard proxying feature may be sufficient.

Unless you specify limitations through a RegEx pattern in the Asset Name Matcher field, the content replication task will fetch all new content, which may significantly expand your storage needs.

Content replication is not appropriate for disaster recovery. If you need a disaster recovery solution, please see our High Availability and resilient deployment options and backup and restore procedures.

Note that you cannot use Sonatype Repository Firewall with content replication. Further, you can only use content replication with a hosted repository source, which cannot use Sonatype Repository Firewall. Proxy repositories serving as the target for content replication will only contain components from these hosted repositories.