Authorization Laravel Package

Product Decisions This Supports

• Build vs. buy for RBAC. Authorization is a "buy" that costs one composer require plus php artisan migrate. The PM decision is whether role/permission infrastructure belongs on your roadmap at all; this package lets you strike it off and redirect that engineering capacity to differentiating features. For most apps, a hand-rolled RBAC layer is two to four weeks of work that is invisible to customers when it ships and embarrassing when it's wrong.
• Shipping an admin/role-management surface. The package supplies the data model (roles, permissions, user↔role, user↔permission) and the assignment verbs (grant, revoke, grantOnly, revokeAll). Everything above the data model — the settings screen, the permission matrix UX, the invite flow — is your product surface, and this package removes the backend prerequisite for it.
• Per-user permission overrides as a product lever. Because permissions can be attached directly to a user, not only via roles, you can support "give this one customer's admin access to the beta export" or a support-driven one-off grant without inventing a role. This is the difference between a role editor and an actual entitlement system, and it's the kind of thing enterprise buyers ask for in security review.
• Declarative role definitions. grantOnly() makes a role's permission set idempotent, which means your role catalog can live in seeders/config and be reconciled on deploy. That's a roadmap enabler for "standard roles ship with the product, custom roles are tenant-defined."
• Zero-friction adoption of Laravel's native authorization everywhere. Created permissions auto-register in the Gate, so @can, $this->authorize(), Gate::allows() and the two supplied middleware (permission:, role:) all work with no extra wiring. This directly reduces the cost of adding route-level and view-level guards later, without a second authorization idiom appearing in the codebase.
• Feature gating and staged rollout. Permission names are arbitrary strings (users.create, reports.export), so the same mechanism can back plan-based feature flags, gradual rollout of a new module to a subset of accounts, or internal-only tooling — without standing up a separate flag system.
• Performance is a product decision, and it's pre-made. Permissions are cached by default, flushed on permission writes, with configurable key and expiry. You are not choosing between "correct" and "fast" at launch; you're choosing a cache key name.

When to Consider This Package

Adopt when:

• You are on a supported Laravel version (releases track Laravel 9 through 13), and you want authorization that speaks Laravel's own vocabulary rather than a parallel API.
• Your model is genuinely roles + permissions, with occasional user-level exceptions. Not ABAC, not per-object policy logic — that's what Laravel Policies are for, and this package composes with them rather than replacing them.
• You want minimal lock-in. The implementation is trait-based and the relationships are native Eloquent; custom User/Role/Permission models are first-class, and migrations can be exported and owned. Swapping out later is a data migration, not a rewrite.
• You value a small dependency surface and are comfortable overriding internals when you need to.

Look elsewhere when:

• You need per-tenant role scoping. There is no teams/multi-tenancy mode. If each customer workspace has its own roles, you will be building the scoping layer yourself or adding a global scope — at which point evaluate spatie/laravel-permission (teams) first.
• You need an audit trail. Nothing here records who granted what, when, or why. If enterprise security questionnaires or SOC 2 are on your horizon, you must layer auditing on top — decide that now, not after the first customer asks.
• You need wildcards, permission inheritance, or dependency logic (e.g. users.*, or "edit implies view"). Name matching is exact.
• You want batteries included. No UI, no policy scaffolding, no super-admin bypass, no team management screens. Filament Shield or Nova permission tooling cover more of the last mile if you're on those stacks.
• You need strong ecosystem evidence. 179 stars and low dependent counts mean thin community support and a real bus-factor question. Treat maintenance cadence as a dependency risk: recent releases are Laravel-version compatibility bumps, which reads as "maintained, not actively developed." That's fine for a small, stable surface — but budget for the possibility that you own it.

Two implementation details that become PM-visible risks:

• Permission cache flushes on model writes, not on raw SQL or some seeder paths. Stale-permission bugs after a deploy will surface as a support ticket, so cache invalidation belongs in your release checklist.
• Tests require registering PermissionRegistrar in setUp(). If you gate PRs on test coverage, expect a small, recurring developer-experience tax until it's in the base TestCase.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed component that replaces a build we would otherwise schedule. It gives us the standard role-and-permission backend — roles, permissions, per-user overrides, caching, route guards — so the team can spend its time on the admin experience customers actually see, and on the features that differentiate us. It integrates with the framework's own authorization mechanism rather than introducing a parallel one, so it doesn't create a maintenance liability or a migration project if we ever outgrow it. The honest caveats: it does not include an audit log or multi-tenant role scoping, both of which have known solutions we'd add if enterprise requirements demand them.

For engineering: A thin, trait-based layer over Eloquent and the Gate. Install, migrate, add the Authorizable trait to User. Permissions auto-register as Gate abilities, so can(), authorize(), @can, and the bundled role:/permission: middleware all work immediately. Models and migrations are fully overridable; every behavior can be extended because the implementation is traits, not a service with a fixed API. The assignment API is grant/revoke/grantOnly/revokeAll on both roles and users, accepting names, models, arrays, or collections. Permission caching is on by default with configurable key and expiry, flushed on write — verify invalidation covers your seeding path. Tests need app(PermissionRegistrar::class)->register() in setUp(). Dependency is supported through Laravel 13 and actively version-tracked; keep the surface small and we retain an exit path at all times.