Permit Nexus PDP

Authorization infrastructure built for massive scale and speed.

Trillions of authorization decisions.
Billions of identities.
One distributed runtime, easily deployed.

Nexus is a ground-up rewrite of Permit’s policy decision point. Your authorization graph lives on disk in SurrealDB, changes arrive over a durable NATS stream, and OPA evaluates policy without a single network hop in the decision path.

Request access Book a demo Talk with our engineers

Read the docs

Now in early access. Already running in production with an early customer, and open to a limited number of teams.

A Permit control plane streaming policy and data over NATS to a large fleet of Nexus PDP nodes, each with its own local disk, watched over by the Permit Akita mascot. — One control plane, a durable stream per PDP, and every decision answered from local disk.

The Classic PDP hit three ceilings. So we removed them.

Relationships need a graph, not a JSON document
The classic PDP keeps authorization data inside OPA as one in-memory JSON document, with no indexes and no concept of edges. ReBAC and derived roles ask exactly the questions that shape cannot optimize.
Nexus keeps the fact graph in embedded SurrealDB, and OPA asks it relationship questions over a local loopback.
Memory grew with every identity
OPA’s own documentation puts raw JSON at roughly 20x the memory of the same data stored compactly on disk. At billions of identities, that is the bill.
Nexus stores that compact form on disk and keeps a bounded cache in memory, so memory is a number you set.
Every update cost a round trip
A notification said something changed, and a second call fetched what. After a disconnect the PDP re-fetched, because nothing remembered what it had already seen.
Nexus receives the change itself on a durable NATS stream, retained for each PDP until it confirms it applied it.

Book a demo Talk with our engineers

Two paths that never block each other

Inside one container, the path that answers decisions only reads, and the path that keeps data fresh only writes. They meet at an embedded database, so syncing never slows a decision down.

Nexus PDP, one container per environment

Dashed boxes are outside the container.

Request path: reads only

Your service

SDK or AuthZEN call

Authorization API

:7000

OPA

evaluates policy

Query loopback

127.0.0.1

Sync path: writes only

Permit control plane

policies and data

NATS stream

durable, per PDP

Change ingest

ordered, atomic

Self-healing

gap detect, rebuild

Where they meet

SurrealDB

embedded, on RocksDB

The fact graph on local disk: users, tenants, resources, and relationships.

No step in answering a decision contacts Permit. Reads never wait on syncing, so a control-plane outage costs freshness, never availability.

SurrealDBThe fact graph, on disk: Users, tenants, resource instances, and relationships live in an embedded SurrealDB store on RocksDB, built for the graph traversals ReBAC depends on.
NATSSync that never loses a change: Each PDP holds a durable subscription. The control plane keeps every change until that specific PDP confirms it applied it, and the data travels in the message.
OPAThe policies you already have: Policy is evaluated by OPA with the same evaluation core as Permit’s managed Cloud PDP, against the roles and relationships you author in Permit.

Talk with our engineers Book a demo

Built for scale, designed to keep answering

No network in the decision path: Every hop is loopback or local disk. Requests are authenticated against the container’s own key, so Permit’s API is never on the hot path.
Memory is a number you set: The data set lives on disk and a configurable cache bounds what stays resident, so memory stops scaling with your identity count.
Serves stale before it serves nothing: If the control plane is unreachable, decisions keep flowing from the local copy indefinitely, and the health endpoint reports how stale it is.
Resumes exactly where it left off: Changes are retained per PDP on the server side. A restarted or disconnected PDP picks up from its last acknowledged position, with no re-fetch.
Converges by construction: An ordered log, a newer-wins merge, and atomic transactions: PDPs that saw the same changes hold the same state, and replays are safe.
Self-healing, without downtime: If a PDP falls too far behind, it builds a fresh database in the background and swaps it in atomically while it keeps answering.
Cold start from pre-built files: First boot loads checksum-verified database files straight into the storage engine instead of replaying records one by one, and fails closed on a partial set.
Isolated by design: One container serves exactly one environment. Credentials never reach child processes, and a compromised PDP holds no key to any other environment.

Benchmarks, with the methodology

Nexus runs the same policy evaluation core as Permit’s managed Cloud PDP. These are its published benchmarks, across policy models, concurrency, and relationship depth.

Under 15 ms P50 latency across RBAC and ReBAC, even under concurrent load.
About 3 ms added on average going from one to three relationship hops.
Under 50 ms P99 latency in most scenarios.
Near-linear throughput scaling: ten concurrent requests yield roughly ten times the throughput.

PDP latency in milliseconds by policy model, scenario, and number of concurrent requests
Scenario	Concurrency	Average	P50	P95	P99
RBACRole check	1	8.2 ms	7.2 ms	11.4 ms	20.1 ms
RBACRole check	10	7.8 ms	6.4 ms	14.2 ms	29.9 ms
ReBACDepth 1: folder → file	1	9.9 ms	9.1 ms	13.3 ms	17.8 ms
ReBACDepth 1: folder → file	10	11.3 ms	9.5 ms	20.1 ms	40.0 ms
ReBACDepth 2: drive → folder → file	10	13.3 ms	10.9 ms	26.1 ms	47.5 ms
ReBACDepth 3: drive → folder → file → comment	10	14.5 ms	12.0 ms	26.7 ms	48.6 ms

Measured in October 2025 on AWS us-east-2, over 10-minute runs per scenario. Latency is the PDP’s server-side processing time and does not include the network round trip; running Nexus beside your service keeps that hop on the same host. Full benchmark tables and methodology

