Runtime configuration delivery

Configuration changes become live only after a managed data-plane replica has accepted a new runtime projection. This is how MCP Gateway moves an approved policy, server, credential-binding or Consumer OAuth change from the control plane to the runtime that serves your tools.

Diagram showing a configuration heartbeat. Published configuration and OAuth key freshness feed PostgreSQL. Each data-plane heartbeat causes the control plane to prepare a configuration fingerprint; unchanged replicas continue with their current configuration and changed replicas fetch a full snapshot. — Each managed replica compares the control plane's desired configuration fingerprint with the fingerprint of its active runtime snapshot.

What starts a change?

The control plane holds the approved configuration for a tenant, environment and data plane. A new policy, approved server configuration, credential-binding change, Consumer OAuth configuration change, revocation, or refreshed authorization-server key state can change the runtime projection.

The data plane does not make those decisions locally. It receives the desired state from the control plane through its authenticated Fleet session.

How the check works

Each managed replica sends a Fleet heartbeat with the identity of its active snapshot. The control plane accepts the heartbeat, records the replica’s activation state, reads the current effective configuration, validates it and calculates a configuration fingerprint.

The heartbeat response carries that desired fingerprint.

If it matches the replica’s active fingerprint, the replica continues serving with its current configuration. It does not download a full projection or create a new delivery artifact.
If it differs, the replica asks for a full snapshot.

The heartbeat interval is an operational setting. Treat the next accepted heartbeat as the normal propagation mechanism, rather than relying on a fixed customer-facing latency promise.

When a full snapshot is needed

Diagram showing full configuration delivery. A changed fingerprint or a new Fleet session causes a data-plane replica to request a snapshot. The control plane builds, stores and delivers the artifact. The replica validates, activates and acknowledges it; an invalid snapshot is rejected. — Startup, session renewal and a changed fingerprint all enter the same validated snapshot-delivery path.

For a full fetch, the control plane builds and validates the projection again, stores an immutable delivery artifact and binds that delivery to the specific replica. The replica validates the document before activation. Its next heartbeat acknowledges the activation back to the control plane.

What this means for operators

When a configuration change appears not to have reached a tool call, check the data plane’s readiness and projection state before changing policy or credentials again. A healthy replica should show an accepted heartbeat and the expected active projection after it has activated the new snapshot.

Each replica follows this process independently. During a rollout or recovery, replicas can acknowledge at different times. The control plane tracks those acknowledgements instead of assuming that one replica’s update proves the fleet has converged.

Managed and self-hosted boundaries

This Fleet handshake describes the managed data-plane path. Self-hosted deployments use their configured runtime-projection source and keep the same safety rule: the data plane enforces only a valid, approved projection and fails closed after the allowed freshness window.

Source truth

Read Control plane vs data plane for the ownership boundary.
Read Check deployment status when a change has not reached a replica.
Read Audit & investigation for the metadata recorded around governed calls.

Amelfi documentation · Space Grotesk / Geist Mono