Laravel Static Permission Laravel Package

Product Decisions This Supports

• RBAC model selection: config-as-code vs. database-backed roles. This package makes "permissions live in the repository" the default. That is the decision it most directly forces, and it is a product decision, not just a technical one — it determines whether an admin can change who can do what without a deploy.
• Build vs. buy for the authorization layer. For a product with a fixed role model (Owner / Admin / Member / Viewer, or a plan-tier matrix), this removes a build item from the backlog. It is a cheaper alternative to building a bespoke Gate/Policy layer, and a lighter alternative to spatie/laravel-permission, which brings migrations, tables, and cache invalidation you may not need.
• Time-to-market on internal tools and admin panels. Where roles are set by the engineering team and reviewed in PRs, this is a near-zero-cost adoption. It unblocks feature work that is otherwise gated on "we need permissions first."
• Compliance and auditability posture. If your buyers ask "who can access PII, and can you prove it?", permission diffs in pull requests are a genuinely strong answer — better than a database row someone edited in production six months ago. This supports a sales/security-questionnaire narrative for SOC 2, ISO 27001, and similar.
• Roadmap gating decision: customer-defined roles. Enterprise deals often arrive with "we need custom roles" or SCIM provisioning. If that is on your 12–18 month roadmap, adopting a static model now creates a migration you will pay for later. Make that a deliberate, documented bet rather than a drift.
• Multi-tenant shape. Works well when roles are identical across tenants. Does not work when each tenant defines its own role vocabulary. This package effectively answers the "are we multi-tenant-uniform or per-tenant-configurable?" question for you.
• Vendor/risk posture on the authorization layer itself. With zero dependents and negligible adoption, this is a single-maintainer, unproven dependency sitting on your most security-sensitive code path. That fact should be weighed as a product risk, not a footnote.

When to Consider This Package

Reasonable fit when:

• The role model is small and stable — roughly under a dozen roles and a bounded permission set — and changes ship with the product, not per customer.
• Authorization decisions are made by the engineering team and reviewed in code; no one in the business needs to edit roles in a UI.
• You want zero additional database surface: no role/permission/join tables, no seeding, no permission-cache flushing after deploys, simpler local and CI environments.
• You are building an internal tool, back office, or B2B app where tenant role structures are uniform.
• You value deterministic tests — asserting that a role grants a permission is a plain unit test with no fixtures.
• Compliance or security review values permissions being versioned, diffable, and code-reviewed.

Look elsewhere when:

• Anyone outside engineering must create or edit roles, or customers expect a "Roles & Permissions" settings screen.
• Enterprise buyers require custom roles, SCIM/IdP-driven group mapping, or per-tenant role vocabularies.
• You need features the mature alternative already ships: teams/scoped roles, wildcard and inherited permissions, Blade directives, middleware and route integration, and an established body of documentation and Stack Overflow answers.
• You already run spatie/laravel-permission. Migrating sideways to a low-adoption package is pure risk with negligible payoff.
• Your security review requires an actively maintained dependency with a track record, advisory history, and multiple maintainers — zero dependents and no visible adoption is a hard fail on most vendor-risk scorecards.
• Permission logic is likely to grow hierarchical or conditional (record-level, ownership-based); a static grants list gets awkward fast and you will want Policies anyway.

Regardless of fit: adopt it behind your own thin abstraction (AuthorizationService / an interface with can(), assignRole()) so the swap cost to a database-backed package stays a day, not a quarter.

How to Pitch It (Stakeholders)

For executives: Authorization is a gate on nearly every feature we ship, and the usual approach — database tables, an admin UI, migrations, and cache handling — is several weeks of work plus permanent operational overhead. This package lets us declare roles and permissions as code, which cuts that to days, removes a whole class of production incidents (stale permission caches, bad rows edited live), and gives us a strong answer to security questionnaires: every permission change is reviewed and recorded like any other code change. The trade-off is real but narrow — the business cannot change roles without a deploy, and it does not support per-customer custom roles. That is the right trade for our current fixed role model and worth it for the speed. Two caveats I would flag honestly: the package itself is very small, essentially single-maintainer, with no meaningful adoption, so it carries dependency risk; and it is not the right choice if we intend to sell custom roles or SCIM provisioning within the next year or two. My recommendation is to adopt it behind our own internal interface, which caps the downside — if it stalls or our needs outgrow it, swapping to the mainstream alternative is contained engineering work rather than a rewrite.

For engineering: You get permissions as a versioned artefact in the repo — no migrations, no role/permission tables, no cache to invalidate on deploy, no seed data drift between environments, and tests that assert grants without fixtures. It keeps authorization reviewable in the diff. Be clear-eyed on the costs: this is a low-adoption package with a bus factor of roughly one, so pin the version, wrap it in our own service boundary, and do not let vendor calls scatter through the codebase. If our model needs hierarchy, wildcards, record-level conditions, or runtime role editing, use Laravel Policies directly or reach for spatie/laravel-permission — do not force this package past its shape.