Hello everyone! 👋 Apologies for bringing this up again — I'd really appreciate hearing from anyone who has experience running 500+ rego policies managed with the opal-server + opal-client stack. The problem: I run opa and opal-client-standalone as sidecars in the same k8s pod. During cold start, the initial policy sync takes over 10 minutes, during which the OPAL client reports an unhealthy status — causing the pod to fail both readiness and liveness probes. Opal-client logs:

2026-03-03T20:36:11.372421+0000 | 16 | opal_client.policy_store.opa_client     | WARNING | OPA client health: False (policy: False, data: True)
2026-03-03T20:36:11.373165+0000 | 16 | uvicorn.protocols.http.httptools_impl   | INFO    | 10.100.35.127:51372 - "GET /healthcheck HTTP/1.1" 503
2026-03-03T20:36:11.379258+0000 | 16 | uvicorn.protocols.http.httptools_impl   | INFO    | 10.100.35.127:51384 - "GET /ready HTTP/1.1" 503

Root cause: OPAL pushes each policy individually via PUT /v1/policies/{path} to the OPA agent. With 500+ policies, each PUT takes ~0.5s+, and this duration appears to grow as more policies are loaded (likely because OPA recompiles/re-evaluates the entire policy set on every single insertion (not sure tho)). This sequential loading leads to a prohibitive startup time. OPA logs:

{"client_addr":"[::1]:37922","level":"info","msg":"Received request.","req_body":"<policy_content>","req_id":3841,"req_method":"PUT","req_params":{},"req_path":"/v1/policies/main/domain/subdomain/policy1.rego","time":"2026-03-03T20:23:39Z"}
{"client_addr":"[::1]:37922","level":"info","msg":"Sent response.","req_id":3841,"req_method":"PUT","req_path":"/v1/policies/main/domain/subdomain/policy1.rego","resp_body":"{}\n","resp_bytes":3,"resp_duration":631.523340,"resp_status":200,"time":"2026-03-03T20:23:39Z"}
{"client_addr":"[::1]:37934","level":"info","msg":"Received request.","req_body":"<policy_content>","req_id":3842,"req_method":"PUT","req_params":{},"req_path":"/v1/policies/main/domain/subdomain/policy2.rego","time":"2026-03-03T20:23:39Z"}
{"client_addr":"[::1]:37934","level":"info","msg":"Sent response.","req_id":3842,"req_method":"PUT","req_path":"/v1/policies/main/domain/subdomain/policy2.rego","resp_body":"{}\n","resp_bytes":3,"resp_duration":716.441353,"resp_status":200,"time":"2026-03-03T20:23:39Z"}

What I've considered to solve: one idea is to use bundles and pre-bake the policies into the OPA container image (e.g. via opa run --bundle /policies, or different methods), so that OPA boots up instantly with all policies already compiled. However, OPAL client has no concept of a "starting commit hash" or awareness that OPA already has the policies — its internal state is in-memory and lost on every restart. So it would still perform the full sync via individual PUTs on every cold start, making the pre-bake effectively useless unless there's a way to tell OPAL "the store is already up-to-date as of commit X — only sync the delta." I’d be very interested to know: - whether others have seen similar behavior at this scale and how you handled/mitigated this - whether there is a way to make OPAL skip the initial full sync if OPA is already pre-loaded (e.g. by providing the last policy commit hash present in the bundle) - whether there is a way to switch OPAL to deliver policies as an OPA bundle instead of individual PUT calls Any real-world experience or recommendations would be very helpful. Thanks!!! 🙏☺️

Hi @Andrea Di Saverio, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.

Hey @Andrea Di Saverio, did the Bot provide you with what you needed? Have you tried Bundling techniques like it suggests?

hi @david, thanks for your reply. The suggestion provided by the Bot is about using the bundle mechanism. I tried it, but it doesn't solve the problem since the bundle is only used by the opal-server to retrieve all the policies (bundled), but it doesn't affect the way the opal-client feeds the opa agent: it still does the sequence of POST calls to the agent, so the problem is not solved.

Understood, I will confer with the team and get back to you 🙂

thank you a lot ♥️ very curious about real-world experiences from you

There's no alternative solution here. reduce the number of files you have, compile them together (as part of the bundle server for example).