OPAL (Open Policy Administration Layer) is designed specifically to handle distributed policy agents like OPA. Here's how it works: How OPAL Distributes Policies to Multiple PDPs OPAL uses a ​*pub/sub (publish/subscribe) architecture*​ to distribute policies and data to all connected OPAL clients (which manage the OPA/PDP instances) . (1) ​*The flow works like this:*​ 1. ​*OPAL Server*​ detects changes to policies (typically from a Git repository) or receives data update triggers via its REST API 2. ​*Updates propagate*​ between OPAL servers and are then sent to the relevant subscribing clients according to their ​*topics*​ 3. ​*OPAL Clients*​ subscribe to specific topics and receive updates via a lightweight WebSocket pub/sub channel—updates typically propagate within milliseconds 4. Once a client receives an update, it uses a ​*data-fetcher*​ to fetch the actual data/policy according to the instructions in the event Key Distribution Mechanisms • ​*Topic-based subscriptions*​: Clients subscribe to specific topics, allowing you to target which PDPs receive which updates • ​*Baseline + follow-on updates*​: New or reconnecting clients receive a baseline state, then continue receiving incremental updates • ​*Automatic reconnection*​: OPAL clients constantly try to reconnect to servers with exponential backoff, and upon reconnection will fetch baseline data again to reach a consistent state Scaling with a Backbone For production deployments with multiple OPAL servers, you can configure a broadcast backbone using Kafka, Redis, or Postgres to ensure updates are synchronized across all servers before being pushed to clients. Check out these potentially useful sources for more details: • Data updates FAQ • On-Premises Deployment

To learn more, see the sources I considered: [[1] Data updates](https://docs.opal.ac/faq/)

Great addition! ​*OPAL Scopes*​ allow you to serve different policies and data sources to different groups of PDPs from the same OPAL server. (1) ​*How Scopes Work*​ Every scope contains its own policy and data sources—all clients using the same Scope ID will receive the same policy and data. This is useful when you need: • Multiple Git repositories (or other policy sources) managed by a single OPAL server • Multi-tenant setups where different customers or services require isolated policies • Different policy directories or branches for different environments (e.g., "internal" vs "external" apps) ​*Setting Up Scopes*​ Scopes are dynamic and can be created on the fly through the

/scopes

API. The OPAL server must be started with

OPAL_SCOPES=1

environment variable. You can then create scopes via REST API—for example, creating an "internal" scope that pulls policies from the

internal

directory and an "external" scope from the

external

directory of the same repo. ​*Launching a Client with a Scope*​

docker run -it \
  --env OPAL_CLIENT_TOKEN \
  --env OPAL_SERVER_URL \
  --env OPAL_DATA_TOPICS \
  --env OPAL_SCOPE_ID=internal \
  -p 7766:7000 \
  -p 8181:8181 \
  permitio/opal-client

Full documentation here: OPAL Scopes

To learn more, see the sources I considered: [[1] OPAL Scopes](https://docs.opal.ac/overview/scopes)