Brandenburg Laravel Package

Technical Evaluation

Architecture fit Brandenburg is not an authorization engine; it is a Nova tool that provides CRUD screens for the roles and permissions tables already owned by spatie/laravel-permission. That is architecturally the right shape: it adds no new persistence model, no parallel policy layer, and no runtime dependency in the request path. All actual enforcement stays with Spatie and Laravel's Gate/Policy machinery, so adopting or later removing Brandenburg should not change authorization semantics. The corollary is that it is only viable where both Laravel Nova and Spatie Permission are already strategic — it delivers zero value to a non-Nova application, and marginal value to a Nova app that manages roles by hand-rolled resources.

Integration feasibility Integration is a Composer require, a tool registration in NovaServiceProvider, and (typically) an asset publish step. The real feasibility question is the compatibility envelope, and the evidence is poor: last release 2020-09-18, 94 stars, no active maintenance signal. A 2020 Nova tool was built against Nova 3's frontend stack (Vue 2 / Nova's mix pipeline); Nova 4 moved to Vue 3 + Inertia and changed the tool scaffolding, so a drop-in on Nova 4+ is unlikely without a port. The same applies to Spatie's v5/v6 (permission caching changes, teams semantics) and PHP 8.2/8.3.

Technical risk

• Staleness (high): ~4+ years without a release means no PHP 8.3, Laravel 10/11, or Nova 4/5 validation, and no security triage. Composer constraints will likely pin the host application and block framework upgrades — an organizational cost, not just a technical one.
• Privilege-escalation surface (high): a UI that grants permissions is an attack surface. Must confirm the tool respects Nova's authorizationGate/canSee, and whether an operator can assign permissions or roles they do not themselves hold (lateral escalation).
• No audit trail (medium): permission changes are security-relevant events; expect to add logging yourself.
• Low bus factor / thin community (medium): few users, so upstream fixes will not arrive; MIT permits forking, but the fork becomes yours.

Key questions

1. Which Nova major versions are supported, and does the tool ship compiled assets or require a JS build?
2. Which spatie/laravel-permission versions, and is the teams feature, multi-guard, or wildcard permissions supported?
3. Does any write path call php artisan permission:cache-reset or the equivalent, and is Spatie's cache TTL configured?
4. Is tool access gated, and is the assignment UI constrained by the operator's own permissions?
5. Are role/permission deletions guarded against orphaning users and dependent policies?

Integration Approach

Stack fit Requires: Laravel (Nova-compatible version), Laravel Nova (paid license, per-site), spatie/laravel-permission. Fits cleanly where Nova is the internal admin surface and Spatie is the single source of truth for roles/permissions. Misfits: API-only products with no Nova install, multi-tenant apps using custom tenancy scoping, or teams of admins who should not be editing authorization at all.

Compatibility Build an explicit matrix and prove it with a timeboxed spike (1–2 days) on the real stack: PHP 8.1–8.3 × Laravel 9/10/11 × Nova 4/5 × spatie v5/v6. Expect failure on Nova ≥4. Treat the spike as a go/no-go gate rather than a discovery exercise.

Migration path

• If on Nova 3 + Spatie 4: near drop-in; publish config, register tool, verify guard names and cache reset.
• If on Nova 4/5: fork and port the tool's Vue components (real but bounded work), or replace it. The replacement is credible and cheap: two Nova resources (Role, Permission) with BelongsToMany fields, plus a roles() field on the User resource, is roughly 1–2 days and eliminates the dependency entirely. Given 94 stars and a 2020 release, replacement is often the better TCO decision.
• Data path: no schema migration is needed beyond Spatie's own; rollback is removing the tool registration.

Sequencing

1. Compatibility spike in a branch; record pass/fail per matrix cell.
2. Authorization review of the tool itself (who can see/edit; escalation constraints).
3. Decide fork vs. custom resources vs. adopt.
4. Add audit logging and verify cache-invalidation behavior.
5. Deploy behind a feature flag to a staging admin, then to production admins only.
6. Document the admin runbook and name an internal owner.

Operational Impact

Maintenance The decisive cost. Assume you own the code: pinning to an old Nova prevents upgrading the whole admin panel, and every future Laravel/Nova bump becomes a manual re-validation. Budget a named maintainer and a recurring "does it still install?" check. If the team cannot absorb that, do not adopt.

Support No vendor support; MIT means self-help only. Issues will be answered by reading source. The upside is a small, readable codebase — a competent Laravel dev can understand it in an afternoon, which caps the downside.

Scaling Write volume is inherently low (roles/permissions change rarely), so database scaling is a non-issue. The genuine scaling concerns are: (a) Spatie's permission cache going stale after edits — the highest-severity failure mode, producing silently incorrect authorization; (b) UI usability and Nova index query counts when role/permission counts reach the hundreds; (c) cache-reset cost in large user bases if writes trigger broad invalidation.

Failure modes

• Silent breakage on Nova or Laravel upgrade (class not found, tool fails to render).
• Stale permission cache after a change — users keep old access, or lose new access.
• Guard mismatch (web vs api) producing assignments that never take effect.
• Teams feature unsupported → cross-tenant permission leakage.
• Privilege escalation via insufficient tool gating or unconstrained assignment.
• Unintended cascade on role deletion, leaving policies referencing missing roles.

Ramp-up Low for developers already fluent in Nova (a few hours: install, register, publish, verify guard names). Moderate for non-technical admins, who need a documented runbook covering role naming conventions, the difference between roles and direct permissions, and the "changes take effect after cache reset" caveat. Add a short internal doc and an explicit "who may grant what" policy before opening the tool to anyone beyond the platform team.

Recommendation: adopt only if pinned to Nova 3 with a named owner and an audit-log wrapper; otherwise fork-and-port or replace with purpose-built Nova resources. The package's design is sound; its release cadence is the disqualifying risk.