--- title: "Two developer-focused products, two default operating models" description: "Both products target application teams. In its standard hosted model, Permit.io pairs a managed control plane with an open source PDP. Cerbos can run a self-hosted Cerbos PDP from hand-authored policy files with no control plane required for decisions, while Cerbos Hub and Cerbos Synapse add commercial management and enrichment capabilities." competitor: "Permit.io" canonical: "https://www.cerbos.dev/cerbos-vs-permit" source: "https://www.cerbos.dev/cerbos-vs-permit" --- # Two developer-focused products, two default operating models Both products target application teams. In its standard hosted model, Permit.io pairs a managed control plane with an open source PDP. Cerbos can run a self-hosted Cerbos PDP from hand-authored policy files with no control plane required for decisions, while Cerbos Hub and Cerbos Synapse add commercial management and enrichment capabilities. ## Verdict **Choose Cerbos when** - The default should be a modular authorization platform: an independently deployable open source PDP, optional Cerbos Hub policy lifecycle, and commercial Cerbos Synapse enrichment. - The application team wants YAML or JSON policy with CEL rather than generated Rego or Cedar. - Policy lifecycle management and decision-time data enrichment should remain separate, optional platform concerns. **Consider Permit.io when** - A low code policy editor is the preferred authoring surface for developers and nondeveloper stakeholders. - Embeddable access request, approval, and user management components are product requirements. - OPAL-based policy and data distribution matches the operating model the team wants. ## Where authorization lives Both products provide developer tooling and SDKs, publish open source PDPs under Apache 2.0, support RBAC and ABAC, participated successfully in the OpenID AuthZEN interoperability testing published in May 2024, and publish pricing with a free tier. Both also sell proprietary management capabilities, although their component boundaries and licences differ. Their defaults differ. Permit policy can be configured through its cloud UI, API, SDK, or IaC; UI changes generate Rego or Cedar in a Git repository the customer can own and extend, and OPAL distributes updates. The self-hosted Cerbos PDP can evaluate hand-authored YAML or JSON policies with CEL expressions from local or Git-backed storage without a control plane. Cerbos Hub adds source-agnostic policy ingestion, testing, signed bundle distribution, fleet monitoring, and audit; Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure and adds decision-time context enrichment. **Permit.io** — Permit provides a low code policy editor intended for developers and nondeveloper stakeholders. Permit Elements adds embeddable access request, approval, and user management components; as of 24 July 2026, Cerbos's public product documentation does not list an equivalent. OPAL is an Apache 2.0 engine for real time policy and data distribution. The Community plan is free for up to 1,000 MAU and 20 tenants as of the same date. **Cerbos** — Cerbos fits teams that want directly authored authorization policy and control over the decision path. The self-hosted Cerbos PDP runs as one binary or container and does not require a cloud control plane for local decisions. Cerbos Hub adds managed policy lifecycle and observability without requiring generated Rego or Cedar; Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure and adds licensed decision-time enrichment from existing systems. - **Source of truth** — With a standalone file- or Git-backed Cerbos PDP, hand-authored policy is the source artifact. Cerbos Hub-backed deployments validate and distribute versioned bundles. Permit supports cloud UI, API, SDK, IaC, direct code, and customer-owned Git workflows. - **What you deploy** — The standalone Cerbos PDP can run as one binary or container reading local policy files. 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. Permit offers a managed Cloud PDP or an Edge PDP container; the Edge container bundles a policy engine, OPAL client, and API server and normally syncs from its configured control plane. - **When you outgrow the UI** — Cerbos policies are authored directly in YAML or JSON with CEL expressions, so users do not maintain generated Rego or Cedar. Permit supports custom Rego or Cedar alongside generated code, plus API, SDK, IaC, and CLI workflows. ## What developer teams ask for Reviewed against current Cerbos, neutral standards, and first-party competitor documentation on 24 July 2026. Several capabilities overlap, but their defaults and component boundaries differ. | Requirement | Cerbos | Permit.io | | --- | --- | --- | | Source of truth for policy | GIT NATIVE — Treats hand authored files in your repository as the authoritative artifact, reviewed and tested like any other code. | MULTIPLE PATHS — Supports cloud UI, API, SDK, IaC, direct code, and customer-owned Git workflows. UI changes generate Rego or Cedar. | | Policy language | NATIVE — Authors policy directly in YAML or JSON with CEL expressions, without requiring users to maintain generated Rego or Cedar. | GENERATED — Generates Rego or Cedar beneath the low code editor and also supports direct custom policy code. | | Self hosting and cloud dependency | NATIVE — The standalone Cerbos PDP needs no control plane for authoring or decisions. It can run air-gapped with local storage and telemetry disabled; enterprise Cerbos Hub also has an on-premise option. | SUPPORTED — Supports local Edge PDPs with a cloud control plane. The Enterprise plan also offers the complete control plane on-premise as a multiservice platform. | | Embeddable end user access UI | VIA CERBOS HUB API — No prebuilt UI components. Applications build access request and user management workflows on Cerbos Hub policy stores, updating policies programmatically through the Cerbos Hub API and SDKs for Go, JavaScript, Python, Java, .NET, PHP, and Rust — documented for per-tenant roles and user-defined permissions. | BUILT IN — Ships Permit Elements, embeddable components for access requests, approvals, and user management. A genuine differentiator. | | Keeping decision data fresh | VIA SYNAPSE — Licensed Cerbos Synapse supports decision-time enrichment from SQL and extension-defined HTTP, IdP, or graph sources, with in-memory or Redis caching. | BUILT IN — Distributes policy and external data to deployed policy agents in real time through Apache 2.0 OPAL. | | List filtering and query planning | BUILT IN — Exposes PlanResources plus six documented query-plan adapters for applying filters in the application datastore. | BUILT IN — Supports object filtering, OPA partial evaluation, and a Prisma extension. Evaluate policy-model and adapter coverage for your stack. | | AuthZEN compatibility | INTEROP READY — The Cerbos PDP partially implements the AuthZEN API, and Cerbos Synapse exposes the Cerbos API in front of an embedded or external Cerbos PDP. Alex Olivier, Cerbos cofounder and CPO, is one of the current AuthZEN Working Group cochairs. | INTEROP READY — Participated successfully alongside Cerbos in the OpenID AuthZEN interoperability testing published in May 2024. | | Open source and pricing transparency | APACHE 2.0 — Publishes the Cerbos PDP under Apache 2.0 with public pricing and a free tier. Cerbos Hub and Cerbos Synapse are commercial add-ons. | APACHE 2.0 — Publishes the PDP and OPAL under Apache 2.0 and SDKs under Apache 2.0 or MIT, depending on the SDK. The hosted control plane is proprietary. | ### Sources - [Cerbos policy storage](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html) - [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/policy-stores.html) - [Cerbos policy authoring](https://docs.cerbos.dev/cerbos/latest/policies/authoring_tips.html) - [Cerbos configuration](https://docs.cerbos.dev/cerbos/latest/configuration/index.html) - [Cerbos Hub on-premise](https://docs.cerbos.dev/cerbos-hub/on-premise) - [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/latest/policy-stores) - [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/) - [Cerbos Synapse data sources](https://docs.cerbos.dev/synapse/latest/extensions/data-sources.html) - [Cerbos query-plan adapters](https://docs.cerbos.dev/cerbos/latest/recipes/query-plan-adapters/index.html) - [Cerbos AuthZEN API](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [AuthZEN interoperability results](https://openid.net/authorization-interop-results/) - [AuthZEN Working Group](https://openid.net/wg/authzen/) - [Cerbos pricing](https://www.cerbos.dev/pricing) The links beside each row point to Cerbos or neutral standards sources. Evaluative conclusions are Cerbos's interpretation; verify current capabilities before deciding. ## Ownership starts with the source artifact Both products support code and Git workflows, but their default authoring paths produce different operational ownership. Permit supports a cloud UI, API, SDK, IaC, direct code, and customer-owned Git. Changes made through its UI generate Rego or Cedar. That model is useful when policy editors must serve a mixed technical and nontechnical audience. A standalone Cerbos PDP reads policies authored directly in YAML or JSON with CEL. The repository can remain the authoritative artifact, with review and tests following the application's existing delivery workflow. Cerbos Hub is optional for the decision path. It adds ingestion, validation, testing, signed bundle distribution, fleet visibility, and audit. Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. ## The control plane and the decision path are separate choices The products can both place a PDP near the application, but the surrounding dependencies differ. Permit offers managed Cloud PDPs and Edge PDP containers. The Edge PDP normally receives policy and data updates through the configured Permit control plane and OPAL. The standalone open source Cerbos PDP can evaluate from local or Git-backed policy storage without contacting Cerbos Hub. A sidecar or service deployment keeps the synchronous request inside the application's infrastructure. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, with no per-decision service call. Permit also offers an enterprise on-premise control plane. The decision is therefore not simply cloud versus self-hosted. Compare the number of components, policy distribution path, failure behavior, and which team operates each component. ## Data distribution and decision-time enrichment solve different problems OPAL distributes data to policy agents; Cerbos Synapse retrieves context when a decision is evaluated. OPAL is an Apache 2.0 distribution engine for policy and external data. It fits systems that want policy agents to receive updates before a check is made. Commercial Cerbos Synapse runs in customer-controlled infrastructure. It can retrieve and transform identity, resource, or relationship context at decision time, with configured caching, before an embedded or external Cerbos PDP evaluates policy. Neither mechanism removes data-lifecycle design. Teams still need to define authoritative sources, acceptable staleness, cache behavior, and failure handling. ## Map the operating model before moving policy A migration can preserve existing application enforcement points while changing authoring, distribution, and context retrieval independently. | Permit.io concept | Cerbos | Notes | | --- | --- | --- | | Policy editor and generated Rego or Cedar | Directly authored YAML or JSON policies with CEL conditions | Translate the effective rules and tests, not the generated source line by line. | | Cloud PDP or Edge PDP | Self-hosted Cerbos PDP as a sidecar, DaemonSet, or service | Keep the existing PEP and replace its authorization client at one boundary first. | | Permit control plane and OPAL updates | Local or Git policy storage, or optional Cerbos Hub bundle distribution | Select the policy path independently from the runtime decision topology. | | Distributed external authorization data | Request attributes supplied by the application or fetched through Cerbos Synapse | Choose per datum whether the caller or customer-controlled Cerbos Synapse owns freshness. | ### A local decision path with optional management 1. **1. Author** — Engineers edit Cerbos policy and tests directly in the source repository. 2. **2. Distribute** — The Cerbos PDP reads local or Git-backed policy, or receives a signed bundle from Cerbos Hub. 3. **3. Check** — The application sends principal, action, resource, and current attributes to its local Cerbos PDP. 4. **4. Enforce** — The application applies the allow or deny response without a hosted control-plane call. Cerbos Hub can manage the lifecycle without becoming a mandatory synchronous dependency. Cerbos Synapse is added only when decision-time enrichment is required. ## Where Cerbos is not a drop-in substitute These differences can determine the decision before policy syntax or deployment cost is compared. | Capability | Cerbos approach | Guidance | | --- | --- | --- | | Embeddable access workflows | No prebuilt UI components. Applications build access request and user management workflows on Cerbos Hub policy stores, updating policies programmatically through the Cerbos Hub API and SDKs. | Choose Permit Elements when those interfaces are a core product requirement, or plan to build and maintain them separately. | | Low code authoring for nondevelopers | Cerbos policy is directly authored as YAML or JSON with CEL; Cerbos Hub adds lifecycle tooling but does not replace Permit's low code editor. | Validate the authoring workflow with the people who will change policy, not only the engineers integrating the Cerbos PDP. | | Push-based external data distribution | The Cerbos PDP evaluates supplied attributes, while Cerbos Synapse retrieves context at decision time. Cerbos does not reproduce OPAL's distribution model. | Keep Permit or OPAL where pushed local data replicas are required, or redesign the source and freshness contract before migrating. | ## Where policy lives decides the rest The default authoring workflow remains a major difference, but it is not the only one. Teams should also compare policy and relationship models, embeddable UI, filtering coverage, deployment mode, commercial boundaries, and operational footprint. Permit's standard model centers its control plane, low code editor, Elements, and OPAL distribution. The standalone Cerbos model centers directly authored policy and an independently operated decision path. Cerbos extends that starting point without collapsing the boundary between policy and application data. Cerbos Hub manages ingestion, validation, testing, signed distribution, fleet visibility, and audit. Cerbos Synapse retrieves external context at decision time. The Cerbos PDP continues to evaluate locally, and teams do not have to inspect or maintain generated Rego or Cedar. Air-gapped operation is available with local storage and telemetry disabled, and enterprise Cerbos Hub can run on-premise. Permit fits when nondeveloper policy authoring and embeddable access workflows are central requirements. Cerbos fits when directly authored policy, a local decision path, independent deployment, and source-controlled lifecycle management matter more. ## Cerbos is the stronger application-authorization platform For teams choosing an application-authorization platform, Cerbos is the stronger overall choice because the open source Cerbos PDP, optional Cerbos Hub policy lifecycle, and commercial Cerbos Synapse enrichment form a modular stack with direct policy authoring and deployment control. Permit remains the stronger fit when its low code editor or embeddable Elements are requirements. Verify the choice with one production-shaped rule, the intended PDP topology, policy-update failure tests, and decision logs. ## Questions you are probably asking ### Is Permit not open source too? Yes. Permit's PDP and OPAL are Apache 2.0, while its SDKs use Apache 2.0 or MIT depending on the repository. The hosted control plane is proprietary. Cerbos PDP is Apache 2.0; Cerbos Hub and Cerbos Synapse are commercial products. Compare which components are required for authoring, distribution, enrichment, and each decision path. ### Permit has a no code UI for our product and ops teams. What does Cerbos offer them? Permit has the clearer fit when prebuilt nondeveloper policy authoring and end user access workflows are hard requirements. Cerbos policies are directly authored YAML or JSON with CEL, and Cerbos Hub adds collaborative playgrounds plus managed validation and distribution. Applications can also build their own access workflows on Cerbos Hub policy stores, updating policies programmatically through the Cerbos Hub API and SDKs, though Cerbos does not ship an equivalent to Permit Elements. ### How do the data models compare, OPAL sync versus Cerbos Synapse fetch? OPAL distributes policy and data changes to deployed policy agents. Licensed Cerbos Synapse retrieves and transforms context at decision time from SQL or extension-defined HTTP, IdP, and graph sources, with configurable caching. Neither model wins universally. Compare freshness requirements, source of truth design, extension work, operational cost, and the Apache 2.0 versus commercial boundary. ### Which is cheaper to adopt? Both publish pricing and free tiers. A workload-specific model should include licence units, plan limits, required components, infrastructure, and operating labour. For Permit, include the selected Cloud or Edge PDP and control-plane deployment. For Cerbos, include the standalone Cerbos PDP and any Cerbos Hub or Cerbos Synapse capabilities required. ## The short version **Cerbos strengths** - Supports a standalone, file-backed Cerbos PDP with no control plane required for authoring or decisions - Deploys the standalone Cerbos PDP as one binary or container and keeps synchronous decisions local - Can run air-gapped with local policy storage and telemetry disabled - Authors policy directly in YAML or JSON with CEL, without generated Rego or Cedar to maintain - Adds policy lifecycle management through Cerbos Hub and decision-time enrichment through Cerbos Synapse - Participated in AuthZEN interop; Alex Olivier is one of the current Working Group cochairs - Publishes public pricing with a free tier and an Apache 2.0 Cerbos PDP **Weigh with Permit.io** - Permit Elements provides embeddable access request and approval UI that Cerbos does not - The no code editor serves mixed developer and nondeveloper teams - OPAL provides Apache 2.0 real time policy and data distribution - Permit supports ReBAC and offers OPA/Rego and Cedar engine options; verify model-specific parity - The Community plan publishes measurable free limits - Permit also supports direct code, API, SDK, IaC, customer-owned Git, and enterprise on-premise workflows Send us one of your real authorization scenarios, however messy. We will model it in Cerbos policies and run it with you.