Use both tools for comprehensive policy enforcement
across your entire SDLC
from
pull requests to
production deployments
The Best of Both Worlds
Lunar catches policy violations before code is merged, giving developers immediate, contextual feedback. OPA provides the final enforcement layer at deployment time, ensuring nothing reaches production that shouldn't.
The later you catch a policy violation, the more expensive and disruptive it becomes.
Developer sees feedback immediately, in context, while they're still working on the feature
Deployment blocked at the gate, team scrambling, release delayed
Issue made it to production, causing outage or security incident
The takeaway: These tools complement each other perfectly
Lunar provides early developer feedback. OPA provides final production safety and runtime authorization.
Choose the approach that fits your needs—or combine them for maximum value
Port your existing OPA policies to Lunar guardrails and get PR-level feedback instead of deployment-time blocks.
Use Lunar for PR feedback on all standards. Keep OPA as your final enforcement gate for critical production policies.
Keep OPA as your main enforcement tool, but feed it richer context from Lunar's SDLC data collection.
Get the best of both worlds: Use Lunar to provide early PR feedback to developers (approach #2), while feeding Lunar's rich SDLC data into OPA for more intelligent policy decisions (approach #3). This gives you defense in depth with enhanced context—developers get helpful guidance early, and your final enforcement gate makes smarter decisions with better data.
Yes! Lunar supports Rego policies natively. If your policies expect standard K8s AdmissionReview or Terraform plan JSON shapes, they'll typically run as-is. Otherwise, you may need a small input-mapping wrapper. You'll get PR-level feedback instead of deployment-time blocks.
Yes! Lunar supports multiple enforcement levels including "block-deploy" which prevents production deployments. However, its key strength is providing earlier feedback in PRs.
Strictly speaking, OPA can evaluate any JSON data you feed it. But it does not have any capabilities to collect that data from your SDLC. Lunar, however, adds a built‑in collector system and central Component JSON, so you get that SDLC data without building your own crawlers and wiring.
No! They work great together. Most customers use Lunar for early PR feedback and keep OPA as their final production gate. This gives you defense in depth and the best developer experience.
Lunar's central cataloger automatically detects which repositories are sensitive or production-critical by integrating with your existing catalog information — such as an IDP (Internal Developer Portal), GitHub metadata, or custom classifiers.
Once classified and tagged, the appropriate guardrails can be applied globally per-tag — no need to configure each repo individually or maintain templates across thousands of repositories.
You can, and it works fine for repo-local checks. The issue is scale: OPA-in-CI still needs per-repo wiring, doesn’t know which repos are production-critical, and gives you PR‑by‑PR feedback and doesn’t, by itself, give you a PR‑centric, SDLC‑wide control plane or org‑wide guardrail view — you have to build that around it.
Lunar adds that missing layer — catalog-aware targeting, built-in SDLC data collection, centralized rollout/enforcement, and unified visibility — so guardrails (including Rego policies) are applied consistently to the right repos.
Start catching policy violations in PRs, not at deployment time.
See how Lunar guardrails can automate your existing OPA workflows and manual processes.