Permit.io vs Cerbos: Managed Control Plane vs Self-Hosted PDP

Permit.io and Cerbos can both run an open source policy decision point next to your application, and both are free to start. Permit.io defaults to a managed control plane with a policy editor and embeddable UI. Cerbos defaults to a self-hosted decision point that reads policy files, with a managed control plane as an option.

We build Permit.io, so this is not a neutral source. Cerbos publishes its own Cerbos vs Permit.io page, and we read it before writing this one. Its verdict is that Cerbos is the stronger overall choice, and that Permit.io is the stronger fit when its low code editor or embeddable Elements are requirements. Much of its technical description of Permit matches our documentation. Whether one is "stronger overall" depends on who edits policy and where decisions must run, so this post lays out the trade-offs. Every statement about Cerbos below comes from Cerbos's own documentation, pricing, or comparison pages, checked on 5 October 2026.

Where policy lives and who runs what

Authorization has three moving parts: the place where policy is written and versioned, the decision point that evaluates it, and the data that decisions depend on. Permit.io and Cerbos split those parts differently by default.

With Permit.io, the control plane runs in Permit's cloud. You define resources, actions, and roles in the Policy Editor, the API, Terraform, or a connected Git repository, and Permit generates policy as code for OPA (Rego) or Cedar. The decision point is either a managed Cloud PDP or an open source Edge PDP container that you run in your own network. OPAL pushes policy and data changes from the control plane to each Edge PDP, which answers checks from its local copy.

With Cerbos, the starting point is the PDP: an open source, stateless service you run as a service, sidecar, or daemonset. Policies are YAML or JSON files with CEL conditions, typically stored in Git. According to Cerbos, the PDP needs no license or account to run. Cerbos Hub is an optional control plane that adds collaborative authoring, a managed build and test pipeline, signed bundle distribution, PDP monitoring, and audit log aggregation. Cerbos Synapse is a separate commercial layer that enriches requests with context from your identity providers and databases at decision time.

Both products ship an Apache 2.0 decision point. Permit.io itself is not open source: it is built on open source components, and its control plane is a commercial service. Cerbos Hub and Synapse are commercial too. The difference is where each product starts and which parts you operate on day one.

What the same check looks like

A permission check in Permit.io names a user, an action, and a resource type, and the policy lives in the control plane:

const permitted = await permit.check("john@permit.io", "read", "document");

In Cerbos, the rule lives in a policy file in your repository, and the application sends the principal, resource, and action to the PDP:

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  resource: "document"
  version: "default"
  rules:
    - actions: ["read"]
      effect: EFFECT_ALLOW
      roles:
        - user

Neither snippet is a full integration; they show where the policy sits. In Permit.io you change it in the editor and it reaches the decision points without a deploy. In Cerbos you change a file, run the tests, and roll out the new policy through your own pipeline or Cerbos Hub.

Permit.io vs Cerbos at a glance

The table below compares the two on the dimensions that usually decide the choice. Where a cell relies on the other vendor's statement, it says so.

Sources: the Permit.io PDP docs, Cloud PDP capabilities, policy engines, deployment options, Terraform provider, GitOps, projects and environments, CI/CD, policy testing, Permit CLI, ReBAC, audit logs, logs forwarder, Permit Elements, the Permit.io pricing page and trust center; OPA (CNCF graduated), Cedar (CNCF sandbox); the Cerbos docs, conditions (CEL), API, storage, audit configuration, Cerbos Hub, Hub audit log collection, pricing, and comparison page.

Failure modes, data sync, and audit export

These three questions usually decide the shortlist after the feature table.

When the PDP or control plane is unreachable

With Permit.io, the paths differ by PDP type. An Edge PDP answers from the policy and data it already holds. Permit's trust center says a local PDP can continue evaluating cached policy during a temporary control-plane interruption, and that policy updates resume when connectivity returns. The managed Cloud PDP is hosted by Permit, so checks depend on Permit's service being available. The Edge PDP can also cache repeated decisions for a TTL (off by default); cached answers can be stale until the entry expires. Sidecar Edge PDPs send checks over loopback, which Permit docs describe as sub-millisecond and free of network latency to the PDP.

