---
title: "Repository-native policy and centrally governed policy workflows"
description: "Both products answer the same runtime question: may this principal perform this action on this resource? They emphasize different policy lifecycles, governance models, deployment topologies, enforcement patterns, and portability boundaries."
competitor: "PlainID"
canonical: "https://www.cerbos.dev/cerbos-vs-plainid"
source: "https://www.cerbos.dev/cerbos-vs-plainid"
---

# Repository-native policy and centrally governed policy workflows

Both products answer the same runtime question: may this principal perform this action on this resource? They emphasize different policy lifecycles, governance models, deployment topologies, enforcement patterns, and portability boundaries.

## Verdict

**Choose Cerbos when**

- Application authorization needs repository-native policy review, tests, and deployment without making a central commercial platform part of each decision path.
- The required enforcement model is an application-side authorization check or a query plan applied by the application data layer.
- An Apache 2.0 PDP and a documented exit path are material procurement requirements.

**Consider PlainID when**

- Inline SQL rewriting, row filtering, and column or cell masking are hard requirements.
- Nondeveloper visual authoring and packaged Authorizers outweigh repository-native ownership and PDP portability.

## Two operating models for the same decision

PlainID and Cerbos both provide fine-grained runtime authorization. PlainID centralizes policy governance in a commercial platform, supports visual, Structured Rego, and selected native authoring, offers managed and self-managed PDP deployment, and provides Authorizers for distributed enforcement and data-layer controls.

Cerbos combines an Apache 2.0 stateless Cerbos PDP with commercial Cerbos Hub and Cerbos Synapse components. The Cerbos PDP uses YAML or JSON policies with CEL conditions and supports shared-service, sidecar, DaemonSet, and selected serverless deployment. Cerbos Hub provides source-agnostic policy lifecycle, build, test, distribution, and audit aggregation. Cerbos Synapse provides decision-time enrichment, transformation, caching, and integration extensions.

**PlainID** — Particularly fits organizations that want centralized policy governance across a large application estate. PlainID supports nondeveloper visual authoring, Structured Rego and selected native formats, and documents Authorizers for API, service-mesh, data, IdP, and SaaS integrations. Its SQL Authorizers provide row filtering plus column- and cell-level filtering or masking across documented data platforms.

**Cerbos** — Fits engineering-owned, repository-based workflows while retaining centralized governance through Cerbos Hub. Policies are YAML or JSON with CEL conditions and can be compiled and tested in CI. The Apache 2.0 Cerbos PDP is self-hosted and runs independently or connects to Cerbos Hub for signed policy distribution without a per-decision Cerbos Hub round trip. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, also without a per-decision service call. Cerbos Hub is available as an enterprise on-premise deployment, including restricted and air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure.

- **Policy review and history** — Cerbos supports repository diffs, pull requests, compile checks, and CI tests, while Cerbos Hub also supports source-agnostic policy stores and a managed validation and distribution pipeline. PlainID provides platform-native audit and history, and teams can also manage Structured Rego through APIs and source control.
- **Integration scope** — Cerbos provides a local container and binary quick start. PlainID integration patterns can involve workspaces, templates, mappers, or Authorizers, while direct REST and SDK paths also exist. Test onboarding effort against one representative service.
- **Who operates it** — Cerbos is designed to fit engineering-owned workflows and can add central governance through Cerbos Hub. PlainID emphasizes centralized governance commonly led by IAM, security, or platform teams. Operating ownership remains an organizational choice for either product.

## What enterprise buyers ask for

Verified against public documentation on 24 July 2026. The links beside each row point to Cerbos or neutral standards sources; competitor sources informed the research but are not linked here.

