OPA returns decisions and leaves enforcement to the caller
OPA separates policy from the software that acts on it. A service sends input describing a user, action, resource, deployment, or configuration. OPA evaluates Rego rules and returns structured data. The caller then accepts a request, rejects a build, selects a cluster, or performs another enforcement action. This lets policy move through review and release independently of application code.
That boundary is also a limitation. OPA does not authenticate the user, intercept every request automatically, or guarantee that a service obeys the response. The integration must supply trustworthy facts, define an explicit decision contract, enforce the answer, and decide how to behave when no answer arrives. A general engine provides flexibility by leaving those choices open.
Rego is the main adoption cost
OPA ships as binaries and container images, and its playground lets a newcomer try rules without installing anything. The CLI can evaluate policies, format them, run tests, inspect coverage, and start a local server. Go applications can embed the SDK, while other runtimes can call REST or use compiled WebAssembly. The mechanical setup is smaller than the policy program around it.
Rego is declarative and differs from ordinary application code. Sets, comprehensions, references, unification, and undefined results require practice. An authorization rule that is undefined is not automatically a denial unless the surrounding policy establishes that default. Teams should begin with one decision, include malformed and missing input in tests, and require policy review from someone who understands both Rego and the business rule.
What happened when we ran it
Our sandbox installed commit 551581f in 73 seconds, adding 173 Go packages. The build succeeded in 110 seconds. The checkout occupied 72.2 MB, contained 7,895 files, and had roughly 488,735 lines of source. We found 13 CI workflow files, a Dockerfile, and a tests directory.
The test command ran for 240 seconds and exited 1. The harness counted 122 package test results: 121 passed and 1 failed. The supplied final lines show several successful packages and others with no test files, then only the aggregate word FAIL. They do not identify the failing package, assertion, or cause. Any more specific explanation would be invented.
The near-clean count is encouraging for a codebase of this size, but it is still a failed run. Before embedding commit 551581f or building a release from it, reproduce the suite in the intended Go environment and capture the first failing package rather than relying on the log tail. Our numbers say nothing about policy evaluation latency for a buyer's own rules and data.
REST, Go, and WebAssembly shift different work to operators
A sidecar or local daemon is language-neutral and keeps OPA's bundle, metrics, status, and logging features available. It also adds a process and a network hop that the application must monitor. The Go SDK removes HTTP and can prepare queries inside the application process, but it couples the service directly to OPA libraries and Go release work.
WebAssembly places compiled policy in another runtime or edge environment. That can suit constrained deployments, while moving data loading, policy rollout, runtime compatibility, and status reporting into the host application. The right path depends less on a headline benchmark than on who will operate distribution and failures. Prototype at least one policy update and rollback before standardizing the integration.
Bundle readiness and outage behavior need explicit rules
OPA can download signed bundles, report activation status, expose metrics, and upload decision logs. A readiness check can wait for the first expected bundle to activate before traffic reaches the process. Without that guard, an agent may be alive while lacking the policy its callers assume is present. Bundle revision and activation errors belong in monitoring, not only in a dashboard.
When OPA cannot answer, the caller chooses whether to fail open or closed. Denying every request may protect a boundary while causing an outage. Allowing requests preserves availability while bypassing policy. Write that choice down per decision, test it by stopping OPA or breaking bundle delivery, and make operators able to distinguish a policy denial from an infrastructure failure.
Issue 8911 adds a scale warning. Its reporter loaded 80 bundles containing about 800 modules and saw several-minute startup because each activation recompiled modules loaded before it. Teams using discovery with many bundles should measure cold start, reduce needless bundle splits, and keep readiness false until all required policy is active.
Untrusted schemas and Rego compilation need isolation
Issue 9000 says JSON schema built-ins resolve file:// references with local file access even when allow_net is an empty list. Since schema input can come from evaluation input, a caller able to submit an arbitrary schema may drive reads from the OPA host. An open pull request proposes denying file references whenever allow_net is configured, but users should verify the released behavior they deploy.
Issue 9088 covers a different untrusted-input edge. The Rego compiler does not accept a context and cannot be canceled through the request context during every compile stage. A service accepting user policies at runtime can therefore have a compile continue after the request is canceled. Bound input size, isolate compilation, and avoid placing arbitrary policy compilation directly on a latency-sensitive request path.
August activity supports a mature but still changing engine
GitHub showed 12,161 stars and 347 open issues and pull requests when fetched. Release v1.19.1 arrived August 17, 2026, and the repository was pushed August 26. Current work covered compiler indexing, formatting, schema restrictions, and documentation. The combined 347 count includes proposals and pull requests; it is not a defect total.
OPA is a CNCF graduated project with named adopters, a third-party security audit, editor tooling, commercial support options, and years of integration material. Those are meaningful maturity signals. They do not erase the single failure in our 122-package run or the open untrusted-input reports. Choose OPA for a policy platform with assigned owners, tested defaults, controlled bundles, and observable failures.