Nova Server Metrics Laravel Package

Technical Evaluation

Architecture fit: llaski/nova-server-metrics is a Laravel Nova dashboard card — a thin PHP metric provider plus a compiled Vue component registered through NovaServiceProvider::cards(). It has no database footprint (no migrations, no models), no queue workers, and no external service dependencies; it reads host-level resource data (CPU load, memory, disk) and renders it in the Nova UI. This makes it a good architectural fit only if the application already runs Laravel Nova, which is a paid first-party product with its own upgrade cadence. For any non-Nova Laravel application, this package is not applicable. Treat it as a developer-facing observability convenience for admin dashboards, not as a monitoring system of record.

Integration feasibility: Low. Installation is a single Composer require plus one card registration line and an asset publish. Realistic effort is a few hours including verification, not days.

Technical risk:

• Maintainer concentration: Single author, five merged PRs total, three tagged releases. Bus factor of one. No visible security policy, contributing guide, or CI matrix.
• Version coupling: This package's value is tightly bound to the Nova major version. The 1.2.0 change (Nova 4 support) is the release's entire substance, which means prior versions were effectively Nova 3-only. Consumers must treat Nova upgrades and this package's version as a coupled pair.
• Metric collection mechanism is unreviewed here: Whether metrics are gathered via /proc, PHP built-ins, or exec/shell_exec materially changes the deployment risk on locked-down hosts (many managed platforms disable process execution).
• Data exposure: Host resource metrics are visible to anyone with Nova dashboard access. Low sensitivity, but worth confirming it is not exposed to lower-privileged Nova roles.

Key questions for the maintainer/vendor:

1. Does 1.2.0 widen the Nova constraint (^3.0|^4.0) or replace it (^4.0 only)? This determines whether the upgrade is safe for a Nova 3 fleet.
2. Were the front-end assets rebuilt for Nova 4's Vite-based toolchain, and are the published assets committed and versioned?
3. How are metrics collected, and do they degrade gracefully when exec is disabled or /proc is unreadable?
4. Is there any caching, or does every dashboard load execute the collection routine?
5. Is multi-node/cluster metrics in scope, or is this strictly single-host?

Integration Approach

Stack fit: Laravel 8/9 with Nova 3 or Nova 4, PHP 7.3+. The package is a leaf dependency — nothing else in the stack depends on it, so adoption and removal are both cheap and reversible.

Migration path: composer require llaski/nova-server-metrics:^1.2. No migrations, no config file changes anticipated, no data backfill. The only structural change is in NovaServiceProvider. Because the release is scoped to Nova 4 support, the migration is effectively a compatibility unlock rather than a feature migration — teams already on Nova 4 were previously blocked at 1.1.0.

Compatibility: Verify the composer.json Nova constraint before upgrading. If 1.2.0 bumped to Nova 4 only, applications still on Nova 3 must stay pinned at 1.1.0 and will stop receiving updates — that is a fork-or-replace decision, not a routine upgrade. Also confirm the published JS/CSS assets match Nova 4's asset pipeline; a Nova 3-built bundle loaded into Nova 4 is the most likely silent failure.

Sequencing:

1. Resolve the Nova constraint question above before touching composer.json.
2. Upgrade in a local/dev environment; confirm the card renders and reported values match reality (free -m, df -h, uptime).
3. Test with exec disabled or as a low-privilege user to observe failure behavior.
4. Promote to staging with production-like host permissions.
5. Roll to production with the version pinned exactly (1.2.0, not ^1.2) to avoid surprise major-version drift.
6. Add a note to the runbook tying future Nova upgrades to a re-verification of this card.

Operational Impact

Maintenance: Low ongoing effort but non-trivial ownership risk. Expect to periodically patch or fork if the maintainer goes dormant — the code surface is small enough that forking is realistic (a few files, one Vue component). Budget a half-day per Nova major upgrade to re-verify.

Support: Community-only. GitHub issues with no SLA, no commercial backing, no documented support window. Escalation path for a production defect is "fix it ourselves." Plan accordingly; do not place this on a critical-path on-call dependency.

Scaling: Metrics are per-host and per-request. Cost scales with dashboard views, not with application traffic, so volume is negligible at typical admin usage. The risk is latency, not throughput: if collection shells out or hits the filesystem synchronously on every dashboard render, constrained containers may see slow admin pages. Recommend confirming caching behavior or wrapping the card behind a short TTL.

Failure modes:

• exec/shell_exec disabled by the host → card renders empty or errors; dashboard page may still load.
• Permission restrictions on /proc or disk_free_space() in containerized environments → partial or zeroed metrics displayed as if valid. Silent wrong data is the worst failure mode here — a dashboard showing 0% CPU is more dangerous than one showing an error.
• Nova major upgrade without a matching package upgrade → asset/render breakage on the dashboard only, not the application.
• Unpinned version resolving to a future release with a narrowed Nova constraint → Composer conflict during unrelated dependency updates.

Ramp-up: Minimal. Any Laravel developer can install, register, and validate this in under a day. The learning curve is in the operational verification (permissions, disabled functions, container behavior), not the code. Document the expected metric values and the collection mechanism in the runbook so the next on-call engineer can distinguish "host is idle" from "card is broken."