| Requirement | Cerbos | PlainID |
| --- | --- | --- |
| Distributed enforcement with a sidecar PDP | NATIVE — Ships as a standalone binary or container and supports shared-service, sidecar, DaemonSet, and selected serverless patterns. A standalone or Cerbos Hub-connected service PDP evaluates locally without a per-decision Cerbos Hub round trip. | DISTRIBUTED OPTIONS — Offers managed Cloud PDP and self-managed PAA PDP deployments. PlainID centralizes policy governance while distributing PEP and Authorizer enforcement; topology depends on deployment. |
| Policy authoring and source of truth | GIT NATIVE — Uses YAML or JSON policies with CEL conditions. Policies can live in Git, compile and test in CI, or use Cerbos Hub's source-agnostic policy stores and managed distribution pipeline. | PLATFORM-CENTRIC — Supports visual, Structured Rego, and selected native authoring. Structured Rego is API-importable and exportable and can be versioned in Git, but depends on PlainID metadata and platform objects. |
| SDK language coverage | 8 LANGUAGES + LARAVEL — Provides gRPC and REST APIs with official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel. | MULTIPLE LIBRARIES — Documents REST APIs plus a Node.js PDP SDK and Java, .NET, and Python integration libraries. Compare maturity and use-case coverage for the required language. |
| Decision time data and connectors | VIA SYNAPSE — The Cerbos PDP evaluates request-supplied context. Commercial Cerbos Synapse can enrich decisions from SQL, identity provider, graph, and API sources through built-in or custom extensions, with in-memory or Redis caching. | BUILT IN — Can retrieve external attributes at decision time and offers configurable identity, source, and decision caching, including Redis-backed options, plus a broad Authorizer library. |
| Inline data filtering and masking | PARTIAL — PlanResources returns a query plan that reference adapters translate for the data layer. Cerbos Synapse proxy extensions can redact Cerbos API response fields. Cerbos does not provide an equivalent inline SQL interceptor. | BUILT IN — Rewrites queries to enforce row filtering and column or cell filtering and masking across documented databases and data platforms. This is a material PlainID strength. |
| Decision logging and audit | BUILT IN — When enabled, emits structured decision logs to file, Kafka, local storage, or Cerbos Hub, including decision context and matched-policy metadata. Cerbos Hub adds managed collection and search. | VERIFY — Provides Authorization and Administration Audit reports. Cloud and self-hosted configurations differ; verify retention, format, and export against compliance requirements. |
| AuthZEN compatibility | INTEROP READY — The current Cerbos PDP partially implements documented AuthZEN endpoints and has participated in published interoperability testing. Alex Olivier is one of the current AuthZEN Working Group cochairs. | INTEROP PARTICIPANT — PlainID and Cerbos both appear in published AuthZEN interoperability results. Compare the exact endpoints, specification version, and production support each vendor ships. |
| Open source and pricing transparency | APACHE 2.0 — The Cerbos PDP is Apache 2.0. Cerbos publishes Cerbos Hub pricing, including a $0 proof of concept tier; Cerbos Hub and licensed Cerbos Synapse capabilities are commercial. | COMMERCIAL — Uses a contact-led sales motion. No public self-serve pricing or documented ongoing free tier was found as of 24 July 2026; PlainID advertises a contact-led free trial. |

### Sources

