Platform Federation
Overview
JFrog Platform Federation connects multiple JFrog Platform sites into a single mesh of peers that keeps the platform configuration identical on every site.
Changes made on any member site are automatically synced to all other member sites, so you can scale globally and stay consistent everywhere, without manual cross-site updates.
In earlier multi-site setups, Access Federation and Federated Repositories synced users and artifacts, while everything else (such as Projects, policies and repository configurations) had to be managed per site, usually with scripts or IaC. Platform Federation is the next generation federation solution. It extends federation to additional platform entities and configuration, and orchestrates the federation of repositories, including local, remote and virtual repositories.
For the full announcement, see the blog post Introducing JFrog Platform Federation.
Why
- Member sites share one platform configuration, so they do not drift apart
- A change on any member site syncs to the other member sites
How
- Connect the sites as a mesh of peers
- Plan and set it up with Plan the Platform Federation
Key Capabilities
- Manage once, apply everywhere: Automate global administration across all distributed sites and eliminate manual overhead
- Repository provisioning: Map the global stages to sites once. Repositories are provisioned automatically on every site mapped to their stage
- Zero configuration drift: Monitor the federation in real time and reconcile drift as soon as it appears
What Gets Synced
- Global Entities: Platform entities and configurations, including Projects, stages and roles, access control and policies
- Repositories: Repositories are provisioned on the member sites from the main site, according to the Stage to Site mapping:
- Local repositories: Configuration and artifacts are federated. The artifacts are kept in sync using Federated Repositories
- Remote and virtual repositories: Configuration only is federated
- Curation policies: Already supported as part of Curation Federation, currently as a standalone solution. Curation Federation is planned to be included in Platform Federation
Architecture
Global Entities are synced directly between all member sites as equal peers. Repositories are provisioned from the main site.
flowchart LR
A["JFrog SaaS<br/>Main Site"]
B["JFrog SaaS<br/>Site B"]
C["JFrog SaaS<br/>Site C"]
A <-- "Global Entities" --> B
B <-- "Global Entities" --> C
A <-- "Global Entities" --> C
A -. "Repository provisioning" .-> B
A -. "Repository provisioning" .-> C- The Platform Federation is managed from the main site. Global Entities sync does not depend on the main site, so it is not a single point of failure for mission critical operations
- If a site goes offline, the other sites keep syncing. The offline site catches up automatically when it returns
- Sync events can be monitored from the platform UI and the REST API of the main site
Operations and Site Availability
Global Entities are synced in a mesh of peers, but not all operations are handled the same way:
| Operations | Where they run | When the main site is down |
|---|---|---|
| Mission critical, such as managing Global Entities and uploading and downloading artifacts in existing repositories | On any member site, without depending on the other sites | Available. Changes are eventually consistent, and are synced to the other sites once they are reachable |
| Stage to Site mapping updates, which provision the repositories to the sites | On the main site only | Not available |
| Repository creation and configuration updates | Requires the main site, and all the sites the repository is provisioned to, to be available | Not available |
When the main site is down, the member sites keep serving mission critical operations, while some non-critical operations are not available until the main site is back.
Where It Fits in the Use Cases
Platform Federation is the foundation of a Multi-Site deployment, keeping all sites complete and uniform peers.
| Use case | Role of Platform Federation |
|---|---|
| Active-Passive and Disaster Recovery | Recommended. The passive site is a live copy of the platform configuration, so a failover does not require reconfiguring access, Projects or repositories |
| Active-Active | Recommended. Every site serves its developers with the same configuration and repositories, so regional teams work in the same logical workspace with local performance. New sites (a new region, an acquisition or a business unit) receive the platform context (such as Projects) when they join |
| CI/CD Separation | Use when the CI and CD sites share the same Projects and access model |
| Main Site with Edges | Use for the full sites. Edge nodes are not members of a Platform Federation; use Access Federation for them |
| Subsidiaries and Vendors | Platform Federation keeps the configuration uniform across all member sites. When each site requires its own users or permissions, use Access Federation with filters |
Implementation Guidelines
- Prerequisites: Enterprise+ subscription with the Platform Federation entitlement, and all sites live and in the same Circle of Trust
- Align before joining: When a Platform Federation is created, or a site is added to it, the most recent value of each Global Entity is applied to all member sites. Overwritten values cannot be restored, so align the configuration of the sites in advance
- Mesh topology and uniform configuration: All member sites sync with each other as peers, and all Global Entities are synced to all of them, with no filtering or mapping per site. Star and chained topologies still require Access Federation
- One Platform Federation per site: A site can be a member of only one Platform Federation
- Existing federation: Federated Repositories and Curation Federation keep working on sites that join a Platform Federation
- Impact of removing a site: A removed site keeps the last synced configuration, and stops sending and receiving updates