System Resources Laravel Package

Getting Started

• Install via Composer: composer require gijsg/system-resources. The package is a Nova card only, so no additional service provider registration is needed beyond Laravel's auto-discovery.
• Register the card in app/Providers/NovaServiceProvider.php inside cards():

public function cards()
{
    return [
        new \GijsGoudzwaard\SystemResources\SystemResources,
    ];
}

• Publish the config (if the package version you install exposes one) with php artisan vendor:publish --tag=system-resources-config, then inspect config/system-resources.php for thresholds and refresh settings.
• First use case: open /nova and confirm the card appears on the dashboard. It is a read-only monitoring widget — intended to give operators a quick CPU / memory / disk glance without leaving Nova, not a full APM tool.
• Look first at the package's src/ directory to confirm how metrics are gathered (likely shelling out to Linux utilities such as free, df, or reading /proc). That single detail determines whether it will work on your hosting environment.
• On v1.0.5 specifically: the release is a bug-fix patch only (issue #26, merged in #27). If you were hitting blank/incorrect card output on an older 1.0.x, try 1.0.5 before doing any deeper debugging.

Implementation Patterns

• Dashboard-only usage. The card is designed for the Nova dashboard (cards()), not as a resource tool or detail component. Keep it there; forcing it into resource screens adds little value because the data is server-wide, not per-model.
• Dedicated ops dashboard. Register the card on a custom Nova dashboard (e.g. a SystemDashboard class) alongside other infrastructure cards so production health lives in one view instead of cluttering the default dashboard.
• Threshold-driven display. Use the config (or, if absent, the card's built-in defaults) to tune what counts as warning vs. critical so colours match your team's tolerance — e.g. disk warning at 80%, critical at 90%.
• Pair with complementary Nova tooling. Combine with a logs card, a queue-monitor card, or Laravel Telescope/Horizon links so the resource card becomes the "is the box healthy?" entry point rather than the whole story.
• Environment scoping. Gate the card behind an environment check or an authorization callback so it only renders for admins and only in environments where the underlying shell commands are permitted (typically staging/production, not local Docker on macOS).
• Refresh expectations. Treat the card as snapshot-on-page-load. Nova cards re-render on dashboard load only; do not assume live auto-refresh unless you add a polling override.
• Pin the patch version. Given the low release cadence, pin gijsg/system-resources to an exact version (e.g. 1.0.5) in composer.json rather than a caret constraint, so an unattended composer update cannot silently move you onto a differently-behaving build.

Gotchas and Tips

• Maintenance risk (slightly reduced, not resolved). v1.0.5 is the first release in a long time and is a single bug-fix patch, not a modernisation pass. Treat the package as minimally maintained rather than actively developed; verify composer.json Nova/PHP constraints against your versions before installing, and be prepared to pin Nova or fork.
• Platform coupling. If metrics come from Linux commands (/proc, free, df), the card will show wrong values or fail on macOS/Windows or restricted containers. Verify by running the same commands inside your app container before trusting the output.
• Shell/exec permissions. exec/shell_exec are often disabled in hardened PHP-FPM or shared hosting. If the card renders empty, check disable_functions and your container's available binaries first — and confirm you are on v1.0.5, since rendering bugs were the subject of the recent fix.
• Disk path ambiguity. Disk usage depends on which mount point is queried; in containerised setups this can report the overlay filesystem rather than the volume you care about. Confirm the configured path.
• No caching by default. Gathered metrics may run on every dashboard load; on heavily trafficked admin panels consider caching the values or reducing card refresh frequency.
• Debugging. Reproduce the data-gathering step directly on the CLI (same user as PHP-FPM) so you can separate permission/binary issues from card/UI issues. Nova's nova:check and the browser console will surface Vue-level errors. When diffing behaviour against the changelog, note the release notes are terse ("Fixed issue #26 in #27") — read the merged PR diff on GitHub to know exactly what changed before upgrading.
• Extension points are limited. This is a small, single-purpose card; if you need historical graphs, alerting, or non-Linux support, plan to wrap or fork it rather than configure it. For long-term needs, evaluate Laravel Pulse or a dedicated server-monitoring package instead.