- [Cerbos deployment patterns](https://docs.cerbos.dev/cerbos/latest/deployment/)
- [Cerbos Hub decision points](https://docs.cerbos.dev/cerbos-hub/decision-points.html)
- [Cerbos policy authoring](https://docs.cerbos.dev/cerbos/latest/policies/)
- [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/policy-stores.html)
- [Cerbos APIs and SDKs](https://docs.cerbos.dev/cerbos/latest/api/index.html)
- [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 Synapse extensions](https://docs.cerbos.dev/synapse/latest/extensions/index.html)
- [Cerbos audit configuration](https://docs.cerbos.dev/cerbos/latest/configuration/audit.html)
- [Cerbos Hub audit collection](https://docs.cerbos.dev/cerbos-hub/audit-log-collection.html)
- [Cerbos AuthZEN API](https://docs.cerbos.dev/cerbos/latest/api/index.html)
- [AuthZEN interoperability](https://authzen-interop.net/docs/intro/)
- [AuthZEN Working Group](https://openid.net/wg/authzen/)
- [Cerbos licence](https://github.com/cerbos/cerbos/blob/main/LICENSE)
- [Cerbos pricing](https://www.cerbos.dev/pricing)

Compiled from public vendor documentation in July 2026. Details change, so verify current capabilities with both vendors before you decide.

## The policy lifecycle starts in different places

PlainID centers policy governance in its platform. Cerbos can start in Git and add centralized controls through Cerbos Hub.

PlainID supports visual authoring, Structured Rego, selected native formats, policy history, and platform workflows. This model is a strong fit when IAM or security owns policy authoring across many applications.

Cerbos resource and principal policies are YAML or JSON with CEL conditions. Teams can review changes in pull requests and run compile checks and policy tests in CI. Cerbos Hub adds source-agnostic policy stores, managed validation, signed bundle distribution, and audit aggregation.

Cerbos Hub is not required for the Apache 2.0 Cerbos PDP to evaluate decisions. When Cerbos Hub is used, connected PDPs evaluate downloaded bundles locally rather than calling Cerbos Hub for each decision. Cerbos Hub Enterprise can run on-premise in restricted and air-gapped environments.

## Data enforcement is not a feature-for-feature match

PlainID can enforce within documented data platforms. Cerbos returns authorization results that the application or adapter applies.

PlainID SQL Authorizers document inline query rewriting for row filtering and column or cell filtering and masking. That is a material advantage when enforcement must sit inside the database access path.

Cerbos PlanResources returns a datastore-agnostic query plan. The application translates that plan through an adapter and includes the resulting predicate in its own query. This keeps query execution and transaction ownership in application code, but it requires an adapter for the selected data layer.

Cerbos Synapse proxy extensions can redact fields in Cerbos API responses. They are not an inline SQL interceptor and should not be presented as a replacement for PlainID's database enforcement.

## Decision-time data has separate runtime boundaries

Both products can use external attributes, but Cerbos separates evaluation in the Cerbos PDP from optional enrichment in Cerbos Synapse.

The standalone open source Cerbos PDP evaluates the principal, resource, and auxiliary data supplied with a request. It remains stateless and can run as a shared service, sidecar, or DaemonSet. 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.

Cerbos Synapse can retrieve and transform decision context from SQL, identity provider, graph, API, and custom sources, with configured caching. Cerbos Synapse runs in customer-controlled infrastructure and sits in the request path only where enrichment or protocol transformation is required.

PlainID documents external attribute retrieval, configurable caching, and Authorizers for multiple enforcement environments. Compare connector coverage, stale-data behavior, and failure handling against one representative attribute-heavy policy.

## Migrate one enforcement path before migrating the catalog

Treat policy translation and enforcement replacement as separate workstreams. Start with one service whose authorization outcomes and data access can be observed.

| PlainID concept | Cerbos | Notes |
| --- | --- | --- |
| Workspace, policy, and policy metadata | Policy repository or Cerbos Hub policy store | Map ownership, review, promotion, rollback, and export workflows before translating rules. |
| Subject, asset, action, and context | Principal, resource, action, and request auxiliary data | Preserve identifiers and attribute provenance so both engines receive equivalent inputs. |
| PDP or Authorizer decision | Cerbos PDP CheckResources request | Run shadow checks and compare normalized allow or deny results before changing enforcement. |
| SQL Authorizer filtering or masking | PlanResources plus a data-layer adapter | This changes the enforcement boundary. Validate query semantics, masking requirements, and transaction behavior separately. |

### A controlled data-enforcement transition

1. **Capture** — Build a corpus of representative principals, resources, actions, context, and expected data results.
2. **Translate** — Express one authorization domain as Cerbos policies and encode expected decisions as policy tests.
3. **Shadow** — Call the Cerbos PDP without enforcing its result, then compare normalized decisions and decision logs.
4. **Adapt** — For list filtering, translate PlanResources output into the selected ORM or query builder and compare returned records.
5. **Cut over** — Move enforcement only after decision parity, query semantics, latency, and failure behavior meet the acceptance criteria.

Inline SQL masking does not map directly. Keep PlainID on that path or implement and validate an explicit application-layer masking control.

## Where Cerbos is not a direct replacement

The products overlap at runtime authorization but differ in authoring, integration packaging, and data enforcement.

| Capability | Cerbos approach | Guidance |
| --- | --- | --- |
| Visual policy authoring | Cerbos policies are YAML or JSON with CEL conditions. Cerbos Hub governs policy lifecycle but does not reproduce PlainID's visual authoring model. | If nondevelopers must construct policies visually, validate author workflows before selecting Cerbos. |
| Inline database filtering and masking | PlanResources returns a query plan for an application adapter. Cerbos does not provide an equivalent inline SQL interceptor. | Retain PlainID for the data path or budget explicit adapter and masking work. |
| Packaged Authorizer breadth | Cerbos exposes REST, gRPC, SDK, proxy, and adapter integration patterns. Coverage differs by target technology. | Inventory every enforcement point and prototype the least common integration before committing to migration. |

## Openness and the cost of leaving

Cerbos policies, repository history, and tests remain under your control, and Apache 2.0 permits continued use of the Cerbos PDP. Cerbos Hub can source policies from Git, APIs, SDKs, CLI, CI/CD, or browser upload, then validate, test, sign, and distribute bundles. Migrating the Cerbos-specific policy model to another engine would still require work.

PlainID Structured Rego uses Rego v1 plus required PlainID metadata and platform-object conventions. It can be edited in the UI or managed through import and export APIs and source control. PlainID's native APIs and platform metadata may create migration work, so request contract terms, policy export samples, AuthZEN production support, and an exit test before purchase.

Both vendors have participated in published AuthZEN interoperability testing. The Cerbos PDP partially implements documented AuthZEN endpoints, and Alex Olivier of Cerbos is one of the current AuthZEN Working Group cochairs. Compare supported endpoint sets and specification versions in a representative integration.

## Use Cerbos as the default application-authorization path

Cerbos is the stronger overall choice when application teams need an open PDP, policy as code, local decisions, managed distribution, and application-controlled query filtering. Prove that model with one policy change containing an attribute condition and a filtered list. Implement it as Cerbos policy and tests, distribute it through Git or Cerbos Hub, run shadow decisions, and apply a PlanResources result to the real data layer. Keep PlainID only where its inline data enforcement or visual authoring is a verified requirement.

## Questions you are probably asking

### PlainID supports policy as code too. Is that not the same thing?

PlainID supports code and visual workflows around a centrally governed policy catalog. Its Structured Rego uses PlainID metadata and platform objects, while Cerbos is repository-native and Cerbos Hub also supports centrally governed, source-agnostic stores. Ask each vendor to demonstrate a policy change, review, failing test, promotion, export, and rollback.

### We need row and column level data filtering. Does Cerbos match PlainID there?

PlainID documents inline SQL rewriting, row filtering, and column or cell filtering and masking across several data platforms; verify database-specific limitations. Cerbos PlanResources returns a query plan that the application applies through an adapter, while Cerbos Synapse extensions can redact Cerbos API response fields. If inline database masking is required, PlainID has the stronger documented mechanism. If filtering should remain in the application data path, Cerbos provides that model.

### PlainID is recognized by analysts. Is Cerbos enterprise ready?

PlainID is listed in current Gartner and KuppingerCole research across authorization and adjacent identity, data, and API categories. Cerbos documents self-hosted production patterns, while Cerbos Hub adds managed policy build, test, distribution, and audit aggregation across Git, API, SDK, CLI, CI/CD, and browser-upload workflows. The open source Cerbos PDP and published Cerbos Hub tiers can be evaluated self-serve; scope a proof of concept around one real service.

### Our business users need to author policy without engineers. Does that rule out Cerbos?

If nondevelopers author policy in a central console, PlainID may be a strong fit. Cerbos policies use human-readable YAML or JSON with CEL conditions, but the default workflow is code-first and should be tested with the intended authors. Cerbos Hub adds centralized governance without requiring Git as the only source.

### Can we integrate Cerbos with our identity stack the way PlainID integrates with IdPs?

With JWKS or keysets configured, the Cerbos PDP can verify and consume JWT claims from an IdP; applications and gateways should still perform authoritative token validation. Cerbos Synapse can query identity provider or directory APIs through configured or custom extensions and cache results. Validate the exact provider, connector implementation, and failure behavior.

## The short version

**Cerbos strengths**

- Combines an Apache 2.0 Cerbos PDP with Cerbos Hub policy lifecycle management and Cerbos Synapse enrichment and integration capabilities
- Uses YAML or JSON policies with CEL conditions across repository-native and source-agnostic Cerbos Hub workflows
- Supports standalone, shared-service, sidecar, DaemonSet, and selected serverless PDP deployment patterns
- Provides gRPC and REST APIs with official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel
- Can record allow or deny decisions and matched-policy metadata when logging is enabled
- Partially implements documented AuthZEN endpoints and has participated in published interoperability testing

**Weigh with PlainID**

- Inline SQL rewriting with row filtering and column or cell filtering and masking is a material PlainID strength
- A broad library of prebuilt Authorizers may reduce integration work; validate the required technology and version
- The visual wizard suits organizations where nondevelopers author policy
- Current analyst recognition across authorization and adjacent identity, data, and API categories
- Deployments can involve workspaces, templates, mappers, and Authorizers depending on the integration pattern
- Portability requires validation because Structured Rego depends on PlainID metadata and platform objects, although APIs and source-control workflows are supported

Send us one of your real authorization scenarios, however messy. We will model it in Cerbos policies and run it with you.