Laravel Mongo Permission Filament Laravel Package

Technical Evaluation

Architecture fit. This is a narrow, opinionated admin-surface package: it ships Filament resources that bind role/permission CRUD to MongoDB-backed Eloquent models via webrek/laravel-mongo-permission. It is not an authorization engine — it is a UI + wiring layer over an existing Mongo permission backend. That makes it a good fit only for teams already committed to (a) Filament as the admin panel and (b) MongoDB as the persistence layer for authorization data. For anyone on a relational default stack, the fit is effectively zero without a deliberate architectural decision to adopt Mongo for authz.

Integration feasibility. Straightforward within its target envelope: register the plugin on a panel, ensure the Mongo connection and the base permission package's migrations/collections exist, and the resources appear. The v1.0.0 test suite covering form persistence (including the permissions select), panel registration, and model binding is exactly the right smoke-level coverage for a package of this shape — it validates the contract most likely to break on Filament upgrades. The declared matrix (PHP 8.2/8.3/8.4 × Laravel 12, MongoDB service in CI) is a credible, modern support statement.

Technical risk. Several, mostly bounded:

• Version cliff. Laravel 12 / PHP 8.2+ only, hard requirement on webrek/laravel-mongo-permission ^1.5. Teams on Laravel 10/11 cannot adopt without an upgrade; teams on Laravel 12 cannot pin older majors. This is a greenfield-only package as of v1.0.0.
• Thin dependency surface with real coupling. The stated reason for the base-package bump — "legacy flat-data fix + cache invalidation" — signals that permission data shape and cache correctness live outside this package. The most dangerous behavior (stale permission caches) is delegated to a dependency whose fix is one minor version old. Treat the cache-invalidation path as unproven until independently verified.
• Static analysis depth. PHPStan level 5 is a floor, not a guarantee. It won't catch dynamic Filament/Livewire magic or mixed-type boundaries in Mongo document handling.
• Single-vendor concentration. Both the plugin and the underlying permission package appear to come from the same author (webrek). Bus-factor and long-term maintenance risk are correlated, not independent.
• Unstated Filament major. The release notes say "Filament panel" without a version constraint. Filament's major-version cadence is fast; an unpinned or loosely pinned Filament requirement is the most likely source of near-term breakage.

Key questions.

1. Which Filament major(s) are supported, and is that constraint explicit in composer.json?
2. Is there a documented upgrade/migration story from pre-1.0 tags, or is v1.0.0 a clean break?
3. What exactly does the ^1.5 cache-invalidation fix change, and is there a test proving stale-cache behavior is resolved?
4. Does the package own any schema/collection setup, or does it assume the base package's migrations have run?
5. What is the policy surface (policies/gates) the Filament resources rely on — can a non-super-admin be prevented from escalating their own roles?
6. Is there a supported path for multi-tenancy (panel tenancy in Filament) with Mongo-scoped roles?
7. What is the release cadence and support window commitment, if any?

Integration Approach

Stack fit. Adopt only if the target application is Laravel 12, PHP 8.2+, Filament-admin-driven, and already (or deliberately) using MongoDB for authorization data. If any of those is false, stop — the cost of forcing the fit exceeds the value of the resources this package provides.

Migration path. There is no incremental path from a pre-1.0 state documented; treat v1.0.0 as a fresh install. Plan for: install base permission package at ^1.5, verify the legacy flat-data fix addresses whatever shape your existing documents are in, run the base package's migration/backfill, then register the plugin. If you have existing role/permission documents in the legacy flat format, back up and rehearse the backfill in a non-production environment before touching production — the release notes imply a data-shape change but give no detail on reversibility.

Compatibility. Pin filament/filament explicitly and test the exact combination. Lock the base permission package to ^1.5 and re-run the full suite on any bump, including patch releases — cache-invalidation code is where subtle regressions hide. Confirm the MongoDB driver extension version in your runtime matches what CI exercises.

Sequencing.

1. Spike in a throwaway Laravel 12 + Filament + MongoDB environment; confirm resources render and the permissions select persists correctly.
2. Verify authorization boundaries — attempt privilege escalation through the UI with a low-privilege panel user.
3. Validate cache invalidation by mutating a role and asserting the effect is immediate and durable across processes (queue workers, Octane, multiple app servers).
4. Rehearse data backfill against a production-shaped dataset.
5. Roll out behind a feature flag / to a single panel before broad exposure.

Operational Impact

Maintenance. Low code volume, but two packages to track in lockstep, plus Filament's own major cadence. Budget for a review every Filament major and every base-package minor. Because the package is a thin binding layer, most breakage will arrive as "resource won't render / form field missing" after an upstream bump — noisy but easy to detect.

Support. Single-maintainer concentration across both packages is the dominant support risk. There is no evidence of a support policy, LTS commitment, or security disclosure process. For an authorization-adjacent surface, that is a governance gap worth escalating before adoption, not after.

Scaling. The package itself adds negligible runtime cost — Filament resource pages are admin-traffic-bound, not request-path. The scaling question belongs to MongoDB and to the permission cache. Watch for: permission cache stampedes on cold start, document growth if roles accumulate historical permissions, and query performance if policies resolve permissions per-request without caching. Confirm caching is actually enabled and shared across all PHP workers.

Failure modes.

• Stale permissions after a change — the classic and most damaging failure; a revoked role remains effective until cache TTL or invalidation. The ^1.5 bump claims to fix this; verify independently, including across queue workers and multi-node deployments.
• Silent UI-level privilege escalation — a panel user able to edit roles they shouldn't reach. Filament resource authorization is configuration, not default-secure; audit the policies.
• Mongo unavailability takes down the admin panel entirely; ensure the authz read path degrades predictably rather than fail-open.
• Filament major upgrade breaks resource registration with a hard error — detectable, not silent.
• Backfill data loss if legacy flat documents are transformed without a rollback path.

Ramp-up. Low for a Laravel/Filament-fluent engineer: hours to a working panel. The real ramp is conceptual, not syntactic — the team must understand both the Mongo document shape for permissions and the cache-invalidation lifecycle, or they will misdiagnose stale-permission bugs as application logic errors. Pair the rollout with a short internal write-up on the authz data model and cache behavior; that document will pay for itself the first time a permission change "doesn't take."