Technical decision brief
Cerbos vs OPA
OPA is a general-purpose policy engine that evaluates Rego policies over structured data. Cerbos is purpose-built for fine-grained authorization across applications, APIs, agents, services, and workloads. The comparison covers both engines and the lifecycle tooling around them.
The decision
Choose Cerbos when
- Default to Cerbos when the scope is application authorization and teams want principals, resources, actions, roles, conditions, tests, audit, and query planning as product primitives.
- Operating Rego conventions, bundle infrastructure, decision-log collection, or application-specific query adapters creates material maintenance work.
- Policy reviewers prefer an authorization-specific YAML or JSON schema with CEL conditions over a general-purpose language.
Choose OPA when
- Choose OPA where one engine must cover Kubernetes admission, infrastructure, CI/CD, and policy shapes outside application authorization.
- Keep OPA where an existing platform is stable and its Rego expressiveness or ecosystem is a verified requirement.
At a glance
What application teams ask for
The table describes documented mechanisms. It does not assign winner scores.
| Requirement | Cerbos | OPA |
|---|---|---|
| Application authorization primitives | Models principals, resources, actions, roles, and derived roles directly in policy. | Models anything expressible in Rego, with authorization conventions left to your team. |
| Evidence for Application authorization primitives | ||
| Policy testing and CI | Ships a first class test format and compile checks designed for authorization policies. | Provides mature testing through opa test and surrounding tooling. Genuine parity on this row. |
| Evidence for Policy testing and CI | ||
| Decision logging and audit | Provides configurable decision logging to file, Kafka, local storage, or Cerbos Hub. Cerbos Hub adds managed collection and search. | Provides configurable decision logging. OPA core requires a collector or control plane for durable storage and search. |
| Evidence for Decision logging and audit | ||
| List filtering and query planning | PlanResources returns a query plan, with reference adapters for Prisma, Drizzle, Mongoose, Convex, LangChain/ChromaDB, and SQLAlchemy. | The Compile API returns partially evaluated queries or a JSON AST. Use an ecosystem adapter or build translation for the target query layer. |
| Evidence for List filtering and query planning | ||
| Managed policy distribution | Cerbos Hub builds, tests, signs, and distributes policies from Git and other policy-store workflows. The open source Cerbos PDP also supports disk, Git, object storage, database, and Cerbos Hub stores. | OPA core supports bundle distribution. The Apache 2.0 OPA Control Plane adds self-hosted Git-based policy management, bundle building, external data sources, and object-storage distribution. |
| Evidence for Managed policy distribution | ||
| SDK language coverage | Provides REST and gRPC APIs with official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel. | Exposes REST, a Go API, WebAssembly, and a broad ecosystem of language SDKs and integrations. Maturity varies, so verify the specific package. |
| Evidence for SDK language coverage | ||
| AuthZEN compatibility | The Cerbos PDP partially implements AuthZEN Authorization API 1.0. Alex Olivier is one of the current AuthZEN Working Group cochairs. | OPA core does not document native AuthZEN endpoints. OPA participated as a PDP in the 2025 OpenID interoperability event; verify the adapter, gateway, and specification version required. |
| Evidence for AuthZEN compatibility | ||
| Infrastructure and platform policy | Focuses on authorization decisions and can integrate with infrastructure systems through Cerbos Synapse. It is not a general-purpose admission-policy engine. | Has mature ecosystem projects for infrastructure policy. Gatekeeper is the OPA project's recommended Kubernetes admission-control integration. |
| Evidence for Infrastructure and platform policy | ||
Deep dive 1
The policy model trades breadth for application structure
OPA evaluates arbitrary Rego over structured data. Cerbos fixes the outer model around application authorization and uses CEL for conditions.
OPA can express application, infrastructure, admission, configuration, and pipeline policy. The team defines its own input schema, package conventions, decision shape, and reusable libraries.
Cerbos models principals, resources, actions, roles, derived roles, scopes, conditions, and structured outputs directly. This is less general than Rego and makes more authorization conventions common across services.
Migration should start by identifying the application-authorization subset of the Rego estate. Infrastructure and admission policies can remain on OPA while application decisions move to Cerbos.
Deep dive 2
Both engines are open source; the surrounding ownership differs
OPA core provides engine primitives and bundle support. Cerbos packages authorization-specific runtime and lifecycle mechanisms across Cerbos PDP, Cerbos Hub, and Cerbos Synapse.
OPA provides policy evaluation, testing, bundles, decision logging, partial evaluation, REST, Go, and WebAssembly integration. The self-hosted OPA Control Plane adds Git-based management, bundle building, external data, and object-storage distribution.
The Apache 2.0 Cerbos PDP provides authorization APIs, policy tests, decision logging, and query planning. Cerbos Hub adds managed build, test, signed distribution, and audit aggregation. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, without a per-decision service call. Cerbos Hub Enterprise can run on-premise in restricted and air-gapped environments.
Cerbos Synapse is a separate commercial component for decision-time data and protocol or integration extensions. It runs in customer-controlled infrastructure. Neither Cerbos Hub nor Cerbos Synapse changes the open source licence of the Cerbos PDP.
Deep dive 3
List filtering exposes the integration cost
OPA can partially evaluate policy. Cerbos returns an authorization-specific query plan with reference data-layer adapters.
OPA's Compile API can return partially evaluated queries or a JSON AST. The application still needs a safe translation layer for its ORM, database, or search system.
Cerbos PlanResources returns a datastore-agnostic query plan for the requested principal, action, and resource kind. Reference adapters translate supported plan shapes for selected data layers.
Neither approach removes the need to validate query semantics and unsupported expressions. Compare the real adapter code, generated predicate, and returned records for representative policies.
Implementation
Separate reusable authorization intent from Rego implementation
Translate the input contract and decision table before translating expressions. Keep OPA for policy domains that require its general-purpose model.
| OPA or Rego concept | Cerbos | Migration or coexistence note |
|---|---|---|
| input.subject or input.user | request.principal | Normalize the principal ID, roles, and attributes at the enforcement point. |
| input.resource | request.resource | Assign a resource kind and ID, then pass domain attributes under resource.attr. |
| input.action and allow rule | Rule actions and EFFECT_ALLOW or EFFECT_DENY | Derive an explicit action-by-scenario decision table before modeling rules. |
| Rego helper rule | Derived role, scoped policy, or CEL condition | Choose the construct by domain meaning. Do not mechanically inline every helper into CEL. |
| Partial evaluation or Compile API | PlanResources query plan | Replace and test the data-layer translation separately from single-resource checks. |
An owner-or-editor document policy
document.yaml
apiVersion: api.cerbos.dev/v1
resourcePolicy:
version: default
resource: document
rules:
- actions: ["view", "edit"]
effect: EFFECT_ALLOW
condition:
match:
expr: request.resource.attr.ownerId == request.principal.id
- actions: ["view", "edit"]
effect: EFFECT_ALLOW
roles: ["editor"]The enforcement point sends the principal, document resource, and requested action to CheckResources. Add deny cases, missing-attribute cases, and scope variants to the Cerbos policy test suite before comparing with the Rego result.
Deployment
Deployment control spans the Cerbos platform
The components can be adopted independently and placed according to runtime, governance, and network requirements.
Cerbos PDP
The Apache 2.0 decision engine runs as a shared service, sidecar, DaemonSet, or selected serverless topology.
Explore Cerbos PDPCerbos Hub
Commercial Cerbos Hub is hosted by default and is available to enterprise customers on-premise for restricted and air-gapped environments. The Cerbos ePDP evaluates Cerbos Hub-managed policy bundles in-process through WebAssembly in JavaScript environments.
Explore Cerbos HubCerbos Synapse
The commercial enrichment and integration layer runs in customer-controlled infrastructure in front of an embedded or external PDP.
Explore Cerbos SynapseCerbos capabilities
Follow the implementation details
These pages document the Cerbos mechanisms referenced throughout this comparison.
Research basis and disclosure
Claims were reviewed against public product documentation, official project material, and standards sources on 24 July 2026.
Compiled from public documentation in July 2026. Details change, so verify current capabilities before you decide.
Competitor documentation informed this comparison but is not linked from this page. Cerbos documentation and neutral standards or foundation sources were checked separately.
Alex Olivier, Cerbos cofounder and CPO, is one of the current OpenID Foundation AuthZEN Working Group cochairs. The Cerbos PDP API reference states that it partially implements the AuthZEN Authorization API.
Test the decision
Use Cerbos for application authorization and keep OPA where it fits
Cerbos is the stronger overall choice for application authorization because its PDP, policy model, tests, audit, query planning, Cerbos Hub distribution, and optional Cerbos Synapse enrichment are designed around that problem. Prove the boundary with one Rego package that performs single-resource checks and list filtering. Run both engines in parallel and compare decisions, data predicates, latency, memory, rollout, and operational work. Keep OPA for admission, infrastructure, and other general-purpose policy domains.