Entrust Laravel Package

Product Decisions This Supports

• Roadmap / platform currency: v9.0.0 (Laravel 10 & 11 support) answers the single question that matters for this dependency — can we keep shipping on a supported Laravel version without rewriting our authorization layer? That is a scheduling decision, not a feature decision.
• Build vs. buy: RBAC is commodity infrastructure. This release reinforces that we should never build roles/permissions in-house; the decision is only which off-the-shelf package carries it.
• Sustaining vs. modernizing: the major version bump is the forcing function for a "stay on Entrust as a bridge" vs. "migrate to spatie/laravel-permission" roadmap call. It buys time; it does not change Entrust's capability ceiling.
• Feature scoping: Entrust models permissions as role → permission only. There are no direct user-level permissions, no teams/multi-tenancy, no wildcard or cached permission resolution. Any roadmap item in those areas is a migration trigger, not a configuration change.
• Use cases it fits: internal admin panels, back-office tools, and simple gated feature sets where roles are few and stable. It does not fit customer-facing products with per-tenant role customization.

Open item to resolve before committing: the release notes are one line. A major version bump (8.1.0 → 9.0.0) implies breaking changes that are not documented here — most plausibly the Laravel 11 removal of app/Http/Kernel.php (middleware alias registration moving to bootstrap/app.php), plus a dropped minimum PHP/Laravel floor. Treat the changelog as incomplete until verified against the diff.

When to Consider This Package

Adopt when:

• You already have an Entrust-based schema (roles, permissions, role_user, permission_role) in production and want the smallest-diff path onto Laravel 10/11.
• Your authorization model is genuinely simple: a user has one or more roles, roles hold permissions, and checks happen at the route/controller/Blade level.
• You need @role / @permission / @ability Blade directives and role: / permission: middleware without writing them.
• You can accept a low-velocity, fork-maintained dependency and pin the version.

Look elsewhere when:

• Greenfield. There is no reason to start here. spatie/laravel-permission is the de facto standard: direct user permissions, teams, wildcard permissions, permission caching, and a large active community.
• You need multi-tenancy, per-tenant role editing, or an admin UI for role management.
• You want authorization expressed through Laravel's native Gates and Policies with roles as one input rather than the whole system.
• You need a guaranteed support window, security response process, or documented upgrade guides — none of which a single-maintainer fork can promise.
• Team familiarity is low and the cost of learning Entrust's legacy conventions equals the cost of migrating.

How to Pitch It (Stakeholders)

To executives: Entrust is our existing roles-and-permissions layer. It was effectively abandoned upstream years ago; this maintained fork has just shipped support for Laravel 10 and 11, which means we can stay on a supported framework version without an authorization rewrite this cycle. That's a real cost avoidance — a rewrite touches every gated route, screen, and permission check in the product. The recommendation is to take the upgrade as a bridge, and put a migration to the industry-standard package on next year's roadmap rather than this quarter's.

To engineering: treat v9.0.0 as breaking, not routine. Register a spike to: confirm the PHP/Laravel minimums, verify how middleware aliases are registered under Laravel 11's bootstrap/app.php, re-publish and diff config/migrations, and run the full authorization test suite against a pinned tag. The changelog is under-specified for a major release — do not merge on the version number alone. Also note this is a maintenance dependency, not a strategic one: it will not grow features, so avoid designing new capability on top of it. Any new work needing direct user permissions, teams, or cached permission checks should go through Spatie instead, and we should not run both.

Bottom line: adopt v9.0.0 to preserve framework currency for an existing Entrust codebase; do not adopt it for anything new.