When to use CrowdControl

The short decision guide. For the long version, see the comparison page.

Pick CrowdControl when

Most of these should be true:

  • Rules should be reviewable by people who don't write code every day.
  • The thing you're gating is a document — a Terraform plan, a GitHub event, a Kubernetes manifest, a config file — not a runtime request.
  • You want the fastest path from "new rule idea" to "new rule in CI".
  • You want a dependency-free embed, not another service to run.
  • Your rules are simple enough that a bounded grammar is fine.

Pick something else when

There's a real structural gap:

  • You need entity-based authorization across a user/resource graph → CEDAR, SpiceDB, or OpenFGA.
  • You need relationship/Zanzibar-style authorization queries → SpiceDB or OpenFGA.
  • You need machine-checked proofs about policy semantics → CEDAR.
  • You need a Turing-complete policy engine and the readability cost is acceptable → Rego / OPA.

Roadmap gaps (not reasons to switch)

These are operational / tooling things that don't exist yet but don't belong in the "switch to something else" column:

  • A cc serve PDP with audit logs and rollout controls
  • Policy bundle distribution
  • Hosted playground
  • Metrics and health endpoints

All of these are thin wrappers on top of the existing engine. If any are blockers, open an issue.

Good-fit examples

  • Terraform PR gate — evaluate flattened plan + PR metadata against rules in CI.
  • GitHub branch protection — check PR shape, approvals, file paths, labels.
  • K8s admission shim — evaluate manifests before they hit the cluster.
  • Config lint — every service must have owner, runbook, oncall.
  • Change review checklists — gate promotion between environments.

Bad-fit examples

  • Per-request API authorization — use CEDAR or Cerbos.
  • Zanzibar relationship queries — "does Alice share folder X with Bob?" — use SpiceDB.
  • Admission control with recursive policy composition — use OPA/Gatekeeper.