Policy as code, and as data
OPAL watches a private git repo and pushes new Rego straight into every OPA instance within seconds of a commit — no redeploy, no restart. That's policy code: reviewed, versioned, git-gated. But not every policy change needs a pull request. This demo splits off a second, deliberately narrower tier — policy data — that's safe for any logged-in visitor to edit directly, live.
- • Lives in a private GitHub repo, OPAL-watched
- • Full Rego — arbitrary logic, real review surface
- • Push → OPAL diffs → OPA gets a new bundle in ~5s
- • Lives in Redis — a closed vocabulary, not code
- • Any logged-in visitor can edit it, no review gate
- • Save → OPAL's data channel pushes it in ~2s
Log in below and edit which cohorts unlock each feature flag. This writes to Redis, not git — the change reaches the live feature-lab demo in about two seconds via OPAL's data-source channel, no redeploy.
⚠️ Honest caveat: this is a shared demo resource with no per-user isolation — anyone else visiting right now can also change it, and your edit is visible to every visitor. Fine for a toy; not how you'd ship a real multi-tenant feature-flag system.
Authenticate
- What it costs
- Splitting policy into 'code' and 'data' tiers is an extra concept for anyone reading the system — two propagation paths (git-diff bundle push vs. an on-demand data-update event) to reason about instead of one. The data tier's safety rests entirely on the schema being a genuinely closed, small vocabulary; it stops being safe the moment it grows expressive enough to encode real logic, which is exactly why raw Rego authoring gets its own separate, role-gated tier instead of being bolted onto this one.
- When you'd choose differently
- If every policy change can safely go through a PR — small team, low change frequency — skip this split and let OPAL's git channel be the only path; it's simpler to operate and reason about. Reach for a live-editable data tier when the change frequency or the number of people who need to make small, low-risk tweaks (feature-flag cohorts, threshold values) would otherwise turn your git history into a stream of trivial data-only commits.
- What it costs
- A per-request `opa eval` subprocess is real, measurable overhead per submission (process spawn, not just an in-memory call) — fine at demo-traffic volume, a real bottleneck if this tier saw production-scale submission rates. The restricted builtin set is an allowlist regenerated from a pinned OPA version, not something that auto-updates; a future OPA release adding a new dangerous builtin stays excluded here until this file is deliberately regenerated. And the promoted-policy namespace fencing (data.authored.*) only holds because every real-traffic policy was written to never reference it — that's a discipline this demo enforces by code review, not by any mechanism that would stop someone from wiring it in later.
- When you'd choose differently
- Skip a raw-Rego tier entirely if your users only ever need to express a handful of closed choices — the data-authoring tier above covers that with far less risk. Reach for this pattern when policy authors genuinely need Rego's expressiveness (arbitrary boolean logic over arbitrary input shapes) and you're prepared to operate the sandboxing seriously: restricted builtins, enforced namespacing, real resource limits, and an audit trail — not just a role check in front of an eval() call.