Skip to content

More than one deployment

One deployment can call another.

A group with several brands, regions, or subsidiaries ends up with several deployments. Federation lets them delegate work to each other on purpose, with the loop and abuse problems solved rather than left to policy.

The guard

Why this cannot run away.

Delegation carries a hop count and a trace across every instance boundary. A request that exceeds the limit, or that arrives carrying a trace already in flight, is refused rather than forwarded. The guard is always on, on every plan.
Federated delegation across four deployments, with the hop limit refusing a fourth hopGroup HQ delegates to a retail brand deployment, which delegates onward to logistics, then to a support desk. Each step increments a hop counter carried across the instance boundary. A fourth hop back to Group HQ is refused because the trace is already being handled.123refused: trace already handledGroup HQparentRetail brandchildLogisticschildSupport deskpeer
How it works

What the capability actually does.

A register of who you trust

Each link names a remote deployment as parent, child, or peer, with its base URL checked before it is ever called. Enabling and disabling a link is one toggle, and the whole register is visible in one screen.

A loop cannot form

Delegation carries a hop count and a trace across the instance boundary, propagated by every onward call. A request that exceeds the hop limit, or that arrives carrying a trace already being handled, is refused. This guard is always on, on every plan, because a delegation loop between two customers is not a licensing matter.

Inbound is governed too

A link records the API key the remote instance presents. You can require that inbound federated work arrives on a key bound to an enabled link, and rate limit each link independently.

A misbehaving peer disables itself

Repeated failures from one link trip a circuit breaker that disables it, writes an audit entry, and fires a webhook. It stays disabled, and visibly marked, until someone looks at it.

In the product

The screens this happens on.

The global settings area where deployment-wide configuration including federation links is managed

Where federation links are governed

Deployment-wide configuration, including the register of remote instances this one is linked to. Each link records whether the remote is a parent, a child, or a peer, and its address is validated before it is ever called. A link that keeps failing disables itself and is marked here rather than retrying quietly.

  • Inbound work can be restricted to a key bound to an enabled link
  • Each link is rate limited independently
Boundaries

What it deliberately does not do.

Stated here rather than discovered in production. Every one of these is a real constraint, and knowing them before you buy is worth more than a longer feature list.
  • Federation is an Enterprise capability. The 14 day trial carries it so it can be evaluated properly.
  • The loop guard applies from the first hop across an instance boundary. A single deployment calling its own Orchestrators is unaffected.
  • The inbound allow-list is off by default, because turning it on before links are configured would refuse work that should be accepted.
  • This is delegation between deployments you control. It is not a way to make one deployment serve several customers, which remains out of scope.
Elsewhere

The rest of the platform.

See what it costsCompare it