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.

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.