System Info Laravel Package

Product Decisions This Supports

• Support operations and MTTR reduction. The bundle exposes the deployed environment (versions, PHP/runtime, configuration, service life data) inside the admin UI. That turns "what are you actually running?" into a self-serve answer instead of a multi-round-trip support thread — a direct lever on ticket resolution time and escalation cost.
• Support-tier and SLA packaging. Because it exists to serve support engineers, it is a natural anchor for defining what a paid support plan includes: standardized environment collection at ticket intake, a required "System Info screenshot/export" in the support template, and triage checklists built on the fields it surfaces.
• Release and lifecycle governance. Release notes reference service-life metadata and version-detection fixes. It supports the roadmap decision of which Ibexa DXP versions we support, and how we tell customers they're out of support — an in-product signal rather than an email campaign.
• Build vs. buy: buy (or rather, inherit). This ships as part of the Ibexa DXP bundle set under the Ibexa BUL (or GPL v2). Building an equivalent environment-diagnostics panel ourselves would be duplicative and would drift from upstream. The decision is adopt and configure, not build — the only real build work is wiring its output into our support and monitoring workflows.
• Upgrade and migration planning. The v5.0.0 line carries PHP 8.3 minimums and Symfony 6/7 upgrades. That constrains our platform roadmap: any customer environment on older PHP/Symfony becomes an upgrade project with a known, vendor-signposted path.
• Pre-sales and onboarding demos. A read-only "here is your environment" screen is a cheap, credible artifact for implementation kickoffs and health checks; it also gives professional-services a repeatable environment-audit deliverable.
• Use cases it does not cover, which should be owned elsewhere on the roadmap: application performance monitoring, uptime alerting, log aggregation, and health-check endpoints for load balancers. Do not let stakeholders assume "System Info" equals "observability."

When to Consider This Package

Consider it when all of the following hold:

• You are running Ibexa DXP (it is a bundle within that product; installing it standalone is explicitly not the supported path).
• You have a support or managed-services function — internal or customer-facing — that needs to know a deployment's runtime and configuration without shell access to the host.
• You want vendor-aligned diagnostics rather than a bespoke internal tool, and you accept the Ibexa BUL terms that come with a DXP subscription.
• Your platform baseline can absorb the PHP 8.3 / Symfony 6–7 requirements of the current 5.x line.

Look elsewhere — and treat this as a fit-gap finding, not an adoption candidate — when:

• You are on Laravel. This is a Symfony bundle built around Ibexa's kernel, admin UI, and Twig components. There is no Laravel integration path; the equivalent need is served by Laravel Telescope, Pulse, Horizon, and php artisan about. Flag the mismatch explicitly in any evaluation doc.
• You need actual observability. No metrics export, alerting, tracing, or SLO reporting. Pair with a real APM/monitoring stack.
• You are not an Ibexa customer. Licensing and the "install Ibexa DXP" instruction make it a non-starter; the GPL v2 branch carries copyleft obligations that need legal review before any standalone use.
• You need community momentum as a signal. 3 stars, 0 dependents, and a long tail of "no significant changes" releases mean you must not treat GitHub activity here as evidence of ecosystem health. The correct signal is the Ibexa DXP release train, not this repo.
• You need it as a stable public API. Recent releases are internal alignment work (type hints, Twig component refactors, schema renames). Consume it as an admin feature, not a programmatic contract.

How to Pitch It (Stakeholders)

For executives (one paragraph). Ibexa System Info is a small, no-additional-cost component that already ships with our Ibexa DXP subscription. It gives support and administrators a built-in view of the deployed environment, which shortens diagnostic back-and-forth and reduces time-to-resolution on environment-related tickets. The recommendation is not to invest engineering effort here — it is to use it deliberately: standardize it as the first artifact in every support intake, and use its version and service-life data to drive proactive upgrade conversations. The risk is low; the value is in process adoption, not code.

For engineering. This is an upstream Ibexa bundle, not something we extend or fork. Two implications: (1) our supported-platform baseline is now bounded by its requirements — PHP 8.3 and Symfony 6/7 in the 5.x line — so plan upgrades accordingly; (2) it is a diagnostics surface, not a telemetry pipeline. Keep our monitoring, logging, and alerting investments separate and do not let the existence of this screen deprioritize them. Where we do invest is the thin glue: capturing its output into support tickets, and mapping its version fields to our lifecycle policy. Note for anyone reusing this assessment: the package is Symfony/Ibexa-specific and offers no Laravel integration — our Laravel services should use the Laravel-native equivalents.