Why Permit.io?
Short answer: Permit.io is an authorization service with three layers: a policy decision point your services call, a dashboard where your team changes access without code, and embeddable UI for your customers. Use it when several services share access rules that change often. Don't use it when one fixed role check in a single service covers your needs.
| Fact | Value |
|---|---|
| Policy models | RBAC, ReBAC, and ABAC, plus policy as code through GitOps. |
| Deployment modes | A managed Cloud PDP, a self-hosted Edge PDP, and Nexus PDP (early access). The control plane runs in hybrid, light on-premise, or full on-premise deployments. See Deployment options. |
| SDK languages | Node.js, Go, .NET, Java, Python, and Ruby SDKs, plus generated PHP, Kotlin, Erlang, and C++ API clients. See SDK feature parity. |
| Free tier | Community plan, labeled "Free Forever" on the Permit.io pricing page: MAU 1000, Tenants 20, Authorization Queries No Limit, Environments 3, PDP Instances No Limit. |
| Audit | Decision logs on the Audit Log screen. The pricing page lists Logs Retention 14 days for Community. |
| Open-source components | The Edge PDP (permitio/PDP), OPAL, cedar-agent, the Permit SDKs, and the Permit CLI are open source. See Open-source fallback. |
| Compliance | SOC 2 Type II attested and HIPAA compliant. |
This page is for engineering leads and architects deciding whether to build application authorization in-house or use Permit.io. It explains what Permit provides and how each part works.
What authorization covers
Authorization decides what a signed-in user or service can do in your application. For example: can Macy, an editor in the acme-corp tenant, publish a document?
Answering that question in production takes more than an if statement in your code:
- Your services need a fast, consistent decision at every enforcement point.
- Your product, support, and security teams need to change who can do what without a code release.
- Your customers' administrators need to manage their own users and approve access requests.
Permit provides one layer for each of these needs.
Decision infrastructure for your services
Permit decouples authorization policy from application code. Your code calls permit.check(), and a policy decision point (PDP) evaluates the policy and returns the decision.
- Control plane. Permit's cloud stores your policy and the identifiers it refers to: users, roles, tenants, and resources. You manage it in the dashboard, the API, the Terraform provider, or GitOps.
- PDP. You run the PDP container in your own network, next to your services, or use the managed Cloud PDP. Open Policy Administration Layer (OPAL) pushes policy and data changes from the control plane to each PDP.
- SDKs and APIs. SDKs for your backend language send checks to the PDP and manage users, roles, and tenants through the Permit API. See the SDKs overview.
The call below asks whether macy@acme.com, an editor in the acme-corp tenant, can publish a document. Replace <YOUR_API_KEY> with your environment API key, and set pdp to your PDP URL:
import { Permit } from "permitio";
const permit = new Permit({ token: "<YOUR_API_KEY>", pdp: "http://localhost:7766" });
const permitted = await permit.check("macy@acme.com", "publish", {
type: "document",
tenant: "acme-corp",
});
A PDP container answers thousands of checks per second with sub-millisecond latency. When it runs as a sidecar, checks go over the loopback interface, so there is no network latency. For the architecture, see How Permit.io works.
A back office for your team
The Permit dashboard lets the people who manage access change authorization without writing code. A product manager can grant the Editor role publish on Document in the Policy Editor, and the change reaches every PDP without a deploy.
Member roles (Workspace Owner, Workspace Editor, and Workspace Viewer) control which team members can change policy, for the whole workspace or for a single project or environment. For example, a product manager can be an editor in the staging environment and a viewer in production. The Audit Log screen shows the decisions your PDPs make, so the team can see why a user was allowed or denied.
Embeddable UI for your users
Permit Elements are embeddable UI components for user management, access requests, approvals, and audit logs. You embed them in your application so your customers' administrators can manage access in their own tenant, and your Permit policy controls what each administrator can do in those components.
Compliance
Permit.io is SOC 2 Type II attested and HIPAA compliant. For security and compliance details, see permit.io.
Frequently asked questions
Should I build authorization myself or use Permit.io?
Building it yourself fits one service with a few fixed roles. Use Permit when your services need a fast, consistent decision at every enforcement point, when product, support, and security teams must change access without a code release, or when your customers' administrators must manage their own users. The Permit capabilities checklist compares each capability with a homegrown service.
What does Permit.io provide?
Decision infrastructure (a policy decision point, SDKs, and APIs), a back office for your team (the dashboard with the Policy Editor and Audit Log), and embeddable UI for your users (Permit Elements).
Which authorization models does Permit.io support?
RBAC, ReBAC, and ABAC. You can combine them in one policy. The managed Cloud PDP evaluates RBAC and ReBAC, and an Edge PDP also evaluates ABAC.
Can I run Permit.io inside my own network?
Yes. You run the PDP container in your network, next to your services, and the control plane stays in Permit's cloud by default. Light on-premise and full on-premise deployments move more of the stack into your network. See Deployment options.
Is Permit.io open source?
Permit is not an open-core company, but the PDP, OPAL, and the Permit SDKs are open source. See Open-source fallback for the exit path.
Does Permit.io have a free tier?
Yes. The Community plan on the Permit.io pricing page is labeled "Free Forever" and lists MAU 1000, Tenants 20, Authorization Queries No Limit, Environments 3, and PDP Instances No Limit.