// the find
permitio/opal
Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...)
OPAL is a real-time synchronization layer that sits between your policy engines (OPA, Cedar) and your data sources, pushing policy and data updates via WebSocket pub/sub instead of requiring engines to poll. It's for teams running OPA or Cedar at scale who are tired of stale authorization decisions caused by cache lag or manual reload scripts. Production usage at Tesla and Walmart gives it credibility beyond a side project.
The WebSocket pub/sub architecture is the right call — clients get updates in milliseconds rather than on a polling interval, which matters when your auth data changes on every user action. The fetch provider abstraction is genuinely useful: you can pull data from HTTP endpoints, git repos, S3, or write your own provider without touching core OPAL code. Multi-engine support (OPA + Cedar, with OpenFGA in the topics) means you're not locked into one policy language. The Helm chart and extensive docker-compose examples cover real deployment scenarios including Kafka backbone, rate limiting, and multi-tenant scopes.
The OPAL server is a single point of failure for update distribution — the broadcast channel (Redis or Kafka) is required for HA, which adds ops complexity that the README glosses over. Policy data is fetched client-side directly from sources after the server signals an update, which means the server has no visibility into whether clients actually applied the update successfully; the callback mechanism exists but requires extra setup. Python async codebase with FastAPI is fine, but the config system (custom `confi` library) is non-standard and the env var surface area is large with no schema validation at startup. Cedar support relies on a separate `cedar-agent` sidecar that's also a Permit.io project, so you're implicitly depending on a second less-mature service.