Technical decision brief
Cerbos vs Cedar
Cedar is an Apache 2.0 authorization language and engine ecosystem with strong schema validation and formal analysis. Cerbos combines an Apache 2.0 Cerbos service PDP with an optional Cerbos Hub-managed, in-process WebAssembly ePDP and Cerbos Synapse decision-time data. The right choice starts with the product boundary, not policy syntax alone.
The decision
Choose Cerbos when
- Default to Cerbos when multiple services or languages need one independently deployable authorization API rather than an evaluator embedded into each application.
- Policy build, test, signed distribution, audit collection, list-query planning, or decision-time data would otherwise become internal platform work.
- Deployment control matters across the stack: the Cerbos service PDP and Cerbos Synapse are self-hosted, Cerbos Hub ePDP evaluates in-process, and Cerbos Hub Enterprise is available on-premise for restricted and air-gapped environments.
Choose Cedar when
- Choose Cedar when symbolic equivalence and permissiveness analysis are firm requirements, or when its typed model is the platform standard.
- Choose Cedar when a native in-process Rust or Go implementation, a Java binding, or an embedded engine without a Cerbos Hub dependency is required. An existing Cedar-based AWS workflow can also be decisive.
At a glance
What application teams actually need
The table describes documented mechanisms. It does not assign winner scores.
| Requirement | Cerbos | Cedar |
|---|---|---|
| Open source authorization engine | The Cerbos PDP is an Apache 2.0 authorization service with source available for independent operation. | Cedar's language, core implementations, and principal tooling are Apache 2.0. Genuine parity on licensing. |
| Evidence for Open source authorization engine | ||
| Network-addressable PDP | Ships a deployable Cerbos PDP with REST and gRPC APIs, health endpoints, SDKs, and documented service, sidecar, and DaemonSet patterns. | Provides embeddable implementations, bindings, and experimental local-agent foundations. The production service contract and topology remain an integration decision. |
| Evidence for Network-addressable PDP | ||
| In-process policy evaluation | Cerbos Hub ePDP downloads filtered policy bundles and evaluates them in-process through WebAssembly in browsers, Node.js, edge runtimes, and React Native. | Provides Rust and Go implementations, Java bindings, and WebAssembly. Cedar has broader native embedding; both support in-process WebAssembly. |
| Evidence for In-process policy evaluation | ||
| Schemas and policy validation | Validates policy structure and can enforce JSON schemas for principal and resource attributes. | Provides typed schemas and validation designed to catch policy and entity-model errors before evaluation. A Cedar strength. |
| Evidence for Schemas and policy validation | ||
| Formal policy analysis | Provides compile checks, schemas, and scenario-based policy tests, but not a symbolic equivalence or permissiveness prover. | Can compare policy sets for equivalence or permissiveness and find behaviors such as shadowed permits and impossible conditions. Cedar is stronger here. |
| Evidence for Formal policy analysis | ||
| Policy lifecycle and distribution | Cerbos Hub builds, tests, signs, and distributes policies through managed or enterprise on-premise workflows, including restricted and air-gapped deployments. | The open source engine evaluates supplied policies. Distribution, approvals, rollout, and fleet management come from the adopter or a downstream Cedar-based product. |
| Evidence for Policy lifecycle and distribution | ||
| Decision logging and audit | The Cerbos PDP can log decisions to file, local storage, Kafka, or Cerbos Hub. Cerbos Hub adds centralized collection and search. | The engine returns a decision and diagnostics. Experimental local-agent components can emit tracing and OCSF events; durable collection and search depend on the deployment. |
| Evidence for Decision logging and audit | ||
| List filtering and query planning | PlanResources returns a datastore-agnostic query plan, with reference adapters for six data layers. | Partial evaluation and level validation can reduce or bound authorization work. Applications still own safe translation into their datastore query layer. |
| Evidence for List filtering and query planning | ||
| Decision-time data | The Cerbos PDP evaluates supplied attributes. Optional Cerbos Synapse retrieves, transforms, and caches context from customer-controlled data sources. | The evaluator consumes the request, policies, and relevant entities. The application, agent, or downstream service supplies and refreshes that data. |
| Evidence for Decision-time data | ||
| Runtime and language interoperability | The Cerbos service PDP serves polyglot applications through stable APIs and official SDKs. Cerbos Hub ePDP adds in-process WebAssembly for JavaScript environments. The Cerbos service PDP partially implements AuthZEN. | Offers Rust and Go implementations, Java bindings, and WebAssembly. Strong when in-process evaluation is the intended architecture. |
| Evidence for Runtime and language interoperability | ||
Deep dive 1
The decisive difference is the product boundary
Cedar supplies embeddable authorization engines and tooling. Cerbos supplies a deployable PDP plus optional lifecycle and data infrastructure.
A Cedar evaluator receives a request, a policy set, and relevant entity data. Native implementations, bindings, WebAssembly, and experimental local-agent foundations give platform teams several ways to embed or productize that evaluator.
The open source Cerbos PDP is a network-addressable service with REST and gRPC APIs, health endpoints, official SDKs, policy tests, configurable audit, and query planning. Services can share one authorization contract without embedding a language runtime.
Commercial Cerbos Hub also supports an embedded PDP. Its JavaScript client downloads filtered policy bundles from Cerbos Hub and evaluates them in-process through WebAssembly without a per-decision call to a Cerbos service. Cerbos Hub adds managed build, test, signed distribution, and audit workflows, while commercial Cerbos Synapse adds decision-time data and integration extensions. The open source Cerbos service PDP remains independently operable without either product.
Deep dive 2
Cedar leads on formal policy analysis
Cedar can reason symbolically about whole policy sets. Cerbos focuses on executable tests, validation, audit, and rollout evidence.
Cedar's analysis tooling can compare two policy sets for equivalence or relative permissiveness and detect cases such as shadowed permits, impossible conditions, or forbids that override expected access. Its symbolic compiler and mechanically checked foundations are meaningful advantages for high-assurance policy work.
Cerbos validates policy structure and attribute schemas, compiles policies before deployment, and runs scenario-based test suites. In production, configurable decision logs and Cerbos Hub audit collection make observed behavior inspectable.
These are complementary assurance layers, not interchangeable features. Choose Cedar when proofs about policy-space behavior are mandatory. Choose Cerbos when consistent deployment, regression tests, decision evidence, and application integration are the larger operational risk.
Deep dive 3
Data and list filtering reveal the integration work
Both evaluators need relevant authorization facts. Cerbos packages a query-plan API and offers Cerbos Synapse for decision-time data.
Open source Cedar evaluates the entities and context supplied to it. Level validation and partial evaluation can help bound or defer work, but the adopter still designs entity retrieval, refresh, and datastore-query translation.
The open source Cerbos PDP likewise evaluates attributes supplied in the request. PlanResources returns an authorization-specific, datastore-agnostic query plan, and reference adapters translate supported plans for six data layers.
Optional Cerbos Synapse runs in customer-controlled infrastructure and retrieves, transforms, and caches decision-time data. It changes the platform boundary, not the Cerbos PDP licence: teams that already have reliable context assembly can use the Cerbos PDP alone.
Implementation
Map authorization intent before translating syntax
Cedar and Cerbos structure authorization differently. Start from the request contract, entity model, and expected decisions instead of converting policies line by line.
| Cedar concept | Cerbos | Migration or coexistence note |
|---|---|---|
| principal, action, resource, context | principal, actions, and resource; map context to attributes or JWT auxData by meaning | Normalize IDs and attributes at the enforcement point before comparing decisions. Use auxData only for supported JWT-backed facts. |
| permit and forbid policies | EFFECT_ALLOW and EFFECT_DENY rules | Rebuild the decision table explicitly; the combining semantics are not a mechanical text substitution. |
| entity types, attributes, and hierarchy | roles, derived roles, resource attributes, and request context | Choose the Cerbos construct by domain meaning. Keep relationships in supplied data where that is clearer. |
| Cedar schema and validation | principal and resource schemas plus compile checks | Carry required attributes and failure cases into both schema validation and policy tests. |
| partial evaluation and entity slicing | PlanResources query plan | Test generated datastore predicates separately from single-resource checks. |
| application-managed policy set | Cerbos PDP policy store or optional Cerbos Hub workspace | Choose direct self-hosted storage or Cerbos Hub-managed build and distribution based on lifecycle requirements. |
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"]Add explicit deny, missing-attribute, hierarchy, and list-filtering cases to the Cerbos test suite. Compare the resulting decisions with the Cedar evaluator before changing the enforcement path.
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 27 July 2026.
Cedar refers here to the open source language and engine ecosystem, not Amazon Verified Permissions or another downstream Cedar-based service. Compiled from public documentation in July 2026; verify current capabilities before deciding.
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
Compare the platform you need to operate, not just the evaluator
Cerbos is the stronger overall default for application authorization because the open source Cerbos service PDP, Cerbos Hub ePDP, query planning, audit, optional Cerbos Hub lifecycle, and optional Cerbos Synapse data layer form a coherent production boundary. Cedar is the stronger choice when formal policy analysis, a native Rust or Go implementation, a Java binding, operation without a Cerbos Hub dependency, or Cedar ecosystem compatibility is decisive. Prove the difference with one policy set that includes single-resource checks, list filtering, policy rollout, audit retrieval, and a decision that needs external context.