I can't comment on issue #966 or its linked PR. It isn't in the sources I have, so I can't speak to its design or status. Here is what is documented about the setup you describe. ​*What OPAL supports today*​ OPAL can use an API bundle server as the policy source instead of a git repo. The server fetches a

bundle.tar.gz

over HTTP, extracts it locally, and builds a git repo from the contents to track changes. It detects new bundles by ETag, or by hashing the file if the server doesn't support ETags. (1) Two change-detection modes are available: polling every

OPAL_POLICY_REPO_POLLING_INTERVAL

seconds, or a webhook to

<opal-server-url>/webhook

. (1) For authentication,

POLICY_BUNDLE_SERVER_TYPE

supports

HTTP

(bearer token or no auth) and

AWS-S3

. Credentials go in

POLICY_BUNDLE_SERVER_TOKEN_ID

and

POLICY_BUNDLE_SERVER_TOKEN

. (1) An Artifactory-style server would fall under the generic

HTTP

type, but the sources don't document JFrog specifically. ​*What isn't covered*​ The documented model is a single

OPAL_POLICY_BUNDLE_URL

, so a single bundle source. (2) The sources don't describe pulling several bundles and routing them to different clients, which is what your feature request proposes. ​*Per-client distribution with one source*​ Once the policy is in the tracked repo, clients can subscribe to specific directories via

OPAL_POLICY_SUBSCRIPTION_DIRS

, with

:

as the delimiter. Each client then receives only the policy files under those directories. (3) For example: •

edge1

sets

OPAL_POLICY_SUBSCRIPTION_DIRS=default:tenants/tenant1

•

edge2

sets

OPAL_POLICY_SUBSCRIPTION_DIRS=default:tenants/tenant2

This gives selective distribution, but from one source whose directory layout does the partitioning. (3) Since your use case is separate bundles per team or service, the closest fit today is to compose them into one

bundle.tar.gz

with a directory per bundle, then use the subscription directories above. Multiple independent bundle sources would be a new capability. OPAL also has a scopes concept for multi-tenancy, which may be relevant to your design. (2) For feedback on the PR itself, the OPAL maintainers on GitHub are best placed to review it, and you can also reach out at help@permit.io.

To learn more, see the sources I considered: [[1] Policy syncing from API](https://docs.opal.ac/tutorials/track_an_api_bundle_server) [[2] OPAL Configuration Guide | OPAL](https://docs.opal.ac/getting-started/configuration) [[3] Track a Git Repo | OPAL](https://docs.opal.ac/tutorials/track_a_git_repo)