Federated Repositories

JFrog Artifactory Documentation


Subscription Information

This feature is supported with Enterprise X and Enterprise+ licenses.

From JFrog Artifactory 7.18.3, the JFrog Platform enables you to create Federated repositories, which mirror artifacts and their metadata with other Federated repositories on remote JFrog Platform Deployments (JPDs) in a multi-site environment. A Federated repository functions similarly to a local repository on the local JPD but is grouped logically with other Federated members located on remote JPDs to create a Federation.

Once you have created a Federation, changes made to artifacts on one member of the Federation will be replicated asynchronously to the other Federated members. The Federated repository configuration is also aligned across all members of the Federation.

For example, if Federated repository A in "JPD A" and Federated repository B in "JPD B" are members of the same Federation, deploying a file to Federated Repository A in "JPD A", will trigger a copy of the file action to the Federated Repository B in "JPD B".

Similarly, deploying a file to Federated Repository B in "JPD B", will trigger a copy of the file action to the Federated Repository A in "JPD A". The configuration changes are also synchronized based on the latest update (e.g. latest update to the configuration is propagated to all members of the Federation).


A file that is replicated from one Federation member (the source) to a different Federation member (the target) cannot be downloaded by users from the target member until it receives the metadata.

The arrival of the metadata can be verified by seeing the file displayed in the tree browser or the database of the target member.

Starting from version 7.74, Cloud customers can confirm the file's arrival by looking for the following log message:

"Finished the handle mirror event for repo <repo_key> and message: <message>"

Use Cases

Federated repositories provide Enterprise organizations running software in more than one geographical site with a single source of truth for the binaries, as if they were one seamless unit, and support the following use cases:

  • Distributed development teams

  • Remote production environment

  • Increased artifact availability in a multi-site environment

Defining Characteristics

Federated repositories have the following characteristics:

  • Federated repositories use a persistent queue to ensure that events are maintained even in the event of a system failure or restart.

  • Metadata events are updated asynchronously among Federated repositories. However, because of the persistent queue, the repository Federation mechanism ensures that all events will be synchronized among all Federation members. For example, an event might not be sent immediately to a different Federation member due to a server failure or network delays, but the system ensures that the event will be sent eventually.

  • There is no dependency among Federation members, nor is there member priority when synchronizing the metadata. This means that a member which is slow to respond or experiencing heavy traffic will not impact the other members.

  • When the same file is sent from two locations simultaneously, conflict resolution is performed based on timestamps where the last event received overrides previous events. This is why clock synchronization is critical to the proper functioning of the Federation (see Setup Prerequisites for Federated Repositories.