Repository Replication

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

NEW IN 3.34.0

We are redesigning replication in 2022 to remove Replicator and make it easier to set up and deploy. Once we release the new implementation, we will no longer support the replication method detailed here.

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

What is Repository Replication?

Repository replication allows you to publish artifacts to one Nexus Repository Pro instance and make them available on other instances to provide faster artifact availability across distributed teams.

With repository replication, you can manage what binaries can be replicated between two or more instances. The following diagram illustrates the replication process. 


Replication Use Cases

Primary Use Case

Repository replication is primarily used to make content in one repository available to another repository as soon as it is published so that users on the second instance do not have to wait for Nexus Repository to proxy content from another instance. With large files (e.g., Docker images), waiting for Nexus Repository to proxy content from another instance can induce timeouts. So, rather than using a proxy repository and only replicating content on demand, we now replicate the content on creation. When a person or CI tool on the target end requests content, their local Nexus Repository instance will already have that content, so the request won't induce any timeouts to the format-specific client as Nexus Repository can immediately start serving the new content. This use case is illustrated above.

Replicate One Source to Multiple Targets

You can also use repository replication to replicate content from one source repository to multiple target repositories. You may use this setup if you have a central Nexus Repository server with multiple sites in other parts of the world and the need to push all content from the central server to those other sites for speedier local access for developers. This setup is illustrated below with setup detailed in Replication Scenarios.

Bi-Directional Replication

You could also set up a bi-directional replication scenario where content is replicated between two geographically separate locations. You would use this setup if you had two locations with separate Nexus Repository instances (Team A using Instance A and Team B using Instance B). If both teams consume content that the other team creates, you would need to replicate content in both directions so that Team A has quick access to the content Team B publishes and vice versa. This setup is illustrated below with setup detailed in Replication Scenarios