Filament System Versions Laravel Package

Technical Evaluation

What it is (and isn't). cmsmaxinc/filament-system-versions is a thin presentation-layer add-on for Filament panels. It contributes dashboard widgets that render the running PHP/Laravel/Filament versions plus installed Composer dependency versions. It carries no domain logic, no persistence, no migrations, and no public API surface. That framing matters more than the score: this is a developer-convenience/observability widget, not infrastructure. Blast radius is small and reversible in minutes.

Architecture fit. Good fit for any Laravel application already running a Filament panel and wanting in-UI "what am I actually running?" visibility — useful for QA, staging, support triage, and on-call. Poor fit if you have no Filament panel (the dependency cost is disproportionate), or if your team already satisfies this need through your APM, health-check endpoint, Sentry release tags, or an existing php artisan about-style page. Before adopting, confirm this isn't duplicating a capability you already pay for.

Integration feasibility. Mechanically trivial: composer require, register the plugin in the target PanelProvider, optionally publish config/views. Realistic effort is well under a day including review. There is no data migration, no schema coupling, and no backfill.

Technical risk — the three things that actually matter:

1. How versions are sourced. If the package shells out to composer show / composer outdated at request time, you inherit process-execution requirements, container PATH assumptions, and latency. If it parses composer.lock / vendor/composer/installed.json, it's safe but can go stale relative to the deployed artifact. Confirm which, and whether it fails closed.
2. Information disclosure. A widget listing every installed package and exact version is a curated vulnerability roadmap for anyone who reaches that page. Authorization gating must be explicit and must default to deny. This is the single most important control in the assessment.
3. Rendering cost on the dashboard. Enumerating hundreds of Composer packages per page load can noticeably degrade a dashboard that people keep open all day. Caching (or build-time generation) is effectively a requirement, not a nice-to-have.

Broader risk signals. 14 stars and a single publisher (cmsmaxinc) mean weak adoption evidence and an unproven bus factor. The recent 2026-10-06 release is reassuring as a liveness signal but is one data point — check whether it tracks Filament major releases promptly, since Filament's own upgrade cadence is the most likely source of breakage. The overall score (~19.7/100) is consistent with a niche, low-visibility package; because the scope is deliberately narrow, that low score is a governance annoyance rather than a technical blocker, provided the exposure is gated.

Key questions to resolve before sign-off:

• Which Filament majors are supported, and is there a stated compatibility policy for Filament 4.x / future 5.x?
• Does the widget execute shell commands or read from disk? What happens when neither is available?
• Is there a built-in authorization gate, and can it be scoped per-panel (e.g. non-production only)?
• Is output cached, and is the cache TTL configurable?
• Does it expose versions in production by default, or must that be opted into?
• Test coverage and CI status; any open issues describing dashboard breakage?
• Does it leak absolute paths, environment names, or other metadata beyond package versions?

Integration Approach

Stack fit. Laravel 10/11/12 + PHP 8.2+ + an existing Filament panel. Zero interaction with your domain model, queues, storage, or auth schema. The only meaningful coupling is to the Filament version, which is also the most volatile part of the stack.

Pre-adoption spike (half a day, timeboxed). Install on a throwaway branch against a copy of your real composer.lock and confirm: (a) the widget renders without error, (b) it works in your actual runtime image (not just local — this is where missing composer binaries and read-only filesystems surface), (c) measured page-load delta on the dashboard, (d) default authorization behaviour. If any of these fail, the fallback is a 30-line custom widget reading installed.json — which is a genuinely competitive alternative given the package's size.

Migration path. None required. No migrations, no data, no config contract to inherit. Rollback is composer remove plus reverting the PanelProvider diff. Treat it as a leaf dependency with no downstream consumers.

Compatibility guardrails.

• Pin to a caret range and commit the lockfile; do not float.
• Add a smoke test asserting the widget class resolves, so a Filament upgrade that breaks it fails in CI rather than in the admin UI.
• Record the package in your dependency inventory with an explicit note that it is UI-only and non-critical, so a future Filament major upgrade can drop it without a migration plan.

Sequencing.

1. Spike on a branch; capture render time and authorization behaviour.
2. If adopted, ship gated and non-production-first: super-admin-only, and ideally restricted to staging/local panels via a config flag.
3. Promote to production only after confirming the gate with a non-admin account and verifying no sensitive metadata is rendered.
4. Establish a review trigger: re-evaluate at each Filament major upgrade, and if upstream goes >12 months without a release or a Filament compatibility commit.

Definition of done. Widget visible to the intended role only; verified invisible (403/absent, not merely hidden) to everyone else; dashboard p95 unchanged within an agreed budget; documented rollback in the PR description.

Operational Impact

Maintenance. Low steady-state cost: no runtime services, no scheduled jobs, no storage growth. Realistic effort is a version bump per Filament major plus occasional PHP-version hygiene. The non-obvious cost is governance — a 14-star, single-maintainer dependency still has to be tracked, CVE-monitored at the package level, and re-reviewed on each framework upgrade, and that bookkeeping can exceed the widget's value. Price that in honestly.

Support and ownership. Upstream support is effectively "best effort by one publisher." Assume no SLA and no guaranteed response to issues. Internal ownership must be assigned explicitly — ideally the platform/internal-tooling team that owns the Filament admin — with the understanding that if upstream stalls, the team forks or replaces it with an in-house widget. Because the surface is ~a few Blade views and a class, forking is cheap and should be the documented contingency rather than an escalation.

Scaling. Effectively free at any user count if version resolution is cached or static; without caching, cost scales with dashboard views × installed-package count. For a dashboard opened habitually and left on a wall display, uncached enumeration is a real and recurring tax. Cap it: cache with a TTL, or generate the payload at deploy time.

Failure modes and mitigations.

• Composer binary absent / process execution blocked → widget errors or shows empty. Mitigate by verifying in the production image pre-rollout; ensure the widget degrades gracefully rather than throwing and taking the dashboard down.
• Read-only or non-standard vendor path → blank/incorrect data. Verify against the deployed artifact layout.
• Filament major upgrade → widget class or view registration breaks, potentially failing the whole dashboard. Mitigate with the CI smoke test and staged rollouts.
• Uncached enumeration → dashboard latency regression, worst on the most-used page in the app.
• Authorization misconfiguration → dependency inventory exposed to lower-privileged staff or, worse, to any authenticated user. This is the highest-severity failure and the one to test adversarially, not just visually.
• Staleness → displayed versions diverge from what's actually running (cached or build-time data). Mitigate by labelling the data source and timestamp, and by never treating this widget as an audit source of truth.

Ramp-up. Near-zero for any Laravel/Filament developer: one composer require, one provider line, one permission check. Documentation burden is a short README note covering the authorization gate, the data source, caching, and the rollback command. No training, no runbooks, no on-call impact.

Recommendation. Adopt conditionally, as a gated, non-production-first convenience widget — and only if the authorization gate is verified or added. Given the low adoption signal and the small surface area, the in-house alternative (a single widget reading vendor/composer/installed.json behind an existing policy) is a legitimate and arguably stronger choice for teams already wary of single-maintainer dependencies. Either way, do not let it become the authoritative answer to "what's deployed" — that belongs to your build metadata and release tagging.