System Resources Laravel Package

Technical Evaluation

Architecture fit. gijsg/system-resources is a single-purpose Laravel Nova card: one PHP Card class that gathers host metrics at request time (load average, memory, disk) plus a Vue component that renders them as a dashboard tile. There is no persistence layer, no time-series store, no thresholding, and no alerting. It is an at-a-glance convenience widget, not monitoring. It fits only if the product requirement is literally "show a resource tile inside the Nova admin panel" — anything beyond that (history, multi-node rollup, alerting) is out of scope by design and should not be retrofitted onto it.

Integration feasibility. The hard dependency is Nova itself, which is commercial, closed-source, and versioned. The published release dates to May 2020, which places it in the Nova 3 era. Nova 4 (2022) moved card asset compilation to Vite and changed registration conventions; Nova 5 (2024) continued that drift. A card of this vintage is a likely break on modern Nova: the JS build pipeline, the Nova::script()/Nova::style() calls, and the component scaffolding all need verification before any commitment. Budget this as a fork, not an install.

Technical risk. The dominant risk is abandonment, not code quality. Twenty-nine stars, zero dependents, and no release in roughly six years means there is no community triage, no CVE response, and no compatibility patches. Secondary risks are environmental: metric collection typically relies on sys_getloadavg(), /proc reads, or shell calls, all of which behave differently on Linux vs. macOS vs. Windows, and differently again under cgroup v1 vs. v2 in containers. In a locked-down container the calls can fail silently and render zeros — a failure mode that looks like healthy headroom.

Key questions for the requesting team.

1. Which Nova major version is in production today, and is an upgrade scheduled?
2. Is the deployment bare-metal/VM or containerized/Kubernetes? (Container metrics are per-pod and will mislead.)
3. Is the actual requirement "dashboard tile" or "operational monitoring"? Only the former justifies this package.
4. Has the team evaluated Laravel Pulse, which ships first-party server-resource cards and is maintained?
5. Who owns the fork if we adopt it — and what is the budget for the next Nova major?

Integration Approach

Stack fit. Narrow: Laravel + Nova only. It is inert outside Nova and provides no API, no events, and no reusable service. Treat it as a UI artifact, not infrastructure.

Migration path. Two viable routes.

• Preferred: replace the requirement with Laravel Pulse, which is first-party, actively maintained, and already covers server resources and usage. This eliminates the fork entirely and is the lower-total-cost answer in almost every case.
• Fallback (if the team is pinned to an old Nova or wants this exact tile): vendor the repository into an internal namespace, modernize it to the installed Nova major (Vite build, current card registration), pin it in a private Composer registry, and take ownership of the diff. The code surface is small — a few files — so the fork is cheap in absolute terms; the cost is the recurring obligation.

Compatibility matrix to verify before work starts. Nova 3/4/5, PHP version, Linux vs. macOS, cgroup v1/v2, and the presence of exec/proc access in the runtime.

Sequencing.

1. Spike: install the published version against a staging Nova instance; record exactly what breaks.
2. Estimate the fork (usually hours, occasionally a day), plus recurring cost per Nova major.
3. Decision gate: fork vs. Pulse vs. drop the requirement.
4. If fork: rename namespace, publish privately, add CI to catch Nova upgrades.
5. Register the card, document it, and add a note that the tile is single-host and non-alerting.

Operational Impact

Maintenance. Effectively unmaintained upstream; any adoption transfers the maintenance burden to us. The code is small enough that upkeep is modest, but it recurs at every Nova upgrade — an obligation that outlives the original requester's tenure, which is precisely the kind of debt a TPM should price up front.

Support. No upstream support channel. Nova's own support will not cover third-party cards, so every incident routes to the internal owner. Document the fork owner and escalation path explicitly.

Scaling. Single-host by construction. On a fleet it produces N disconnected tiles, each reporting its own pod's limits — visually reassuring and operationally wrong. It does not aggregate, does not compare nodes, and cannot answer "which host is hot." For anything beyond a single-VM admin panel this is the wrong tool.

Failure modes.

• Restricted container: metrics unreadable → zeros or blanks, indistinguishable from healthy.
• Shell/proc permission errors surfaced silently or as exceptions inside the card.
• Load average misread on shared or burstable hosts.
• Stale compiled assets after a Nova upgrade → card renders empty with no console hint.
• False confidence: no alerting means a green tile does not mean the system is healthy; it means no one has looked at the right signal.

Ramp-up. Low for any Laravel developer — an hour to read the source. The hidden ramp is Nova version archaeology and confirming runtime metric access, which is where the real time goes.

Recommendation. Do not adopt as a dependency. Run the spike only to confirm the gap, then default to Laravel Pulse or an APM tool. Adopt this package only as a short-lived internal fork with a named owner, a documented Nova-version pin, and an explicit decision to revisit at the next Nova upgrade — and communicate to stakeholders that this tile is a convenience, not a monitoring capability.