Filament System Versions Laravel Package

Product Decisions This Supports

• Build vs. buy for internal diagnostics. The capability is narrow — render PHP, Laravel, and Composer package versions in a Filament widget. A competent Laravel engineer can replicate it in an afternoon. Adopting this package is a decision to trade a small amount of dependency risk for zero build/maintenance cost. That trade is usually correct for internal-only surfaces and usually wrong if you need customization, branding, or multi-environment aggregation.
• Whether "system visibility" belongs in the product or the ops toolchain. This package assumes the answer is "in the admin panel." If your observability stack (Sentry, Datadog, Grafana) already surfaces runtime versions, the marginal value drops sharply. If your support team lacks SSH/terminal access, it rises.
• Support-tooling roadmap priority. A concrete, cheap win for reducing first-response time on "it's broken in production" tickets: the responder can confirm PHP/Laravel/dependency drift before asking the customer anything. Good candidate for a small, low-risk roadmap slot rather than a dedicated initiative.
• Upgrade-cadence hygiene. Once version drift is visible in a place people actually look, it becomes easier to justify dependency upgrade work and to argue for a maintenance budget line. This is a visibility enabler for that conversation, not a measurement system.
• Agency/multi-client delivery. For shops running several Filament admin panels, this is a repeatable, per-project addition that standardizes what "environment info" means across clients — useful for handover documentation and for post-incident reviews.
• What it explicitly does not decide. It is not a vulnerability scanner, not an SBOM generator, not a compliance artifact, and not a substitute for composer audit or Dependabot. Do not let it be scoped into a security or audit workstream; it will not satisfy that requirement.

When to Consider This Package

Adopt when most of these hold:

• You already run Filament and have at least one admin panel where a read-only "system info" card fits naturally.
• The audience is internal and trusted — support staff, ops, developers, or a small set of vetted client admins. Version disclosure is low-sensitivity but not zero-sensitivity; treat panel access as the control.
• You want the capability this sprint and are unwilling to spend engineering time on a custom widget.
• You are comfortable pinning an exact version and reviewing the diff before upgrading. At 14 stars and a single-maintainer profile, you are effectively self-insuring.
• The alternative is nothing — i.e., the realistic baseline is that nobody builds the custom version and support keeps asking for terminal access.

Look elsewhere when any of these hold:

• Security or compliance is the actual driver. Use composer audit, the Roave security-advisories dev dependency, or GitHub Dependabot. This package reports versions; it does not evaluate them. Conflating the two is the most likely way this adoption goes wrong.
• You need an SBOM or machine-readable output (CycloneDX, SPDX) for customer or regulatory requirements. Different tool class entirely.
• You need cross-environment or historical data — "which of our 40 apps is on EOL PHP?" A widget in each panel answers the wrong question; you want an inventory or platform-level scanner.
• You are not on Filament, or are on a version the package does not support. Check compatibility against your Filament major version before anything else; Filament's v3→v4 transition broke many plugins.
• Availability risk is unacceptable. Single maintainer, low star count, no visible commercial backing. If the panel is customer-facing or business-critical, fork it into your own codebase under MIT terms rather than taking a runtime dependency — you keep the code and lose only upstream updates you were unlikely to receive.
• You need PII-safe or redacted output. Dependency lists can leak internal package names and architecture. If the panel is ever exposed externally, verify what is rendered before shipping.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, MIT-licensed add-on for our admin panel that shows which PHP, Laravel, and library versions are actually running. It costs essentially nothing and shortens the back-and-forth at the start of support incidents, because whoever picks up the ticket can see the environment immediately instead of waiting on a terminal session. It is not a security tool and does not scan for vulnerabilities — it is a convenience that makes version drift visible to the people who triage problems. Risk is low, adoption cost is hours, and the main caveat is that it is a tiny open-source project, so we should pin the version and be prepared to maintain a fork ourselves.

For engineering: composer require plus registering the widgets on the panel; read-only, no migrations, no runtime hooks, no data leaves the app. MIT license means we can vendor or fork without legal review. Two asks: pin the exact version and review the diff on upgrade, and confirm the panel's authorization gate is correct before enabling it, since it discloses internal package names. If we find we need custom fields, multi-environment rollups, or JSON export, we should fork rather than wait on upstream.

For support/ops: after this ships, the answer to "what version are you on?" is one click, in the same place you already handle the ticket. Please still escalate anything that looks like a vulnerability to engineering — this widget tells you the version, it does not tell you whether the version is safe.