---
title: "Open source Cerbos vs paid Cerbos"
description: "Open source vs paid Cerbos explained. The Apache 2.0 engine is complete and free, running over 2 billion checks a month. See what the commercial platform adds around it, policy distribution, compliance audit, and data enrichment, plus the roughly 19 engineer months it takes to build the equivalent yourself."
author: "Anna Paykina, Alex Olivier & Emre Baran"
date: "2026-08-18T13:09:04.894Z"
canonical: "https://www.cerbos.dev/blog/open-source-vs-paid-cerbos"
image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/open_source_cerbos_vs_paid_cerbos_5291dcd0e7.png"
tags: ["guide"]
source: "https://www.cerbos.dev/blog/open-source-vs-paid-cerbos"
---
# Open source Cerbos vs paid Cerbos
[Watch on YouTube](https://www.youtube.com/watch?v=0DDin9I0abc)
Fewer and fewer teams build their own authorization from scratch. It has gone the way authentication, payments, and cloud storage went before it, teams stop reinventing the hard, security-sensitive parts and reach for a ready-made solution so they can get back to their actual product. That is [increasingly the default](https://www.cerbos.dev/blog/build-vs-buy-authorization), and it is a big part of why teams land on Cerbos.
Where they land differs. Some pick up the open source engine, run it themselves, and later ask what the paid platform adds. Plenty of others skip that step and go straight to the full platform, because they already know the shape of what they are building and know they will need it.
Either way the question is the same, and it is not whether the free engine is secretly held back to force an upgrade. It is complete, and it stays that way. What you pay for is not a better engine. It is everything around the decision that you would otherwise build and run yourself.
This piece walks through what that means, what you get for free, what you take on when you stop at the engine, and where the paid platform earns its place for each kind of team.
#### Table of contents
- [What Cerbos actually is](#What-Cerbos-actually-is)
- [What the free, open source Cerbos PDP includes](#What-the-free-open-source-Cerbos-PDP-includes)
- [What open source Cerbos PDP leaves you to build yourself](#What-open-source-Cerbos-PDP-leaves-you-to-build-yourself)
- [Why authorization keeps getting harder to manage at scale](#Why-authorization-keeps-getting-harder-to-manage-at-scale)
- [What Cerbos Hub and Cerbos Synapse add over the open source PDP](#What-Cerbos-Hub-and-Cerbos-Synapse-add-over-the-open-source-PDP)
- [How to move from open source Cerbos to the paid platform](#How-to-move-from-open-source-Cerbos-to-the-paid-platform)
- [Open source vs paid Cerbos, which one do you need](#Open-source-vs-paid-Cerbos-which-one-do-you-need)
## What Cerbos actually is
> [High-level video walkthrough of how Cerbos works.](https://www.youtube.com/watch?v=0DDin9I0abc)
Cerbos is an authorization management platform. It answers one question consistently, whether a given identity is allowed to take a given action on a given resource, and it answers it not just inside your applications but across the gateways, workloads, and AI agents that now need the same fine-grained, contextual control. It is the kind of thing nobody enjoys building twice.
It splits into four parts, and knowing them makes the free versus paid question much clearer.
* The [Cerbos PDP](https://docs.cerbos.dev/cerbos/latest/) is the open source authorization engine at the core. It evaluates requests against your policies and returns an allow or deny. It is stateless, lightweight, and runs anywhere, in containers, on Kubernetes, in serverless functions, or at the edge.
* The [PEP SDKs](https://www.cerbos.dev/ecosystem) are the client libraries that connect your application to that engine and enforce its decisions in real time, with support for all major languages, including JavaScript, Go, Python, Java, .NET, Rust, PHP, and Ruby.
* [Cerbos Hub](https://www.cerbos.dev/product-cerbos-hub) is the control plane that sits above a fleet of PDPs and handles authoring, testing, versioning, distribution, and audit visibility.
* [Cerbos Synapse](https://www.cerbos.dev/product-cerbos-synapse) is the newest data layer that gathers identity, resource, and relationship data from the systems you already run and delivers full context to the engine before each decision.
The engine and the SDKs are Apache 2.0 and free. Hub and Synapse are the commercial platform. Put together, the four give you one governed layer for every authorization decision instead of a decision engine sitting on its own with a pile of glue code around it.
## What the free, open source Cerbos PDP includes
[Watch on YouTube](https://www.youtube.com/watch?v=f8S111ms-Ck)
Good news \- the open source PDP is a full decision engine, not a teaser.
Every policy feature ships in it. [Resource and principal policies](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html), [derived roles](https://docs.cerbos.dev/cerbos/latest/policies/derived_roles.html), conditions written in CEL, schema validation, and first class test suites are all there. So is [Query Plan](https://docs.cerbos.dev/cerbos/latest/recipes/filtering-resources), which returns a filter you push straight into your database so you can list the rows a user is allowed to see without pulling a million and checking them one at a time.
Policies are plain YAML in your Git repo, so both engineers and product managers can read them, and they cover [RBAC](https://www.cerbos.dev/features-benefits-and-use-cases/rbac), [ABAC](https://www.cerbos.dev/features-benefits-and-use-cases/abac), and relationship based rules in the same file.
It is production grade and free. Stateless, fast, and run by teams across more than 2 billion authorization checks a month. No license, no account, no usage cap on the decisions themselves. This is not open core in the sense people usually mean it, where the free tier is a demo and the useful parts are locked away. The binary you run in production is the same binary whether or not you ever pay us a cent.
For a single service that already holds the attributes its policies need, with no external audit requirement, the free engine is genuinely usually enough.
The moment you have more than one service, more than one environment, or a compliance obligation, the picture changes. Not because the engine runs out of road, but because a running engine is only part of what a real authorization setup needs.
## What open source Cerbos PDP leaves you to build yourself
When teams run a proper evaluation of authorization options, the decision engine turns out to be only one of the dimensions that matter. Integration with your stack, developer and admin experience, distribution, audit, compliance, and vendor support all sit alongside it, and we cover the full set in a separate [evaluation framework](https://www.cerbos.dev/blog/framework-evaluating-authorization-providers-solutions).
The engine is the one dimension open source nails outright, and it happens to be one of the hardest and most security-sensitive. The decision logic itself is the part teams so often end up building by hand, getting subtly wrong, and never fully understanding afterward, and the open source engine takes all of that off your plate.
The other dimensions are where the work moves next. They are the operational layer around the engine, and once you are running more than one instance, that layer is yours to build and maintain. It is easy to underestimate before you are living it.
### Authoring and collaboration
With the engine alone, policies are YAML files you edit locally and share through Git. That works for a couple of engineers. Once product managers, several developers, and reviewers are all touching authorization logic, you are coordinating everything by hand in pull requests, and merge conflicts and slow iteration come with it.
[Cerbos Hub](https://hub.cerbos.cloud/) adds a browser based playground where people edit together with real time feedback, pre built examples, and a wizard for generating common role based policies, so a product manager can reason about a rule without checking out a branch.
### Testing
The PDP supports first class policy tests, but running them is on you. That means your own pipelines in GitHub Actions or CircleCI, your own scripts, your own runners, and combing through logs when something fails.
Cerbos Hub builds [testing](https://docs.cerbos.dev/cerbos-hub/deployments) into the workflow. Every change to a policy store triggers a build that compiles the policies and runs the whole test suite automatically, results show against the exact commit, and a failing test blocks the build so a broken change does not reach production. You see which test cases a change breaks and the commit that caused them.
For a team with a change management board, that matters both before a change ships and after. Before, the effect matrix lays out every role and action for a resource as a grid and shows whether each combination is allowed, denied, or conditional in the built bundle, and it flags where a wildcard has widened access, so a reviewer can see the effective permissions a change produces instead of inferring them from the raw policy files. Execution traces show, step by step, how a given request is evaluated, so there is a clear answer to why a decision came out the way it did.
After, rollback runs on the same versioning. Every deployment is tied to an immutable set of policy store versions, so you can see exactly which policies were live at any moment and, if a change causes a priority incident, redeploy a previous known-good version. Because distribution is push based, that rollback reaches every PDP within seconds. And because you can run separate staging and production deployments, a change can clear the same build and tests in staging before it goes to production, which is usually where a change board wants the gate to sit.
### Distribution
This is the one that quietly hurts the most. On its own, every PDP instance pulls its own policies, checking the store at startup or on an interval. That is a pull model, and it means delays before a change reaches every instance and real work to track which instance is running which version. Miss it and you get version drift, where two PDPs enforce two different rulebooks and nobody notices until an access decision goes wrong.
Cerbos Hub replaces this with a [push model](https://docs.cerbos.dev/cerbos-hub/decision-points). It compiles policy into signed bundles and pushes them to every connected PDP in seconds, with no restarts and no polling, and shows you exactly which bundle each instance is serving and when it last checked in.
### Policy updates and lifecycle
Editing YAML is easy. Everything that turns an edit into a safe production change is not. On your own you maintain the CI that validates syntax, runs tests, builds bundles, and publishes them, plus the versioning, approvals, and rollback story around it.
Cerbos Hub [manages that full lifecycle](https://docs.cerbos.dev/cerbos-hub/policy-stores), validating, testing, compiling signed bundles, and marking them deployment ready, with every change versioned and auditable.
### Decision and audit logs
The PDP writes a log for every check it makes, locally, to standard output. With several PDPs that is several separate log streams with no shared context about which policy version produced which decision. Forwarding, aggregating, indexing, and stitching lineage back together is a project of its own.
Cerbos Hub collects decision logs from every PDP into one searchable place, lets you filter by policy version or environment, and lets you trace the exact policy that produced a given decision. It also charts those decisions, allowed against denied over time and the most active principals and resources, so patterns surface without you building a dashboard. For a [security team](https://www.cerbos.dev/for-security-teams), tracing a decision back to its policy is the difference between answering an auditor in minutes and spending a week reconstructing it.
---
This is the standard supporting cast around any authorization system, and building it yourself is real, sustained engineering time. We have put rough numbers on the effort to reach feature parity with Cerbos Hub using the open source engine alone.
| Capability | What the paid Cerbos solution includes | What you build yourself | Estimated effort |
| :---- | :---- | :---- | :---- |
| CI/CD for policies | Managed validation, rollouts, rollbacks | CI jobs, validation scripts, rollout playbooks | 6 FTE months |
| Testing and dev tooling | Playground, API simulator, automated test runner | Local test harnesses, fixtures, CI test pipelines | 4 FTE months |
| Policy lifecycle | Versioning, approvals, canary rollout, rollback | Versioning, release workflows, audit trails | 3 FTE months |
| Audit logs and visualization | Central audit UI, searchable logs, lineage | Log streaming, ingestion, unified context, a UI | 6 FTE months |
That is [roughly 19 engineer months](https://www.cerbos.dev/blog/cerbos-pdp-and-cerbos-hub-choosing-the-right-setup-for-your-team) of building, and then the ongoing cost of maintaining it while your team would rather be shipping product. The engine is free. The cost is in everything you build and run around it, paid either as a subscription or in headcount.
Framed that way, running the open source engine on its own is a [build versus buy](https://www.cerbos.dev/blog/build-vs-buy-authorization) decision, just narrowed to the tooling around the engine rather than the engine itself. The old rule of thumb holds. Buy for parity, build for competitive advantage. Unless authorization tooling is the product you sell, that surrounding machinery is parity work, and Loop's CTO [reckoned](https://www.cerbos.dev/customers/withloop) buying authorization outright cut six months of development before you even count the maintenance that follows. Some of that machinery you could match given enough time. Some of it you probably will not build as well. Compliance-grade audit logging, distributing policy to a whole fleet in seconds with no drift, and pulling the data each decision needs from live systems without hammering them are the kind of thing a dedicated team spends years hardening.
And the cost is not only money and effort. An authorization layer you cannot keep in sync or see into is a liability in its own right. When policies drift between instances, the same request gets allowed in one place and denied in another, and you tend to find out from an angry user or a failed access rather than a dashboard. When decision logs are scattered across instances, the honest answer to an auditor asking who could do what, and when, is that you would have to go and reconstruct it. Past a certain size, that is not a to-do you will get to later. It is a security and compliance risk you are running now.
## Why authorization keeps getting harder to manage at scale
It would be one thing if that surrounding layer were a fixed, one-time build. Get it working, maintain it lightly, and move on. But authorization has stopped being static, and the work around the engine only grows.
The industry has started naming this shift. In its 2026 reference architecture, Gartner renamed the category from externalized authorization management to the [Authorization Management Platform](https://www.cerbos.dev/blog/authorization-management-platforms), and the definition is the tell. It is not a decision engine. It is centralized authoring, versioning, translation, orchestration, and audit across many enforcement points, with the decision as one part of a larger loop.
This is happening because policies no longer get set once and left alone. They depend on real-time context, get re-evaluated as circumstances change, and have to cover machines and AI agents as well as people. Analysts have been blunt about the shift. At the 2026 European Identity Conference, KuppingerCole's Phillip Messerschmidt described dynamic authorization as a major IAM trend driven by necessity rather than fashion.
Teams do not get there by writing the perfect policy up front, because you usually cannot predict every way one service or user will try to reach another. The realistic path, which KuppingerCole's Reiner Mertens laid out at the same conference, is to start permissive and watch. You deploy policies that allow broadly, log every decision in one place, and see what actually happens in production. Those logs show which services call which, whose identity is attached to each request, and where that identity gets lost along the way. With that picture in front of you, you tighten the policies deliberately, using evidence instead of guesswork.
That loop only works if two things are easy and reliable: pushing a policy change to every enforcement point safely, and collecting every decision into one place you can query. Those are the exact two capabilities the open source engine leaves to you.
The pressure is climbing fastest around [AI agents](https://www.cerbos.dev/features-benefits-and-use-cases/ai-security) and other [non-human identities](https://www.cerbos.dev/blog/nhi-security-how-to-manage-non-human-identities-and-ai-agents). An agent acts on behalf of a person, at machine speed, across many systems at once. Every call it makes needs a decision that weighs both the agent and the human behind it, and every one of those decisions has to be logged to be governed at all. That means gathering the full context for each decision and keeping a record of every one, which is exactly what a bare engine does not do. It is not a distant concern either. Regulations like DORA, ISO 27001, and NIS2 already apply to non-human identities, so the moment agents and service accounts start touching your systems, authoring policy once and proving every agent decision centrally stops being optional.
## What Cerbos Hub and Cerbos Synapse add over the open source PDP
> [Video walkthrough of Cerbos reference architecture.](https://youtu.be/f8S111ms-Ck?si=AzmZy_1EyV32QOmH)
The commercial side is best understood not as a bolt-on, but as the answer to two problems that surround the engine once authorization grows past a single service.
**The first is getting your policies out to every place that enforces them, and every decision back for audit.** This is Cerbos Hub, the control plane. You author and test policy in one place, it runs through managed CI where a failing test blocks the build, and approved policy bundles push to every running instance in seconds. Every decision those instances make streams into a structured store built to [satisfy](https://www.cerbos.dev/blog/staying-compliant) SOC 2, ISO 27001, HIPAA, PCI DSS, and GDPR, with sensitive fields masked locally so they never leave your network. That is the [audit trail](https://www.cerbos.dev/blog/how-does-cerbos-help-with-compliance-audits-and-certifications) a security review asks for, without you building a logging pipeline yourself. For multi-tenant products, Cerbos Hub also lets each tenant or team keep its own independently versioned policy store, combined into one bundle at deploy, so teams manage their own rules without stepping on each other or leaking across tenants. If you run air-gapped or have data residency requirements, [Cerbos Hub runs on premise](https://www.cerbos.dev/features-benefits-and-use-cases/self-hosted-authorization) too. The same policies can also run in the browser as a small WebAssembly bundle, so your front end shows, hides, or disables elements from the exact rules the backend enforces. Keep the real check on the server though, that client-side copy is for the interface, not the security boundary.
**The second is getting the right data into the engine for each decision.** This is [Cerbos Synapse](https://www.cerbos.dev/product-cerbos-synapse), the data layer. The engine is stateless on purpose, which means it can only decide on the attributes it is given. That is fine when the calling app has them. It gets awkward when the identity data lives in your IdP, the resource data in a database, and the relationships in a graph store, and every service has to assemble all of it before every call. Synapse sits in front of the engine on the same API and does that assembly at decision time. Your app sends a user ID, and it returns a fully enriched request, pulling from Okta, Entra ID, LDAP, Postgres, Neo4j, and internal APIs, with caching so it does not hammer those systems. It also speaks the native protocols of infrastructure like Envoy, Kafka, Trino, and Kubernetes, so those systems can delegate access decisions to your policies without anyone writing a custom adapter. Without a layer like this, the stateless engine still needs those attributes, so you end up building and maintaining your own policy information point, the service that fetches identity, resource, and relationship data from each system and hands it to the PDP on every call. Synapse is that layer, so it is not one more thing to build.
Put together, that is one authorization layer, governed end to end. Policy authored and tested once, distributed everywhere in seconds, enriched from the systems you already run, enforced in your applications through the SDKs, and audited centrally to a standard a compliance team will accept. The orchestration across all of it is the thing you are actually paying for, and it is the thing you cannot get by running the engine harder. You are also paying for a team whose entire job is authorization, with commercial support behind it, which for a regulated or business-critical system is part of the product rather than an extra.
## How to move from open source Cerbos to the paid platform
The upgrade is easy because there is no migration. It is the same engine underneath. Switching a standalone PDP to be managed by Cerbos Hub is a configuration change, not a rewrite, and it needs no changes to your application code. You keep your policies, your SDK calls, and the way you deploy.
So it does not have to happen all at once. Teams that start with the open source engine add Cerbos Hub when keeping a fleet of instances in sync and producing audit evidence starts costing real engineering time, and add Cerbos Synapse when wiring data into the engine from a dozen systems becomes the annoying part.
Teams that already know they will need all of it just start there.
When the move happens later rather than up front, it is usually compliance and platform teams who push for it.
## Open source vs paid Cerbos, which one do you need
If you are running a single service, the caller already holds the attributes a policy needs, and no one is asking you for an external audit trail, the open source engine is genuinely enough, and you should run it and be happy.
For almost everyone else, the platform is the part that keeps authorization maintainable as it grows. Many environments and instances that have to stay consistent. A multi-tenant product where every customer's data has to stay isolated from every other's. A compliance mandate that wants queryable decision logs. Attributes and relationships spread across identity providers, databases, and graph stores. Authorization at the edge or inside a browser. Infrastructure like Envoy or Kafka that needs to ask your policies for a decision. Each of those on its own is a reason to move, and real production systems tend to have several at once.
Teams already run Cerbos at exactly this kind of scale. [Utility Warehouse](https://www.cerbos.dev/customers/utility-warehouse), a FTSE 250 company, makes authorization decisions across its whole service mesh millions of times a day, where keeping a fleet consistent and auditable is not a side task you want to hand-build. [Human Managed](https://www.cerbos.dev/customers/human-managed) replaced its own middleware with a single binary and turned a days-long permission change into a five-minute one. And the fintech [Nook](https://www.cerbos.dev/customers/nook) onboards three times as many users after moving to granular roles and permissions. Different sizes, different problems, and in each case authorization became something the team could keep changing safely instead of a growing maintenance burden.
Set against 19 engineer months of building the equivalent and the ongoing cost of running it, the paid layer is usually the cheaper way to get authorization you can actually govern.
Free versus paid turns out to be slightly the wrong frame. There is one authorization platform. The engine at the center of it is free, complete, and yours to run forever. What you pay for is everything that surrounds a decision once authorization becomes infrastructure, and for a single simple service it may be all you ever need. But for anything that grows into real infrastructure, many services, real users and agents, and an audit trail someone will eventually ask for, the platform is not the upsell. It is the product. The free engine is where you start. It is rarely where you finish. And because moving between them is a config change rather than a project, there is little reason to put it off once the pain is real.
---
See the managed side for yourself in [Cerbos Hub](https://hub.cerbos.cloud/), policy distribution, audit, and the playground, with a free tier to start on.
And if you are writing policies, the [Cerbos policy skill](https://www.cerbos.dev/blog/authorization-policies-how-to-write-test-validate-with-ai-help) turns a plain-language description of what you need into a written, tested, and validated policy bundle, so you focus on the business rules rather than the syntax.
Or if you would rather talk through what your particular setup needs, [book a call](https://www.cerbos.dev/workshop) with the team.
Go deeper:
* [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) (eBook) for a step-by-step playbook on decoupling authorization from application code
* [A CISO's benchmark for authorization maturity](https://solutions.cerbos.dev/authorization-maturity-model-a-cisos-benchmark) (eBook) for a way to gauge how governed your authorization actually is
## FAQ
### Is the open source version of Cerbos free to use in production?
Yes, the open source Cerbos PDP is free to use in production. It is licensed under Apache 2.0, needs no license key or account, and is the same binary teams run at scale across more than 2 billion authorization checks a month. It is a full authorization engine, not a trial version, so there is no usage cap or feature gate on the decision-making itself.
### What is the difference between open source Cerbos and paid Cerbos?
The difference between open source Cerbos and paid Cerbos is not the engine, it is everything around the decision. The open source PDP evaluates policies and returns allow or deny. The paid platform, Cerbos Hub and Cerbos Synapse, handles distributing policy to every running instance, collecting decision logs into a compliance-ready audit store, and fetching identity and resource data into the engine at decision time. You pay for the operational layer, not for the ability to make decisions.
### What does Cerbos Hub add over the open source PDP?
Cerbos Hub adds the control plane around the open source PDP. It gives you a browser playground for authoring, managed CI that tests policy and blocks failing builds, push based distribution that keeps every PDP in sync in seconds, and centralized audit logs you can search and trace back to the exact policy version. Building the equivalent yourself is [roughly 19 engineer months](https://www.cerbos.dev/blog/cerbos-pdp-and-cerbos-hub-choosing-the-right-setup-for-your-team) of work before ongoing maintenance.
### When should you move from open source Cerbos to the paid Cerbos platform?
You should move from open source Cerbos to the paid platform when the work around the decision starts costing real engineering time. The common triggers are running many instances that must stay consistent, a compliance mandate that needs queryable [audit logs](https://www.cerbos.dev/blog/why-audit-logs-are-important), attributes spread across identity providers and databases, or authorization at the edge. Adoption is incremental and switching from standalone to managed is a configuration change, so teams typically start with the free engine and add the platform when the pain is concrete.
### Can the open source Cerbos PDP fetch attributes on its own?
No, the open source Cerbos PDP does not fetch attributes on its own, and that is deliberate. It is stateless and decides only on the data passed to it in the request, which keeps it fast and simple. Cerbos Synapse, the commercial enrichment layer, is what fetches identity, resource, and relationship data from systems like Okta, Postgres, and Neo4j at decision time, so an application can send a user ID and get a fully enriched request back.
### Does paid Cerbos meet compliance requirements like SOC 2 and ISO 27001?
Paid Cerbos supports compliance requirements like SOC 2 and ISO 27001 through centralized audit log collection in Cerbos Hub. Every decision made by your PDPs streams into a structured store built to satisfy SOC 2, ISO 27001, HIPAA, PCI DSS, and GDPR, with sensitive fields masked locally so they never leave your perimeter. That queryable decision history is usually what a [security review](https://www.cerbos.dev/blog/how-does-cerbos-help-with-compliance-audits-and-certifications) or auditor asks for.