Nova System Info Card Laravel Package

Getting Started

1. Install via Composer into the same project as Nova:

   composer require coreproc/nova-system-info-card
   

2. Register the card in app/Providers/NovaServiceProvider.php. Cards on the dashboard go in the cards() method:

   use Coreproc\NovaSystemInfoCard\SystemInfoCard;
   
   public function cards()
   {
       return [
           new SystemInfoCard(),
       ];
   }
   

3. Publish assets/config if the package ships them (check the README — many Nova cards need this):

   php artisan vendor:publish --provider="Coreproc\NovaSystemInfoCard\CardServiceProvider" --tag=config
   php artisan nova:publish
   

4. Visit /nova and confirm the card renders on the dashboard. If nothing appears, check storage/logs/laravel.log and your browser console — a missing JS asset is the most common cause.

First use case: drop it on the dashboard of a staging/internal tool so you can eyeball PHP version, OS, disk space, and memory limits during support triage without SSH-ing into the box. It's a diagnostics card, not a monitoring solution — treat it as a quick "what am I looking at" panel.

Implementation Patterns

Dashboard-only registration (the intended use). Register in NovaServiceProvider::cards() rather than per-resource. There is little value in repeating this card on every resource index.

Gate it to admins. The card exposes infrastructure details, so wrap it in canSee():

(new SystemInfoCard())->canSee(function ($request) {
    return $request->user()?->hasRole('admin');
}),

Combine with ->onlyOnDashboard() if your Nova version supports it, so it never leaks onto resource pages.

Environment gating. A common pattern is to show it locally/staging but hide it on production:

$cards = [/* ... */];

if (! app()->isProduction()) {
    $cards[] = new SystemInfoCard();
}

Or the inverse: keep it in production but restricted to a super-admin role so you can debug incidents from a phone.

Layout control. Nova cards accept ->width(). System info is naturally wide; ->width('2/3') or ->width('full') often reads better alongside metrics cards:

(new SystemInfoCard())->width('1/2'),
(new SystemInfoCard())->width('1/2'), // e.g. a second instance if config allows subsets

Pairing with metrics cards. Use Nova's built-in metric cards (or a packages like nova-metrics/chart-js) beside this one — system info gives the what, metrics give the trend. The system card is a snapshot with no history, so don't try to make it do time-series.

Custom config. If the package publishes a config file (e.g. which fields to show, refresh interval), publish it into config/nova-system-info-card.php and adjust rather than editing vendor files. This is the supported extension point — fork only if you need new data points.

Support-runbook pattern. For internal admin panels it's useful to add it to a dedicated "Ops" dashboard alongside Horizon/queue status and a recent-deploy card. Nova supports multiple dashboards; register the card in the dashboard's cards() method instead.

Gotchas and Tips

Nova major-version compatibility. Nova 4 and Nova 5 changed the card/asset contracts. Check the package's composer.json for the laravel/nova constraint before installing; a card built for Nova 3 will not render on Nova 5 even if Composer happily resolves it. Pin the package version alongside your Nova version.

Missing assets after install/upgrade. If the card shell appears but is empty (or the console shows a 404 for a JS chunk), run php artisan nova:publish and clear caches (php artisan optimize:clear). On deploy pipelines, ensure nova:publish runs in the release step.

Disabled PHP functions on shared hosting. Data points like CPU count, uptime, or load average often rely on shell_exec, exec, proc_open, or php_uname. Hosts frequently disable these for security, so fields silently come back empty or null. If you see blanks, check disable_functions in php.ini — this is an environment limitation, not a package bug.

Container vs. host stats. Inside Docker/Kubernetes the card reports the container's view: its own memory limit, its own filesystem mount, the container's OS (often Debian/Alpine), not the underlying node. Don't use disk-free numbers here to make capacity decisions for a containerized app.

Disk figures and mount points. disk_free_space()/disk_total_space() are called against a path (usually base_path() or /). On hosts with separate data volumes, the number may reflect a filesystem unrelated to where your app actually writes. Verify the path the package checks.

Memory/limit values reflect the SAPI, not the machine. memory_limit, max_execution_time, and opcache settings are read from the PHP-FPM/CLI process serving the request. FPM workers and queue workers may have different php.ini files — the card only tells you the web process's view.

Authorization is your job. The package has no opinion about who can see it. Without canSee(), any Nova user sees your PHP version, OS, and disk layout — useful reconnaissance for an attacker. Always gate it, especially on internet-facing Nova installs.

Caching and staleness. Card data is fetched per page load; Nova's SPA won't auto-refresh it. If the package offers a refresh interval config, respect it, but don't expect live numbers — reload the dashboard when you need current figures. Browser caching of the compiled asset can also make changes "not appear" after config edits.

Card silently missing. Work through: is cards() the right method (not resources())? Is the service provider auto-discovered (check bootstrap/providers.php / config/app.php for older apps)? Does canSee() return false for your user? Is NOVA_LICENSE_KEY valid? Run composer dump-autoload after manual provider registration.

Extending. There's usually no event/hook surface on a diagnostic card. If you need extra rows (git SHA, deploy timestamp, env name), the cleanest route is a small custom card in nova-components/ that reads the same info, or a config-driven list of callables if the package supports it. Avoid editing vendor/ — it disappears on the next composer update.

Keep it out of CI smoke tests. Asserting on system info values in feature tests is brittle across runner environments. If you must test, assert the card class can be instantiated and authorized, not the values.