Question 1

How is PermX different from CASL?

Accepted Answer

CASL reasons about abilities against subjects. PermX locks every permission to a fixed module.resource:field.action.scope coordinate, and ships those same coordinates to the UI as route / component / field ids. You get typed autocomplete, single-source renames, and no policy language on top.

Question 2

Do I need MongoDB or Express to use PermX?

Accepted Answer

No. The core is storage- and framework-agnostic. Mongoose and Express ship as optional peers — the engine runs anywhere you can call a function. Bring Postgres, Prisma, Hono, Fastify, Bun.serve — implement one PermXDataProvider and you are wired.

Question 3

What about row-level or ABAC-style rules?

Accepted Answer

Scope covers the common cases: all, own, team, department, self. For arbitrary predicates, wrap the authorize call in your resolver — PermX stays out of your query builder.

Question 4

Is it safe to put permissions in a database?

Accepted Answer

Yes — that is the point. Roles, role-permissions, and UI mappings live in your own DB behind your own auth. PermX caches the graph per tenant, invalidates on write, and bounds DFS to depth 10 so a malformed inheritance tree cannot pin the event loop.

Question 5

What is the migration path from flat-RBAC?

Accepted Answer

Start incremental. Map your existing permission strings to coordinates one module at a time with definePermissions(). PermX will coexist with flat checks until you are ready to flip the switch. Most teams migrate over two sprints.

Question 6

Why does PermX have zero runtime dependencies?

Accepted Answer

Supply-chain risk and bundle weight. Auth is in your hot path on every request and every render — it should not pull a transitive tree you have not audited. Core is hand-written TypeScript with no imports outside the standard library.

PermX compared.

Head-to-head comparisons

PermX vs CASL

PermX vs Casbin

PermX vs Permit.io

Not sure which to pick?