Skip to main content

Open-source Fallback

Learn which open-source projects Permit.io is built on, and how you would replace Permit with a self-managed stack built on those projects. This page is for technical decision makers who evaluate vendor lock-in before adopting Permit.

Permit open source as a fallback

Permit is not an open-core company, but many of the components under Permit are open source. Those components give you a fallback: you can migrate away from Permit, avoid vendor lock-in, or use the components in your own stack. The choice to stay or leave stays with you.

Open-source components under Permit

ComponentRole in PermitRepository
Open Policy Administration Layer (OPAL)Part of Permit's control plane. OPAL pushes policy and data updates to policy decision points (PDPs) as events occur.permitio/opal
Open Policy Agent (OPA)A policy engine that evaluates Rego policy inside Permit PDPsopen-policy-agent/opa
Cedar-agentA policy engine option that evaluates Cedar policypermitio/cedar-agent
Permit PDPThe PDP container that runs OPA and the OPAL client next to your servicespermitio/PDP
Permit SDKsOne SDK per language that sends permission checks from your code to a PDP and wraps the Permit APIpermitio on GitHub

Migrate from Permit to a self-managed stack

The migration replaces each Permit-managed part with a component you run:

  1. Export your policy code. Connect a Git repository with GitOps. Permit writes the policy code generated from the Policy Editor to that repository. The code runs on the policy engine it was generated for, and you can edit it freely.
  2. Run your own control plane. Deploy an OPAL server that tracks your policy repository and your data sources. See the OPAL documentation.
  3. Build PDP images. Package the OPAL client with your policy engine of choice (OPA or Cedar-agent). The OPAL documentation covers running the OPAL client with an inline OPA.
  4. Send checks from your code. Write a client for your policy engine's API, or adapt the open-source Permit SDKs to call your PDPs.
  5. Add management interfaces (optional). Build the back-office and customer-facing interfaces you need, as an API or a UI.