Defender Laravel Package

Product Decisions This Supports

• Build vs. buy for authorization. Roles & permissions is commodity infrastructure, not a differentiator. Defender gives you a database-backed RBAC layer (roles, permissions, assignment, caching, middleware, Blade/Gate integration) with an MIT license, so the decision moves from "design a permission schema" to "integrate and configure," typically a sprint-scale task instead of a multi-sprint build.
• Feature scoping for admin and multi-persona products. Use it to gate admin panels, internal tooling, marketplace seller/buyer/support roles, and delegated administration (e.g., "account owner can invite teammates and assign roles") without inventing a permission model per feature.
• Packaging and plan entitlements. Permission strings double as capability tokens (reports.export, users.*). That lets you express plan-tier gating and feature flags in the same primitive as staff authorization, reducing the number of entitlement systems in the stack.
• Roadmap and upgrade risk as a first-class input. v0.12.0 adds Laravel 9 support — the first framework-compatibility movement in a long while. That's a positive signal (the maintainer is still tracking releases) but it lands roughly three majors behind current Laravel, so the ceiling on your own upgrade path remains the deciding factor. Budget this into the roadmap conversation now, not after the next major upgrade.
• Multi-surface authentication. Useful where you have distinct guards (e.g., internal staff vs. customer portal) and want the same authorization vocabulary across both.
• Auditability and support workflows. Role assignment events and a relational model make it feasible to answer "who could do this, and when did that change?" — a prerequisite for support impersonation, permission-scoped break-glass access, and light compliance asks.
• Portfolio triage. The low opportunity score (~32.5) and thin ecosystem (438 stars, few/no dependents, sparse release history) still argue against a bespoke evaluation or fork investment. The new release slightly improves the maintenance signal, but this remains an opportunistic swap-in, not a strategic bet.

When to Consider This Package

Consider adoption when:

• You are on Laravel 9 — now explicitly supported as of v0.12.0 — or an earlier version the package still covers; verify against your composer.json before committing, and confirm the constraint actually admits your locked framework version rather than assuming from release notes.
• You have no near-term major upgrade on the roadmap. Laravel 9 support arriving late is the pattern to plan around: assume a similar lag before 10/11 is supported, if ever.
• You want a straightforward, DB-driven role/permission model with wildcard permissions, cached checks, route middleware, and Gate/Blade compatibility — and you do not need policy-level conditional logic.
• You need multiple authentication providers sharing one authorization vocabulary.
• Your team is small and would rather own a thin integration than a permission subsystem; MIT licensing means forking or patching is legally and practically cheap if you hit a gap.
• Authorization is not customer-facing-critical (internal tools, back-office, early-stage product) where an intermittent maintenance cadence is tolerable with monitoring.

Look elsewhere when:

• You are on Laravel 10/11/12 or PHP 8.2+. v0.12.0 closed the Laravel 9 gap only; everything above that is still unverified. On a security-sensitive surface, spatie/laravel-permission is the actively maintained default and the safer "nobody gets fired" choice.
• Your roadmap has a framework major upgrade inside the next 12 months. This release confirms the package can catch up, not that it will catch up on your timeline.
• You need tenant/team-scoped roles (per-workspace roles in a multi-tenant SaaS). Confirm scoping support explicitly before committing — this is the most common reason RBAC integrations get rewritten.
• You need resource- and attribute-level authorization (ownership, state, field-level, ABAC-style conditions). Use native Gates/Policies, possibly with a rules layer, rather than forcing it into roles.
• You require enterprise identity integration: SSO group-to-role sync, SCIM provisioning, immutable audit trails, or compliance evidence.
• You depend on ecosystem surface area — Nova/Filament/Livewire admin generators, community packages, Stack Overflow answers. Star count and dependent count are leading indicators of how much support you'll get at 2 a.m.
• You need a vendor SLA or long-term support commitment; a solo-maintainer package with an irregular release cadence cannot provide it.

How to Pitch It (Stakeholders)

One-liner: Defender is a free, MIT-licensed Laravel package that gives us roles and permissions out of the box, so we ship access control in days rather than building and maintaining it ourselves.

For executives: Authorization is required for every product surface we plan to ship — admin tools, team management, plan gating. Buying (integrating) rather than building removes an estimated multi-sprint build and an ongoing maintenance line item, at zero license cost. On dependency risk: the package just shipped its first release in a long stretch, adding Laravel 9 support, so it is maintained rather than abandoned — but it tracks the framework slowly and sits several majors behind. That makes it a fit for current-version work and internal surfaces, not a long-term platform bet.

For engineering: It is a conventional relational RBAC model — roles, permissions, assignment, cached lookups, route middleware, and Gate/Blade integration, plus wildcard permissions and multi-guard support. v0.12.0 adds Laravel 9 compatibility, which removes the most immediate blocker for a Laravel 9 codebase; confirm the composer constraint against our lockfile rather than trusting the changelog. Clean integration, no exotic dependencies, MIT so we can patch or fork.

Recommended decision — adopt conditionally, with a hedge:

1. Put it behind an internal interface (an AuthorizationService contract or a thin domain wrapper) and consume only that interface from product code. Swapping to spatie/laravel-permission later then becomes an adapter change, not a refactor.
2. Pin and monitor. Lock to v0.12.0, watch for Laravel 10+ and PHP 8.2 compatibility, and set a review trigger on the next framework major. Add a one-line fallback plan to the risk register.
3. Pilot first. Ship it on an internal or back-office surface, not a customer-facing entitlement boundary, and confirm tenant-scoping behavior before any multi-tenant use.
4. Re-evaluate at the next upgrade. The v0.12.0 release buys credibility but not a commitment to our timeline. If Laravel 10/11 support hasn't landed when we need it, migrate to the maintained alternative while the wrapper keeps the blast radius small.