The policy broke in production. You ran git reset to roll back the code, but Open Policy Agent (OPA) kept enforcing the same rules as before.
That’s because OPA is often loaded with a policy bundle that lives outside your app’s Git state. Rolling back your repository doesn’t reset the policy running in OPA unless you explicitly reload it. This catches many developers off guard when debugging policy changes.
Understanding the link between Git and OPA
OPA evaluates requests using policies written in Rego. These policies are usually stored in Git repos, then deployed to OPA via bundles or API calls. If you revert commits with git reset but the deployed policy bundle remains unchanged, OPA will still use the old or broken policy in memory or on disk.
Steps to reset OPA after a Git rollback
- Identify the commit hash with the working policy version in Git.
- Run
git reset --hard <commit> to move your repo back to that point. - Rebuild or repackage the OPA policy bundle from that commit.
- Push the updated bundle to the OPA instance using your deployment method (e.g., OPA REST API
PUT /v1/policies/<id> or bundle distribution). - Verify OPA is serving the reverted policy by sending test queries.
Avoiding Git and OPA drift
To keep Git and OPA in sync, automate bundle builds on each commit to main and deploy immediately. Use version tags in policy metadata so you can confirm the loaded policy matches the intended Git hash. Store OPA’s data and policy in the same version control flow as your application code.
When debugging, remember: resetting your Git repo does not automatically tell OPA to switch policies. OPA holds whatever bundle it last received. The fix is to explicitly redeploy the version of the policy you want OPA to run.
Want to see a clean, automated Git-to-OPA pipeline that avoids this entire problem? Check it out on hoop.dev and watch it go live in minutes.