Weave Code
System Information Bundle Laravel Package
kmi/system-information-bundle
kmi/system-information-bundle is a Symfony bundle that collects and exposes system information, making environment and runtime details available for diagnostics, monitoring, and admin dashboards.
Simple sonata admin bundle for system information
Frequently asked questions about System Information Bundle
- Is kmi/system-information-bundle a Laravel package?
- No. It is a Symfony bundle built for Sonata Admin, registering through Symfony's kernel and bundle registry and rendering a dashboard block with Sonata's Twig templates. Laravel has no bundle registry, no Sonata Admin and no Doctrine admin layer, so there is no architectural seam where it drops in. The only transferable artifact for a Laravel codebase is the idea and the field list, not the code as a dependency.
- Can I install kmi/system-information-bundle in a Laravel 10 or 11 app with Composer?
- In practice, no. Archived Sonata bundles of this vintage pin PHP 5.6 or 7.x and Symfony 2.8 or 3.x constraints, while Laravel 10 and 11 require PHP 8.1 and above, so Composer will refuse to resolve the dependency set. Forcing it with ignore-platform-reqs drags in sonata-project/admin-bundle, block-bundle, Twig and Doctrine, hundreds of transitive packages that collide with Laravel's own pinned Symfony components. There is also no Laravel service provider and no package auto-discovery, so nothing would wire up even if resolution succeeded.
- What system information does the bundle actually collect?
- It gathers PHP, operating system and server details in one place, including the PHP version, OS name, loaded extensions and runtime configuration values. It also reports memory usage and disk space metrics so you can see headroom at a glance. The layout is exposed as a Sonata Admin dashboard block, which is also the best place to read the source when enumerating the exact fields it surfaces.
- How do I install and register the bundle in a Symfony application with Sonata Admin?
- You install it with composer require kmi/system-information-bundle, then register the bundle in your kernel or bundles.php and make sure Sonata Admin and Sonata Block bundles are already configured. The bundle contributes a dashboard block via its DI extension and Sonata Admin subclass, so it appears wherever your Sonata dashboard is rendered. Treat the repository as a reference specification rather than a long-term dependency, because it is archived and receives no upstream fixes.
- What is the best Laravel alternative for a system information panel?
- The simplest native option is php artisan about plus a small custom Artisan command that prints PHP version, loaded extensions, disk free space and app version. If you want it in an admin UI, build a Blade component or a Filament, Nova or Backpack widget that reads the same values and renders them behind your existing admin authorization. That gives you the same panel in roughly one to two developer-days without pulling in Symfony, Sonata or Doctrine.
- Is the package still maintained, and does it receive security patches?
- The repository is archived, so there are no security patches, no PHP 8 compatibility fixes and no framework version tracking. It has zero stars and zero dependents, meaning there is no community corpus of fixes to lean on either. Using it in an admin panel is a standing information-disclosure risk with no upstream to remediate it, so the due-diligence signal is a clean reject.
- How much effort is it to rebuild this panel natively in Laravel?
- Reimplementing the panel is on the order of one to two developer-days, whereas forcing the Symfony bundle into Laravel is unbounded effort with negative residual value. Read the bundle's DI extension and its Sonata Admin subclass to enumerate the exact fields, then map each one to a Laravel-native source. Implement it as a service provider plus a Blade component or admin widget, and retire the repository from any dependency manifest.
- Is it safe to display PHP config, server paths and disk details in an admin dashboard?
- The bundle touches sensitive surface such as server paths, PHP configuration, disk and memory figures and environment values, so exposing it carelessly is an information-disclosure risk. Because the renderer is unmaintained, any leak or rendering flaw has no upstream fix. In a Laravel rebuild, wrap the panel behind your existing admin middleware and a dedicated gate, and decide deliberately which fields should be permission-gated or excluded for privacy and compliance reasons.
- What is the difference between this system information panel, php artisan about and Laravel Pulse?
- This bundle and php artisan about answer the question of what is installed on the host: PHP version, extensions, OS, disk headroom, memory and environment name. Laravel Pulse and health-check packages answer what is happening on the host right now, with request, queue and cache telemetry. They are different tools with different owners, so clarify which decision your panel actually informs before choosing either.
- How do I map the bundle's metrics to Laravel-native data sources?
- Map each displayed field to an equivalent Laravel source: PHP_VERSION and get_loaded_extensions() for runtime details, disk_free_space() for storage, config('app.version') for the version string, and config values for the database, queue and cache drivers. Useful additions are the last deploy SHA and the last migration timestamp, which Laravel can read directly. Rendering those values through a Blade component or a Filament or Nova widget reproduces the original layout without any Sonata dependency.
Weaver
How can I help you explore Laravel packages today?