With Cerbos, the standalone PDP has no control-plane dependency for decisions: it evaluates the policies it has loaded. Cerbos Hub is optional for authoring, signed bundle distribution, and audit aggregation. If Hub is unreachable, ask Cerbos what a connected PDP does with its last loaded bundle, and how long it keeps serving that copy.

Neither product's public docs we checked define a product-level fail-open or fail-closed switch for the case where the PDP itself is unreachable. That behavior belongs to your enforcement point (the application). Ask how your integration denies, queues, or allows when the decision service does not answer.

How policy and data reach the PDP

Permit.io uses OPAL inside the Edge PDP to push policy and data updates from the control plane to each PDP, so decisions run from a local copy. In the hybrid model the control plane stays in Permit's cloud and the PDPs stay in your network (deployment options).

Cerbos loads policies through its storage drivers, including disk, Git, blob stores such as S3 or GCS, and databases. Decision-time attributes are typically passed by the caller with each request, or enriched by the commercial Synapse layer. With Cerbos Hub, Hub validates and tests policy changes, then pushes signed policy bundles to connected PDPs.

Audit logs and export

Permit.io shows decision logs in an Audit Log screen filterable by user, date, decision, and tenant, and exposes the same data through an API. For Edge PDPs deployed with the Permit Helm chart, the logs forwarder can send decision logs to stdout or Elasticsearch. For a docker run PDP, Permit docs point you to printing decisions from the container output.

Cerbos PDP audit logging is off by default and can write access and decision logs to a local store, a file, or Kafka. Cerbos Hub audit log collection streams PDP decision logs to Hub for aggregation, with local disk buffering if the network drops.

Where Permit.io is the better fit

Permit.io fits best when policy is a shared product concern, not only an engineering file. A product manager can grant a role a new permission in the Policy Editor and the change reaches every PDP without a release. Support can see why a user was denied in the Audit Log screen. Your customers' administrators can manage their own tenant through Permit Elements rather than through tickets to your team. Cerbos says it does not ship equivalent prebuilt components, and that teams who need them should plan to build them or choose Permit.

It also fits teams that want a managed control plane without giving up local decisions. In the default hybrid model, Permit runs the control plane and you run Edge PDPs in your network. With an Edge PDP, decisions are evaluated from a local copy of policy and data; Permit's trust center says sensitive data can stay in your network, and only opaque identifiers need to reach the control plane. With the managed Cloud PDP, decisions run in Permit's cloud. If your requirements tighten, the same product has a light on-premise mode, where the policy administration server runs in your network, and a full on-premise deployment for Enterprise customers.

Beyond the editor, Permit is built for a full policy SDLC. You can manage the authorization model with the official Terraform provider (permitio/permit-io on the Terraform Registry), sync generated policy into a Git repository you own through GitOps, separate projects and environments for promotion, drive changes from the API and Permit CLI, and wire CI/CD plus policy tests (including opa test on generated Rego and Permit CLI test commands) before production.

Permit.io has these constraints:

• The managed Cloud PDP evaluates RBAC and ReBAC but not ABAC, and it applies per-IP rate limits. ABAC, custom Rego, and high request rates need an Edge PDP that you operate.
• The Policy Editor generates allow rules. A rule such as "deny regardless of other policies" needs custom Rego.
• You need an account and an API key to start, which is more friction than pulling a container and a policy file.
• Nexus PDP, the newer self-hosted option for large datasets, is in early access according to Permit's docs.

Permit.io's own service holds a SOC 2 Type II attestation covering Security, Availability and Confidentiality. The latest renewal was completed in January 2026, and Sections 1 and 2 of the report are public on the trust center.

Where Cerbos is the better fit

Cerbos remains a strong choice when authorization stays inside engineering. Policy is a YAML or JSON file with CEL conditions, tests run in CI, and a change ships through the same review process as code. The PDP is a single stateless service (service, sidecar, or daemonset). Cerbos says the standalone PDP can run air-gapped and does not need a control plane to decide, and you can start with no account and add Cerbos Hub later.

