Cerbos vs OpenFGA

If you are comparing Cerbos with OpenFGA, you are probably in one of two places. You are choosing a fine-grained authorization layer and OpenFGA is on the list because it is open source, backed by Okta and modeled on Zanzibar, the system Google built to manage permissions across its products. Or you already run OpenFGA, or Auth0 FGA, its managed version, and you are finding out how much of the work happens outside the engine.

Both solutions can answer whether a person can view a document because they belong to a team that has access to the folder it sits in. They differ in where the facts behind that answer live.

OpenFGA keeps its own copy of your relationship data as tuples, one record per relationship such as "anne is a viewer of folder product", and follows those records to an answer.

Cerbos evaluates your policies against the data where it already lives, in your application, your database or your identity provider.

That difference decides how much of your engineering time goes into keeping two systems in agreement, how naturally a rule can mix relationships with amounts, regions and status, and what your security team can show an auditor afterwards.

Cerbos vs OpenFGA at a glance

OpenFGA and Auth0 FGA share an API, but they are different things to run and to buy, so they get separate columns.

Question	Cerbos	OpenFGA (self-hosted)	Auth0 FGA (managed)
What it is	An authorization management platform. Decision points run next to every workload, Cerbos Hub manages policy, testing and audit, and Cerbos Synapse brings in context and connects gateways, data platforms and AI agents.	An open source ReBAC engine (relationship-based access control) inspired by Zanzibar, a CNCF Incubating project since October 2025.	Okta's hosted service built on OpenFGA, with the same API.
Where the data behind a decision lives	Where it already is. The application sends attributes, or Cerbos Synapse fetches them at decision time. Cerbos keeps no copy.	In OpenFGA's own store (Postgres, MySQL or SQLite) as relationship tuples you write and keep in sync with your database.	In Okta's hosted store, kept in sync the same way. Okta's sync feature is labeled Beta (October 2026).
Relationships and attributes	Both in one policy. Derived roles express owner, member and manager, and conditions in CEL (Google's Common Expression Language) handle amount, region, status and time in the same rule.	Relationships are the model. Attribute rules are added as CEL conditions on tuples and as contextual tuples, facts sent with each request, capped at 100 per request (OpenFGA docs, October 2026).	Same as OpenFGA.
Listing what a user can see	A query plan returns a filter your database runs, so results are complete and paginated by the database.	ListObjects returns up to 1,000 results within 3 seconds by default, both configurable, and flags a partial list in a response header.	Up to 10,000 results since April 2026.
Decision logs	Every decision logged with its inputs, outcome and the policy version behind it, collected in Cerbos Hub, kept up to a year or longer.	No decision audit log. Okta's comparison page says self-hosted teams build their own logging.	A Logging API with 7 days of retention (October 2026).
Coverage	Applications, API gateways and service meshes (Envoy, Istio, Kong, Apigee), Trino, Kafka, Kubernetes, MCP servers and AI agents, from one set of policies.	Applications through its API. Its docs suggest pairing it with OPA for Kubernetes admission and service mesh rules.	Applications, plus Okta's AI agent products.
Standards	Cerbos PDP implements the AuthZEN Authorization API. Alex Olivier, Cerbos cofounder and CPO, co-chairs the OpenID AuthZEN Working Group.	AuthZEN endpoints are experimental, behind a flag, since March 2026.	Not documented.
Pricing	Public. $0 proof of concept, Development from $25 a month, Production from $933 a month, Enterprise custom.	No license fee. You run the servers, the database and the sync.	Not published. Production needs an Enterprise contract.

Where your authorization data lives with Cerbos and OpenFGA

Every fact a decision depends on, who owns a document, which team a person is on, which folder holds which file, has to be somewhere the decision point can read it.

OpenFGA's answer is its own store. Your application writes a tuple, such as "anne is a viewer of folder product", every time the matching fact changes in your database. No transaction spans the two, so a crash or a failed write between them leaves them disagreeing, and a delete in your database does not cascade into OpenFGA. OpenFGA's own documentation says keeping that data in sync "can be challenging" (October 2026), and Okta's blog on ReBAC names the dual write problem, writing the same fact to two systems with nothing to keep them in step. Teams that ran into it describe the same thing. Rover's engineers needed a tuple write for every database write, built their own cascade for deletes, and judged change data capture "too much for us to handle". The Hacker News discussion of their write-up runs through the same problem for every Zanzibar-style system.

That work does not stop at launch. Every new feature that touches a permission adds another write path to keep correct, and every migration of your own schema has a second store to migrate with it. For the security team, a tuple that drifted from the database is access nobody meant to grant, or a revocation that never took effect.

Cerbos keeps no copy. Cerbos PDP is a stateless decision point that holds policy and nothing else. Your application sends the person, the resource and the action with the attributes the policy needs, usually from rows it has already loaded. When an attribute lives somewhere the application does not read, Cerbos Synapse fetches it at decision time from the database, directory or identity provider that owns it, as we show in looking up identity attributes at decision time. A change in your database applies on the next request that reads it, because there is nothing to sync.

OpenFGA's own guidance puts the trade-off the other way, recommending a ReBAC engine when the data is too large or too dynamic to send with every request (October 2026). The facts still have to reach the check in Cerbos too. The difference is that they come from your source of truth on each request, so there is nothing to drift. Folder chains are resolved by Cerbos Synapse from wherever the folder tree lives, and anything else the application does not load comes through Synapse too.

For an identity team, that changes how joiners, movers and leavers reach authorization. Cerbos Synapse reads groups and attributes from your identity provider, such as Okta or Entra ID, at decision time, so a change in the directory applies on the next request instead of waiting for someone to update or delete tuples.

How Cerbos and OpenFGA express relationships and attribute rules

Real permission rules mix both kinds of fact. A person can see a document because of the folder it sits in, but only if the document is not restricted, or only in their own region, or only below an amount.

In OpenFGA, relationships are the model. You define types and relations, and the engine follows them through the tuples you wrote. Here a document inherits viewers from its folder.

model
 schema 1.1
type user
type folder
 relations
   define viewer: [user]
type document
 relations
   define parent: [folder]
   define viewer: [user] or viewer from parent

Attribute rules are an addition to that model. OpenFGA describes support for "some ABAC scenarios" through CEL conditions attached to tuples and contextual tuples sent with each request, with published caps on condition cost and on contextual tuples per request (October 2026). That context is a second mechanism next to the tuples, with its own caps. In Cerbos, attributes on the request are the only mechanism, so a relationship and a region check arrive in the same request and sit in the same rule.

In Cerbos, relationships and attributes sit in the same rule. The same inheritance, plus a classification check, is one condition. Cerbos Synapse queries the folder tree and sends the folders the person can view, and the policy checks the document’s folder against them.

apiVersion: api.cerbos.dev/v1
resourcePolicy:
 resource: document
 version: default
 rules:
   - actions: ["view"]
     effect: EFFECT_ALLOW
     roles: ["user"]
     condition:
       match:
         all:
           of:
             - expr: R.attr.folder in P.attr.viewerFolders
             - expr: R.attr.classification != "restricted" || P.attr.clearance == "restricted"

Ownership, team membership and manager chains become derived roles, granted when a condition comparing the person and the resource is true. Organization and tenant hierarchies use the CEL hierarchy functions. Nested folders of any depth stay in your database or a graph database, and Cerbos Synapse queries that tree before the check and returns the answer as an attribute, here the folders a person can view. CEL does not recurse, and passing the whole tree into every request gets messy, so the policy only receives the result. Our post on hierarchy-based permissions covers related patterns.

Both products use CEL for conditions, so OpenFGA conditions carry across almost as written. Policies are YAML that a security reviewer can read in a pull request, and the same file holds the relationship and the attribute logic.

Listing what a user can access in Cerbos and OpenFGA

Search results, dashboards and AI retrieval all need the list of everything a person can see, not one yes or no.

OpenFGA answers with ListObjects, which follows the stored relationships and returns object IDs. By default it returns up to 1,000 results and stops after 3 seconds, both configurable, and since April 2026 a response header tells the client when the list is partial. Auth0 FGA raised its cap to 10,000 the same month. Your application then fetches those IDs from your database and applies its own sorting and paging.

Cerbos returns the rule instead of the list. A query plan turns the policy into a filter, and an adapter adds it to the query your application already runs, so the database returns the rows the person may see, sorted and paginated as usual, with no result cap because the database does the listing. Documented adapters cover Prisma, Drizzle, Mongoose, Convex, SQLAlchemy and LangChain with ChromaDB for retrieval, and translate conditions on columns such as owner, tenant and folder path, and on related tables.

Every user who can see one document, the question behind a sharing dialog, stays a query on your shares and members tables.

Policy changes, testing and rollback in Cerbos and OpenFGA

OpenFGA models are immutable. Each change creates a new model ID, and your application points at the version it should use. Model tests in .fga.yaml files run fast in CI. Self-hosted OpenFGA has no management console, according to Okta's comparison page (October 2026).

Cerbos policies live in Git or in Cerbos Hub policy stores, with test suites next to them. Cerbos Hub runs the suites on every change, only builds a deployment when they pass, shows which build every decision point runs, and rolls back to an earlier build in one step. The Cerbos Hub playground shows a permissions matrix and a trace of every rule a decision went through, so product, identity and security people can check a change before it is proposed. Scoped policies let a tenant or business unit narrow what the organization allows without a separate store per tenant.

Audit evidence in Cerbos and OpenFGA

When an auditor or an incident review asks why someone could open a record in March, the answer has to be "here is the decision and the policy that made it", not a reconstruction.

Self-hosted OpenFGA has no decision audit log. Its change log records tuple writes, and Okta's comparison page says teams running it build and operate their own logging (October 2026). Auth0 FGA adds a Logging API with 7 days of retention.

Cerbos logs every decision with its inputs and outcome, linked to the policy version that made it. Cerbos Hub collects those logs from every decision point into one searchable trail, and you can export them to your own archive or SIEM. Retention runs from a week on the proof of concept tier to a year on Production and as long as you need on Enterprise. With the Git history of every policy change alongside, the access decision evidence auditors ask for under SOC 2, ISO 27001, HIPAA, PCI DSS or DORA comes from a search, not a reconstruction. Cerbos itself holds a SOC 2 Type II attestation.

Where Cerbos and OpenFGA run decisions

Self-hosted OpenFGA runs as a service in front of its database, or as a library inside a Go service. You size and tune both, and keep the database highly available, because every check reads it. Auth0 FGA moves that to Okta, which means each check is a call to Okta's regional API, and Okta documents that results can take a few seconds to converge after a write (October 2026).

Cerbos decision points run wherever the workload does, as a sidecar, a shared service, a DaemonSet, a serverless function or in the browser and at the edge. They hold only policy, so a check never leaves your network and they scale by adding instances. If Cerbos Hub is unreachable, running decision points keep serving the last policy they received, and new ones start from the last built copy. Cerbos Hub runs hosted, or on-premise and air-gapped for enterprise customers.

Authorization beyond the application with Cerbos and OpenFGA

The same rule has to hold wherever the data can be reached, in the application, at the API in front of it, in the analytics platform behind it and in the agent working on someone's behalf.

OpenFGA covers applications that call its API. Its documentation suggests pairing it with a second policy engine, OPA, for Kubernetes admission and service mesh rules, so a team ends up with two languages and two places to audit.

Cerbos covers each of these from one set of policies and one audit trail.

• API gateways and service meshes use Cerbos at Kong and Apigee, and Cerbos Synapse as the external authorization service for Envoy and Istio.
• Data platforms and event streams get Cerbos answering Trino's authorization calls, so a query returns only the rows and columns a person may see, and Kafka's, so only approved services read or write a topic.
• Kubernetes admission follows the same policy language.
• AI agents have every tool call checked before it runs, down to the arguments, through agent hooks such as Claude Code's, at an MCP gateway or in the MCP server. The agent's token and the person's token travel in the same request, so a policy can require both.

Okta sells AI agent authorization too, through Auth0 for AI Agents, which uses Auth0 FGA for retrieval filtering. In Cerbos, the policy that governs an agent's tool call is the same one that governs the person's API call and their Trino query, recorded in the same audit trail, so a security team can approve an agent rollout with controls it can show an auditor.

AuthZEN, portability and lock-in with Cerbos and OpenFGA

Both have an Apache 2.0 engine. OpenFGA is a CNCF project, and Cerbos PDP is the engine inside the Cerbos platform.

What you carry if you ever change decision service is the policy and the request format. Cerbos policies only run on Cerbos, but they hold no data, so leaving means rewriting readable rules. Leaving OpenFGA means rewriting the model and also exporting and transforming the second copy of your data held in its tuples.

AuthZEN, the OpenID Foundation's Authorization API, standardizes how an application or gateway asks for a decision. Cerbos PDP implements it, and Cerbos appears in the published interoperability results. OpenFGA added AuthZEN endpoints behind an experimental flag in March 2026, and OpenFGA's docs say its full model cannot be used through the AuthZEN endpoints alone. Alex Olivier, our cofounder and CPO, co-chairs the AuthZEN Working Group, so read our view on it with that in mind.

Cerbos and Auth0 FGA pricing

Cerbos publishes its pricing, based on monthly active principals, the people and services that get an authorization decision in a month.

• Proof of concept. $0, with a week of audit logs.
• Development. From $25 a month, with three months of audit logs.
• Production. From $933 a month, with unlimited workspaces, decision points and tenants, and a year of audit logs.
• Enterprise. Custom, adding SSO, self-hosted Cerbos Hub, custom retention and phone support.

Self-hosted OpenFGA has no license fee. The cost is the database, the servers, the sync pipeline, the logging you build and the engineers who run all of it. Auth0 FGA does not publish a price and is not on Auth0's pricing page. Its documentation says it is billed by the distinct users sent to Check and ListObjects each month, per store, and production use needs an Enterprise contract (October 2026).

Cerbos at enterprise scale

The Cerbos platform runs more than 2 billion authorization checks a month, and Utility Warehouse uses it across 4,500 services and millions of non-human identities. Alex Olivier, our cofounder and CPO, co-chairs the OpenID AuthZEN Working Group, which wrote the standard API for asking an authorization decision point for an answer.

Analysts track the category too. Cerbos is recognized in the AuthZEN category of the Gartner® Hype Cycle™ for Digital Identity, 2026, and is included in multiple KuppingerCole Leadership Compass reports, including ones on policy based access management, API security and management and generative AI defense, and more.

Google ran Zanzibar at Google’s scale. OpenFGA is a separate implementation with its own database and limits, so the scale that matters is the one you measure on your own data.

When OpenFGA may still fit

Most application models are one or two hops plus attributes, which Cerbos handles in a condition. If your product's core permission question is reachability through a very large sharing graph, many hops across millions of edges, test that part with your real data first, and move the rest of authorization to Cerbos.

Moving from OpenFGA to Cerbos

Most of the move is deciding where each tuple's fact comes from afterwards. Usually it is a column your database already has, and sometimes a lookup Cerbos Synapse makes at decision time. Relations become derived roles, OpenFGA conditions carry across as CEL, Check becomes a Cerbos check and ListObjects becomes a query plan. Teams translate one resource type at a time, run Cerbos beside OpenFGA on the same requests until every decision matches, then cut over. Our migration guide walks through a full translation with passing tests.

Choosing between Cerbos and OpenFGA

For most teams building fine-grained authorization into applications, APIs and AI agents, Cerbos is the stronger choice. Policies are evaluated against your data where it already lives, so there is no second store to keep in sync, and every decision leaves a record with the policy that made it.

As Rob Crowe, Principal Engineer at Utility Warehouse, put it, “Cerbos audit logs changed how we do security. We can trace every permission, investigate suspicious behavior, and answer tough questions about who did what, when, and why.”

Try Cerbos. Your engineers get permitted lists straight from the queries they already run. Your identity team sees a leaver lose access the moment the directory changes, with no tuples to delete. Your security team can show which policy allowed each AI agent tool call. To plan the move from OpenFGA, book a call with our team and leave with a migration plan your security and audit teams can review.

---

Go deeper:

• OpenFGA alternatives
• Migrating from OpenFGA to Cerbos
• How Cerbos works
• How to adopt externalized authorization (eBook), for a step-by-step playbook on moving authorization out of application code