Authorization is not a feature you bolt on at the end. It runs continuously at runtime. Every request, every service interaction, every automated action depends on it. And as your organization grows, compliance frameworks, data residency laws, and security requirements start shaping where and how that authorization infrastructure can live.
Getting the deployment model wrong creates real problems. If authorization data ends up in the wrong jurisdiction, you fail an audit. If policies can't be updated without downtime, you slow engineering to a crawl. If decision logs don't stay where your regulators expect them, you introduce risk that no amount of good policy writing can offset.
This guide walks through the deployment models available for your authorization system, what drives the choice between them, and what each one means for your team in practice.
Understanding the real authorization deployment choice
Conversations about deployment models for authorization often create more confusion than clarity. Terms like "on-premise," "self-hosted," "BYOC," and "air-gapped" get treated as separate categories when they're actually describing overlapping things.
It helps to start from how externalized authorization actually works. There are two main components. The Policy Decision Point (PDP) evaluates authorization requests in real time. The control plane handles policy authoring, validation, versioning, distribution, and audit logging.
The PDP always runs inside your infrastructure. Whether deployed as a sidecar, a shared service, or using WebAssembly-compiled policy bundles, the decision engine sits close to your workloads. That's a constant, not a variable.
What changes is where the control plane runs. It can be managed by the vendor in the cloud. Or it can run inside your own environment. That's the core choice.
Your environment itself has its own properties. It might be a public cloud account, a private data center, or a network with no external connectivity at all. Air-gapped isn't a separate deployment model. It's a property of the environment where you operate a self-hosted control plane.
So the real decision tree is simpler than most articles make it seem.
Cloud-hosted control plane
When it makes sense
Cloud-hosted authorization works when you're building SaaS products, operating global services, or need to scale without maintaining additional infrastructure. The vendor manages the control plane, handles upgrades, patching, compliance certifications, and incident response. Your team focuses on writing policies and integrating authorization into your applications.
This fits when your compliance framework allows vendor-managed services and when you don't have strict data residency requirements that mandate keeping authorization data inside your own perimeter. It also fits teams that don't have the capacity to run Kubernetes clusters, manage certificate rotation, or staff 24/7 infrastructure support. In those cases, delegating operational responsibility is genuine risk mitigation.
Geographic distribution is another factor. If your users span multiple continents, a cloud provider with global points of presence can place stateless PDPs closer to users than most teams could manage on their own. Since every request waits for an authorization decision, latency matters.
How it works
Policies are authored through the control plane interface, validated and compiled by the vendor's infrastructure, and distributed to PDPs that evaluate authorization requests inside your environment. Your applications call these PDPs over gRPC or REST, typically with sub-millisecond to low-millisecond latency depending on network topology.
The vendor handles versioning, rollback, and distribution. Audit logs flow into the vendor's logging infrastructure, accessible through APIs or dashboards.
Trade-offs
The economic model is OpEx-based, with monthly or annual pricing tied to usage. This removes large upfront capital investments and aligns cost with scale.
You trade customization for convenience. Integrating with an internal certificate authority or routing audit logs through a proprietary pipeline may require working within the vendor's API boundaries. And if an auditor asks exactly where authorization decision logs are stored, the answer depends on the vendor's infrastructure choices. For organizations operating under frameworks that demand full control over where access decisions and their logs reside, this can be a deal-breaker.
Self-hosted control plane
When it makes sense
Self-hosted means you run the authorization control plane inside your own environment, alongside the PDPs that already live there. Your environment could be a cloud account you operate (AWS, GCP, Azure), a physical data center, or both.
The strongest drivers are compliance and data sovereignty. Regulations like GDPR in Europe, HIPAA in the United States, CCPA in California, and provincial privacy laws in Canada often require proof that sensitive data does not leave a controlled environment. This includes authorization decisions and their audit trails. Healthcare audits can hinge on demonstrating that authorization logic never traverses the public internet. Financial regulators expect full traceability of every access decision.
A financial institution in Canada, for example, may need to prove that every audit entry is stored inside Canadian data centers. A self-hosted deployment lets them point auditors directly to their own logging systems without relying on a vendor's regional hosting promises.
Self-hosted also works for organizations that need direct integration with internal PKI, observability stacks, or identity systems the vendor doesn't natively support. And it gives teams full control over how PDPs scale across clusters and regions.
How it works
Policies are authored by your teams, validated, compiled, and encrypted in your self-hosted control plane, then distributed as signed bundles to your PDPs. Applications call local PDPs over gRPC, REST, or Unix domain sockets. All decision logic, audit logs, and management traffic stay within your perimeter.
With Cerbos Hub deployed on-premise, you get the same capabilities as the cloud service. Policy management through Git workflows and CI pipelines, APIs, or the Hub UI. Built-in validation and testing before production deployment. Controlled rollouts without redeploying applications. Decision logs that capture requests, actions, resources, outcomes, and the exact policy version behind each decision for complete traceability.
Running in air-gapped environments
Some organizations operate networks with no external connectivity. Defense, government, energy grids, and critical infrastructure often mandate this level of isolation.
Authorization in an air-gapped environment works the same way, but policy updates and patches must be transported manually or through one-way transfer channels. Policies are signed and exported as bundles on the connected side, carried across the gap, and verified before activation. Decision logs are collected internally and exported on controlled schedules for compliance reporting.
The operational overhead is higher. Every update moves on human schedules. Monitoring must work within closed networks. But for organizations where the cost of a single intrusion outweighs operational convenience, this is the right trade-off.
Costs and responsibilities
Self-hosted deployments put the operational burden on your team. You own uptime, monitoring, patching, backups, and upgrades. High availability requires designing and operating redundancy across clusters and sites.
The benefit is certainty. All data, policies, and logs remain under your governance. Compliance frameworks like SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, and FedRAMP all benefit from the ability to demonstrate that authorization decisions and their audit trails live entirely within your infrastructure.
But compliance is a moving target. Standards evolve, and what satisfies auditors this year may not be enough next year. Self-hosted gives you the agility to adapt quickly within your own environment, but it also means you carry that responsibility yourself.
At small scale, self-hosting can look cheaper than paying for a managed service. Total cost of ownership rises once you factor in 24/7 staffing, patch management, and incident response. Teams that choose self-hosted for cost savings sometimes discover later that the headcount required to run it safely erodes the difference.
How to decide
The decision comes down to a few factors, roughly in order of how much they constrain your options.
Compliance is the most rigid. If regulations require that authorization data never leaves your environment, cloud-hosted is off the table. This comes up consistently in financial services, healthcare, government, and defense.
Operational capacity is where the practical trade-off lives. Self-hosted gives you maximum control, but it requires staff, process, and discipline. If your team can run it, you get sovereignty and flexibility. If not, the cost of operational gaps (delayed patches, misconfigurations, slow incident response) can outweigh the control benefits.
Latency and scale are usually comparable between the two models. Both support sidecar and shared pool architectures. Both deliver sub-millisecond response times for sidecar deployments. The PDP runs in your infrastructure either way.
Cost looks different at each scale. Cloud-hosted aligns cost with usage. Self-hosted requires planning for infrastructure and staffing. The true total cost of ownership only becomes clear after sustained operation.
Some large organizations run both. Self-hosted deployments protect the most sensitive or regulated workloads. Cloud-hosted authorization handles SaaS-facing services and less restricted environments. The key is keeping policy authoring, testing, and auditing unified across all environments so your authorization logic doesn't fragment.
What this looks like with Cerbos
Cerbos PDP is the open-source authorization engine at the core of the platform. It evaluates authorization requests against policies and returns access decisions.
Cerbos Synapse gathers identity, resource, and relationship data from your existing systems - identity providers, databases, graph databases, internal APIs - and delivers complete context to the policy engine before every authorization decision.
Cerbos PEP SDKs are client libraries that connect your applications directly to the PDP and enforce real-time access decisions.
Cerbos Hub is the control plane for policy authoring, testing, versioning, distribution, and audit visibility. It handles policy distribution across every PDP instance so updates propagate without restarts or redeployments. Security and compliance teams get full visibility into every authorization decision with structured audit logs that meet SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, FedRAMP, NIS2 and DORA requirements. Cerbos Hub supports both cloud-hosted and on-premise deployment. On-premise Hub runs in your data center, your cloud accounts, or fully air-gapped networks.
Both deployment models get identical capabilities. Centralized policy management, Git-native workflows, CI/CD integration with policy validation on every commit, built-in testing with coverage reports, and structured audit logs that support compliance requirements across SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, and FedRAMP.
Utility Warehouse runs Cerbos across 4,500 services and millions of NHIs with sub-millisecond authorization. 4G Capital saved $264k per year compared to building in-house and stays audit-ready across ISO 27001, SOC 2, GDPR, and PSD2. Salesroom deployed enterprise-ready authorization in three weeks.
The deployment model should match your environment and risk appetite. The authorization logic stays the same regardless.
Try Cerbos to see how policy management works across deployment models, or book a call to talk through your architecture with the team.
Go deeper:
- How to Adopt Externalized Authorization (eBook) for a step-by-step playbook on decoupling authorization from application code
- Learn more about Cerbos on-premise here
FAQ
Tagged in
