--- title: "Collective Replication" slug: "collective-replication-v6-7" updated: 2026-08-21T13:28:37Z published: 2026-08-21T13:28:37Z canonical: "support.appgate.com/collective-replication-v6-7" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.appgate.com/llms.txt > Use this file to discover all available pages before exploring further. # Collective Replication Collective replication distributes a shared configuration baseline from a **source Collective** to one or more **target Collectives**. The shared configuration can include policies, entitlements, conditions, roles, and more. Collective replication is designed to help organizations and managed service providers (MSPs) scale consistently across regions, tenants, and environments while maintaining a governed security and access posture. Collective replication provides: - Centralized configuration distribution and scale-out to multiple target Collectives, whether in a single enterprise or across multiple tenants. - Ensured continuity and access even if parts of the environment are unreachable, degraded, or operating offline. - Environmental integrity with safe, reliable movement of a configuration between lifecycle stages, keeping non-production environments and disaster recovery environments functional. Collective replication is a separately licensable feature. For more information, see the [Licenses](/v1/docs/licenses-v6-7) section. ![Diagram illustrating source and target collectives with configuration pulling processes.](https://cdn.us.document360.io/e7482ce5-acfa-4c3b-b76c-b6c32472644a/Images/Documentation/collective-replication-1-architecture.png?sv=2026-02-06&spr=https&st=2026-10-26T22%3A55%3A44Z&se=2026-10-26T23%3A55%3A44Z&sr=c&sp=r&sig=8UvCMtJP%2BRj6DJ8aAoLuy8YliM0TJ7oS%2FaiALVJGZnM%3D) #### Source Collective The **source Collective** holds the [entities](/v1/docs/collective-replication-v6-7#replicated-entities) that you want to replicate. On the source Collective, administrators can: - Configure entities. - Configure replication target Collectives and assign tags to be replicated to each target Collective. - Decide which entities are replicated to each target Collective by applying the target Collective’s tag. The source Collective acts as the central point of configuration distribution for all subscribed target Collectives. #### Target Collective The **target Collective** receives a selected subset of AppGate ZTNA [entities](/v1/docs/collective-replication-v6-7#replicated-entities) from the source Collective. The target Collective uses the Admin API and a service on the Controller on which the replication was configured. It contains a replicated copy of only the entities that have been tagged for that target Collective. Collective replication uses a pull-down model: - The target Collective connects to the source Collective. - The target Collective retrieves (pulls) the entities it needs using the admin API. - The source Collective does not maintain a constant connection to the target Collective, reducing dependency on continuous connectivity. ## Registering a Target Collective Before a target Collective can receive a configuration, it must be registered with the source Collective. To register the target Collective: 1. Generate a registration key in the [**Replication Targets**](/v1/docs/replication-target-v6-7#configuring-a-target-for-replication) page in the **source Collective**. - After creating a replication target in the source Collective, an administrator copies the registration key. 2. Use the registration key in the **target Collective**. - In the target Collective, paste the registration key in the ***Key*** field if the [**Replication Source**](/v1/docs/replication-source-v6-7) page to connect to the source Collective. 3. Tag the entities to replicate. - In the **source Collective**, administrators apply one or several of the target Collective’s tags to specific entities (for example, Sites, policies, or entitlements). - Only entities with at least one of those tags are eligible for replication to that target Collective. ## Replication Synchronization Once registered, a target Collective keeps its configuration in sync with the source Collective in two ways: ### Periodic Replication The **target Collective** periodically pulls configuration from the **source Collective** using the admin API. You can view when the next replication will occur in the **Replication Source** page next to ***Source Replication Status***. ### On-Demand Replication In addition to scheduled replication, admins can trigger a manual replication from the admin UI: 1. From the replication target, go to the **Replication Source** page. 2. Select Actions > *Replicate from source now.* ![Overview of registration, sync, and replication status in a data management process.](https://cdn.us.document360.io/e7482ce5-acfa-4c3b-b76c-b6c32472644a/Images/Documentation/collective-replication-2-sync-lifecycle.png?sv=2026-02-06&spr=https&st=2026-10-26T22%3A55%3A44Z&se=2026-10-26T23%3A55%3A44Z&sr=c&sp=r&sig=8UvCMtJP%2BRj6DJ8aAoLuy8YliM0TJ7oS%2FaiALVJGZnM%3D) ## CA certificate renewal with Collective Replication When renewing the CA certificate (Settings > Licenses) for a Collective that uses Collective Replication, wait at least 30 minutes after uploading the new certificate before activating it. Replication runs every 15 minutes and receives the next CA certificate automatically during authentication. Activating the CA certificate before Collective Replication receives it breaks replication and requires manual reregistration. The 30-minute wait accounts for delays caused by system load, network latency, and internal timing. ## **Disconnecting and Reconnecting Replication** If you need to remove entities from the target Collective: 1. In the source Collective, go to **Replication Targets**. 2. Select **Actions** > *Change item replication tags > Remove item replication tag*. 3. Select tags to remove from the drop-down. 4. Wait for the next sync. 5. From **Replication Source** in the target Collective, select **Actions** > *Disconnect*. If you don’t need to remove entities, simply disconnect. When you reconnect a target Collective to the same source: 1. Previously replicated entities are automatically reclaimed by their matching IDs. 2. Reclaimed entities: - Become read-only again. - Have their configuration replaced with the current version from the source Collective. - Lose any changes made during the disconnected period. To preserve custom changes made while disconnected, clone the entity before reconnecting. ### Service Downtime Restrictions Collective replication should not be stopped for extended periods. The service must be restarted within three to seven days after it has been stopped. If downtime exceeds this timeframe, you must reregister the target collective to resume replication. ## Replicated Entities The following AppGate ZTNA entities can be replicated: - Admin roles - Client profile groups - Conditions - Criteria scripts - Device claim scripts - Entitlement scripts - Entitlements - Identity providers - IP pools - MFA providers - Policies - Ringfence rules - Sites - Tags (only the tags configured for the target Collective) - User claim scripts If you attempt to edit a replicated entity, you will see a message with the blue **R** icon stating that it cannot be modified. To make a replicated entity editable, you can clone the entity or disconnect the target Collective. > [!NOTE] > NOTE > > Only the tags that are specified for the specific target will be included in the replicated entities ### Entity Relationships and Order Some entities depend on others, for example: - **Sites** are foundational and role-based. Many other entities refer to them. - **Entitlements** require that their referenced Sites already exist. Because of these dependencies, it's important to tag all entities that rely on each other with the same tags. If they are not tagged properly, there will be replication warnings and the replication will be incomplete. ### Secrets Management Between Collectives Collective replication uses the normal Controller API in which secrets are not exposed, so secrets must be manually moved from the source Collective to the target Collective. The following fields are considered secret: | Field Name | Admin UI Location | | --- | --- | | ***Client Secret*** | Identity Providers > OIDC > Google OIDC Configuration > Enable | | ***Password*** | Sites > Cloud Resolvers > Illumio Resolvers | | ***Password*** | Sites > Cloud Resolvers > VMware VSphere Resolvers | | ***Password*** | Sites > Tunneling > Tunnel Traffic > Terminate tunneled… > PKCS #12 Files | | ***Secret*** | Sites > Cloud Resolvers > Azure Resolvers | | ***Service Access Key*** | Sites > Cloud Resolvers > AWS Resolvers > Access Method > Use Access Key | | ***Service Account Password*** | Identity Providers > LDAP/LDAP Certificate > LDAP Configuration | | ***Shared Secret*** | Identity Providers > RADIUS > RADIUS Configuration | | ***User Shared Secret*** | MFA Providers > Authentication > Authentication Mode > RADIUS server MFA | | ***User Shared Secret*** | MFA Providers > Authentication > Authentication Mode > Appgate SDP Challenge-Response MFA | If you have not moved these fields to the Secrets store: 1. Refer to [Configure Secrets](/v1/docs/configure-secrets-v6-7) to add the secret. 2. Go to the field and select *Refer to local secret*, then select the saved secret from the drop-down. The secret then needs to be manually added to the target collective with the same name as in the source collective. If the entities use a normal password entry or if the secret is missing, the replication of the entity will fail and there will be a warning in the **Replication Status Details** page. ## Monitoring Replication Health ### Replication Status Details When Collective replication is initiated, you can view the status of the replication from: - The **Replication Targets** page by selecting the health status of a target. - The **Replication Source** page by selecting the replication under ***Source Replication Status***. Both of these will open the **Replication Status Details** window, displaying a list of entities and how many have completed replication. Possible statuses include: - ***Healthy****.* All entities were replicated successfully. - ***Warning****.* Only some entities were replicated. - ***Error****.* Replication has failed. Details about the errors are provided.