Hi Alex,
You read that right - content sync is designed for strictly linear topologies only. A target can be chained to act as the source for a further target (e.g., STG → PROD-A → PROD-B), but a single source syncing to two independent targets at the same time is explicitly listed as an unsupported topology in the docs. It won't be hard-blocked, but you're likely to end up with inconsistent state or unintentional overwrites, since each target ends up with its own independent synchronization history.
A few practical options depending on what you actually need:
1. Chain it instead of branching it
Set it up as STG → PROD-A → PROD-B. PROD-A needs Target enabled (receiving from STG) and Source enabled (sending to PROD-B), each with its own secret. The only downside is a small propagation delay to PROD-B - the "Content sync restoration" scheduled task runs roughly every 30 seconds per hop, so PROD-B lags PROD-A by about one cycle.
2. Don't use content sync for this at all
If PROD-A and PROD-B are supposed to be identical (e.g., two nodes/regions), that's usually a sign they shouldn't be modeled as two separate content-sync targets in the first place. Treat them as one logical Production environment and keep them aligned the way you already keep code/content types aligned - via your CI/CD repository export/import or deployment package, not content sync. Content sync is built for the "prepare then publish" flow (dev/local → staging → production), not for keeping N production replicas of the same environment in step - that's more of an infrastructure/HA concern (shared DB behind a load balancer with stateless app nodes) than something content sync is meant to solve.
3. If you genuinely need two independent production databases kept current
I haven't seen a supported branching setup work reliably in practice. What's worked for teams I know is triggering two separate deployment jobs off the same release trigger using CI/CD repository export/import rather than content sync - that mechanism is designed to be run against multiple targets from the same source data, unlike content sync.
So no, there isn't a supported way to fan a single staging source out to two production targets simultaneously with content sync - that's called out explicitly under "Supported topologies" in the docs you linked. Chaining, or falling back to your normal deployment pipeline for the second target, are the realistic paths forward.
