Policy stores :: Cerbos Authorization Management Platform // Documentation

Policy stores

Policy stores are flexible containers for Cerbos policy files managed inside Cerbos Hub. A store decouples policy storage from any specific source control system, letting each team choose the workflow that best fits its needs while Cerbos Hub guarantees validation, versioning, and secure delivery to deployments.

Why use policy stores

Clear boundaries and ownership

Create one store per team, product, tenant, or environment so each group owns just the policies that matter to them, reducing cognitive load.

Independent update cadence

Teams can update their store at any time without blocking others, a new deployment is built only when you choose to combine the stores.

Layered policy logic

Combine multiple stores in a single deployment to apply global guard rails, platform defaults, application-level rules, and tenant overrides in a predictable hierarchy.

Source agnostic workflows

Populate a store from Git, a CI pipeline, the Cerbos Hub API, the cerbosctl CLI, or a direct UI upload, no GitHub lock-in.

Full visibility and auditability

View every policy file in Hub, see which store and commit contributed to a deployment, and trace any PDP decision back to the exact policy version.

Supported ingestion methods

Method Typical use case
Git repository Structured policy as code managed with pull requests and reviews. If you are using GitHub, you can connect your repository directly to a policy store in Cerbos Hub.
CI or CD pipeline Push the policies produced by a build job, for example when generating service-specific policies or promoting between environments.
Cerbos Hub SDKs Programmatic updates such as per-tenant roles, user-defined permissions, or event-driven changes.
cerbosctl CLI Local scripting, quick one-off uploads, or integration into existing tooling.
Browser upload Ad hoc tweaks, demos, or importing legacy policy files.

Life-cycle inside Cerbos Hub

  1. Create a store in Cerbos Hub workspace.

  2. Add or update policy files using any supported ingestion method.

  3. Automatic validation ensures policies are correctly formatted.

  4. Reference the store in one or more deployments to build a versioned bundle.

Store detail page

Each policy store has a detail page with the following tabs:

Import

Add policies to the store by uploading files, connecting to a Git repository, or using other ingestion methods.

Policies

Browse the current contents of the store in a file tree. Select a version from the dropdown to view historical snapshots. Click Create playground to experiment with the policies in an isolated environment—this creates a playground pre-populated with all policies and tests from the store.

Version history

View a chronological list of all versions, showing when each was created and what changed.

Client credentials

Manage API credentials scoped to this store for programmatic access via SDKs or the CLI. Each credential shows its type (read-only or read and write), usage statistics, and when it was last used.

Settings

Configure store options and manage connections to external sources like GitHub.

Best practices

Use meaningful names

Name stores after their responsibility, for example security-global, platform-core, payments-service, or tenant-alpha.

Keep tests with policies

Store-specific tests catch regressions early and run automatically on every change.

Protect production stores

Restrict write access and require review for stores that feed your production deployment.

Isolate dynamic inputs

Create a dedicated store for API-driven or user-defined policies to avoid mixing static and dynamic files.

Review store composition

Periodically confirm that each deployment references only the stores it needs and in the correct order.