It is also a fit when query planning for list endpoints is central to your workload. According to Cerbos, its query planning API with adapters can turn a policy into a database filter.

The trade-offs are real: no prebuilt end-user UI components (Cerbos's comparison page acknowledges this), policy logic lives in YAML plus embedded CEL rather than in Rego or Cedar, and decision data is not pushed the way OPAL pushes it. The caller passes the attributes a decision needs on each request, or the commercial Synapse layer fetches them at decision time. If non-engineers must edit access, or if you need a managed graph of relationships synced to the PDP, plan for extra work or prefer a product built around those cases.

Policy language: open standards versus YAML plus CEL

The language under the PDP shapes portability, hiring, and lock-in as much as the control plane does.

Permit.io generates policy as code for Open Policy Agent (OPA) in Rego, or for Cedar. OPA is a CNCF graduated project (graduated 29 January 2021). Cedar was accepted to the CNCF at Sandbox on 8 October 2025. Both are open source policy languages with their own ecosystems: editors, linters, test runners, training material, and a hiring pool that already knows the syntax. Generated Rego or Cedar can be reviewed in Git, tested with standard tools (Permit documents opa test on the policy repository), and, in principle, reused outside Permit if you later change control planes.

Cerbos policies are YAML or JSON documents with CEL conditions. That format is Cerbos-specific. CEL itself is an open expression language, but the surrounding policy schema, rule shape, and evaluation semantics are proprietary to Cerbos. Teams that invest deeply in Cerbos policy files should plan for a rewrite if they move engines later. Hiring and tooling also concentrate on one vendor's policy shape rather than on Rego or Cedar skills that transfer across the industry.

YAML is a further constraint when policies grow. YAML is designed for configuration and structured data, not for expressing branching logic. In Cerbos, complex rules become CEL expression strings embedded inside YAML fields. Those strings are harder to format, refactor, type-check, and unit-test than policy written in a language meant for logic. For small allow/deny matrices this is fine. For large, evolving authorization logic, a dedicated policy language (Rego or Cedar) is usually easier to keep correct.

ReBAC and the scale of decision data

Relationship-based access control is where the data model matters as much as the policy text.

Permit.io models ReBAC with resource instances, relationship tuples, resource roles, and role derivation. OPAL pushes policy and related data to Edge PDPs so checks can run against a local copy without the application stuffing the full graph into every request. For larger relationship-heavy datasets, Permit documents Nexus PDP (early access as of September 2026) as a self-hosted option with on-disk storage and sync that resumes after disconnection. Treat Nexus availability as time-sensitive and recheck before you buy.

Cerbos's PDP is stateless: it evaluates the policies it has loaded against the principal and resource attributes supplied on each API request. Relationship facts are not stored as a first-class graph inside the open source PDP the way Permit stores relationship tuples; if a rule needs "user owns folder," the caller (or Synapse) must provide those attributes on the check. Cerbos's public site and llms.txt also list ReBAC as a supported model; that claim is not spelled out as a relationship-tuple store in the PDP API docs we checked, so verify the exact shape against Cerbos before you assume Zanzibar-style graph semantics. Cerbos does document a default limit of 50 resources per check request (configurable), which is a batching limit, not a published ceiling on total relationships in a system.

If your product is a deep sharing graph with nested folders, groups, and derived roles, prefer a system that persists and syncs relationships to the PDP. If your checks are mostly roles plus a handful of attributes you already have in the request path, Cerbos's pass-attributes model stays simple.

Choose Permit.io or Cerbos: a short checklist

Pick Permit.io when:

• Product, support, or customer administrators must change access without a code release.
• You need embeddable user management, access requests, or approvals inside your product.
• You want a managed control plane and decisions inside your own network, with a path to full on-premise.
• You expect to mix RBAC, ABAC, and ReBAC (including relationship tuples and role derivation) in one policy, with data synced to PDPs.
• You want policy in Terraform, GitOps, environments, CI/CD, and a CLI, on top of open policy languages (Rego or Cedar).

Pick Cerbos when:

• Authorization policy is owned only by engineers and reviewed like application code.
• You want a decision point with no control plane or account at all, including in air-gapped environments.
• You prefer hand-authored YAML/CEL policy files over generated Rego or Cedar, and accept that format trade-off.
• Query planning for list endpoints is central to your workload.

Consider neither as your first choice when your main problem is a very large relationship graph with Zanzibar-style consistency controls. AuthZed, Auth0 FGA, and OpenFGA are built around that case. For a wider view of the field, see our comparison of authorization-as-a-service options.

Comparing cost across different units

Both vendors publish a free starting point, but the units differ, so a direct price comparison misleads. According to the Permit.io pricing page, the Community tier is free and lists 1,000 monthly active users (MAU) and 20 tenants. Paid plans include a Pro tier and Enterprise. The compare table lists Pro as usage-based with a published MAU quota of 50K (no dollar list price for Pro is shown on the page). Enterprise is also usage-based, contacted by quote, and lists no limits on MAU and tenants. In short, Pro and Enterprise pricing is based on MAU. According to Cerbos's pricing page, the open source PDP is free, and Cerbos Hub is priced by monthly active principals: a proof-of-concept tier at $0 for up to 100 monthly active principals, a Development tier from $25 per month, a Production tier from $933 per month that includes the first 5,000 monthly active principals, and custom Enterprise plans. A principal is a user or a service, so non-human identities count.

To compare fairly, model your own workload. Count users, tenants, and non-human identities, then include infrastructure and engineering time for every component you will run: PDPs, a control plane, and any enrichment or distribution layer.

How to test both before you commit

A short proof of concept shows more than any table. Take one production-shaped rule, such as a role that is allowed an action only for resources in the user's own tenant. Implement it in both products, deploy the decision point in the topology you intend to use, and then test failure modes: stop the control plane or policy source and see what the PDP does, push a bad policy and see how it is caught, and check that the decision log explains an allow and a deny to someone outside your team.

Frequently asked questions

What is the main difference between Permit.io and Cerbos?

Permit.io starts from a managed control plane with a policy editor and embeddable UI, and decisions run in a managed Cloud PDP or an Edge PDP in your network. Cerbos starts from a self-hosted, stateless PDP that reads policy files, with Cerbos Hub as an optional control plane. The right choice depends on who edits policy and how much of the stack you want to operate.

Are Permit.io and Cerbos open source?

Both publish an Apache 2.0 decision point: the Permit.io Edge PDP, OPAL, and cedar-agent on one side, and the Cerbos PDP on the other. Permit.io itself is not open source, and its control plane is a commercial service. Cerbos Hub and Cerbos Synapse are commercial products.

Which is cheaper, Permit.io or Cerbos?

It depends on your workload, because Permit.io's published limits use monthly active users and tenants, while Cerbos Hub uses monthly active principals. Both have a free starting point. Model users, tenants, non-human identities, and the infrastructure you will run before comparing.

Can non-developers manage policy in Cerbos?

Cerbos policies are YAML or JSON files with CEL conditions, and Cerbos Hub adds a collaborative playground for editing them. According to Cerbos, it does not ship prebuilt UI components for end users, although applications can build their own workflows on the Cerbos Hub API. Permit.io provides a low code Policy Editor and Permit Elements for this case.

Does Permit.io keep working if its control plane is unreachable?

An Edge PDP answers from the policy and data it already holds, so Permit's trust center says a local PDP can continue using cached policy during a temporary control-plane interruption. The managed Cloud PDP is hosted by Permit, so it depends on Permit's service being available. If that matters, run an Edge PDP.

Can I run Permit.io fully on-premise or air-gapped?

Yes, on an Enterprise license. Permit.io supports a full on-premise deployment, delivered as Helm charts for Kubernetes or OpenShift, and a light on-premise mode where only the policy administration server runs in your network. Cerbos can also run its PDP air-gapped, and Cerbos Hub can be self-hosted on its Enterprise plan.

How hard is it to migrate between Permit.io and Cerbos?

You can usually keep your existing enforcement points and swap the client at one boundary first. Policies do not translate line by line, because Permit generates Rego or Cedar while Cerbos uses YAML/JSON with CEL, so plan to re-express the effective rules and their tests rather than convert files. Run both side by side on one resource type before you commit.