Have a latency or throughput target? Bring it, and we will validate Nexus against it with you.

Book a demo Talk with our engineers

Classic PDP and Nexus, side by side

Aspect	Classic PDP	Nexus PDP
Where the authorization graph lives	In memory, inside OPA	On disk, in embedded SurrealDB
Memory as data grows	Grows with the data set	Bounded by a cache you configure
How changes arrive	Notification, then a fetch from Permit’s API	The change travels in a durable NATS message
Round trips per change	Two or more	One
Changes missed while offline	Reconnect, then re-fetch	Retained for that PDP, resumed in place
Calls to Permit’s API per decision or update	Per update	Never
Runtime	Rust API server, Python OPAL client, OPA	Rust binary, NATS leaf, OPA

Same APIs. Deploy it like any stateful service.

Nexus is wire-compatible with the classic PDP on the endpoints it implements, so existing SDK integrations keep working. It connects to the same Permit environment and enforces the same policies.

Check and bulk check
User permissions
Authorized users
Multi-tenancy
RBAC and ReBAC, including role derivation
AuthZEN evaluation, search, and discovery
Decision logs to Permit

To run it: one container per environment, a persistent volume, about 4 GiB of memory to start, probes on port 7001, and a 40 second termination grace period.

Talk with our engineers

docker

docker run -d --name nexus-pdp \
  -p 7766:7000 -p 7001:7001 \
  -e PDP_API_KEY="$PERMIT_API_KEY" \
  -v nexus-data:/var/lib/edge-pdp \
  --memory 4g \
  permitio/pdp-v3:<tag>

kubernetes (excerpt)

containers:
  - name: nexus-pdp
    image: permitio/pdp-v3:<tag>
    ports:
      - containerPort: 7000  # authorization API
      - containerPort: 7001  # health
    resources:
      requests:
        memory: 4Gi
    livenessProbe:
      httpGet: { path: /health, port: 7001 }
    readinessProbe:
      httpGet: { path: /health/ready, port: 7001 }
    volumeMounts:
      - name: nexus-data
        mountPath: /var/lib/edge-pdp
terminationGracePeriodSeconds: 40

Is Nexus the right PDP for you today?

Nexus is a new option, not a replacement. Both PDPs connect to the same environment, so you can run them side by side while you evaluate.

Choose Nexus for

Very large identity and relationship data sets
ReBAC-heavy models and deep role derivation
Decisions that must never depend on reaching Permit
Long disconnections without a full re-fetch

Stay on the classic PDP, for now, for

ABAC condition sets, user sets, or resource sets
Custom Rego bundles and policy as code
Local facts and read-your-own-writes
URL-based enforcement, Kong, or nginx
Prometheus metrics, or running without persistent storage

See the full feature comparison

Book a demo Talk with our engineers

Questions about Nexus

What is Permit Nexus PDP?

A ground-up rewrite of Permit’s policy decision point. It stores your authorization graph on disk in embedded SurrealDB, stays in sync over a durable NATS stream, and evaluates policy with OPA, with no network call in the decision path.

Is it generally available?

Nexus is in early access and is already running in production with an early customer. It is enabled per account; request access and we will scope it against your workload.

Does it replace the current PDP?

No. It is a new deployment option. The classic PDP remains fully supported, both connect to the same Permit environment and enforce the same policies, and you can run them side by side while you evaluate.

Do we need to change our code?

Not for the endpoints Nexus implements. It is wire-compatible with the classic PDP on check, bulk check, user permissions, authorized users, and the AuthZEN APIs, so existing SDK integrations keep working.

How fast is it?

Nexus runs the same evaluation core as Permit’s managed Cloud PDP, whose published benchmarks show P50 latency under 15 ms across RBAC and ReBAC under concurrent load, and P99 under 50 ms in most scenarios. Those figures are server-side processing time; running Nexus beside your service keeps the network hop local. If you have a specific target, bring it to the early access call and we will validate against it with you.

What does it take to run?

One container per Permit environment, a persistent volume for the database and event store, about 4 GiB of memory to start, health probes on port 7001, and a termination grace period of at least 40 seconds.

Bring your biggest authorization workload.

Tell us how many identities, relationships, and decisions you are planning for. We will scope Nexus against it and turn it on for your account.

Request access Book a demo Talk with our engineers

Read the docs

Permit Nexus PDP

The Classic PDP hit three ceilings. So we removed them.

Relationships need a graph, not a JSON document

Memory grew with every identity

Every update cost a round trip

Two paths that never block each other

Built for scale, designed to keep answering

Benchmarks, with the methodology

Classic PDP and Nexus, side by side

Same APIs. Deploy it like any stateful service.

Is Nexus the right PDP for you today?

Choose Nexus for

Stay on the classic PDP, for now, for

Questions about Nexus

Bring your biggest authorization workload.

Permit Nexus PDP

The Classic PDP hit three ceilings. So we removed them.

Relationships need a graph, not a JSON document

Memory grew with every identity

Every update cost a round trip

Two paths that never block each other

Built for scale, designed to keep answering

Benchmarks, with the methodology

Classic PDP and Nexus, side by side

Same APIs. Deploy it like any stateful service.

Is Nexus the right PDP for you today?

Choose Nexus for

Stay on the classic PDP, for now, for

Questions about Nexus

Bring your biggest authorization workload.