Filament Memory Tracker Laravel Package

Technical Evaluation

Architecture fit. The package is a Filament panel plugin: a Laravel service provider that registers a dashboard widget/page and (almost certainly) a queue event listener or scheduled sampler that persists memory samples to a database table for charting. Its architectural footprint is deliberately small — read-only observability, no request-path mutation, no external services. The catch is that the value lives entirely in the Filament UI. If the organization is not already standardized on Filament as its admin layer, the package has no usable surface and the evaluation ends there.

Integration feasibility. Mechanically trivial: composer require, publish config and migrations, register the plugin in the panel provider, run a worker, confirm samples land and the widget renders. Total effort is measured in hours, not days — provided version constraints line up. The package's last release is February 2023, which predates Filament v3 (mid-2023) and v4 (2025). Filament changed its plugin registration, widget, and charting contracts across those majors, so a modern install should be assumed broken until proven otherwise.

Technical risk. This is the dominant concern and it is concentrated in four places:

• Staleness/abandonment. Twenty-seven stars, score 0.225, one release more than two years ago. No active triage, no security patching, effectively a single-maintainer project. Treat it as a vendored snippet, not a dependency.
• Framework coupling. The package is pinned to a 2023-era Filament/Laravel/PHP matrix. Every future Filament major bump is a forced port of widget code we do not own.
• Platform assumptions. Memory introspection in PHP means reading /proc/<pid>/status or shelling out to ps. That is Linux-only, breaks or silently misreports under cgroup v2 without care, and is meaningless on Windows/macOS dev machines. Containerized workers may report container memory rather than worker memory, or nothing at all.
• Superseded value proposition. Laravel Pulse (first-party, late 2023) and Horizon already cover queue health, and Pulse covers memory. The differentiated capability here has narrowed to "memory trend chart inside a Filament panel," which is a small delta to rebuild.

Key questions.

1. Which Filament major and Laravel/PHP versions are we actually on, and does the package's composer.json constraint set admit them?
2. Do our queue workers run in containers with cgroups v2? Do we trust the sampler's readings there?
3. Is Pulse or Horizon already deployed? If so, what does this add that a custom Pulse card would not?
4. Do we need historical memory trends for capacity planning, or just current usage plus an alert threshold? The latter is far cheaper to build.
5. Who owns the fork when the upstream maintainer disappears? If the answer is "nobody," do not adopt.

Integration Approach

Stack fit. Laravel + Filament only. It requires a publishable migration for the samples table and no external service, which is the one genuinely attractive property: zero infrastructure to operate. If the team is not on Filament, the recommendation is to skip entirely rather than extract the sampler — the sampler is the easy half to reimplement.

Migration path. Evaluate on a short-lived branch, never on main: install, publish migrations/config, register the plugin, dispatch a batch of jobs against a real worker in the real container image, and verify both ingestion and widget rendering. If the current Filament major is incompatible — the likely outcome — the options are, in order of preference:

1. Replace with a Pulse card (or a thin internal listener writing to a memory_samples table plus a Livewire chart). Roughly one to two days, fully owned, no upstream risk.
2. Fork and port the widget to the current Filament API. Realistically one to two days for the UI plus whatever the sampler needs; ongoing cost is the port on every Filament major.
3. Pin Filament to a version the package supports. Reject this — the tail is wagging the dog.

Compatibility. Verify four constraints before writing any code: PHP version, Laravel version, Filament major, and queue driver. Job events (JobProcessing/JobProcessed/JobFailed) are driver-agnostic, but worker process introspection is not — it assumes a specific process topology and will behave differently under Horizon supervisors, queue:work with multiple --tries, or SQS-driven workers.

Sequencing.

1. Confirm the Filament version and the existing Pulse/Horizon footprint — this may close the evaluation outright.
2. Timebox a half-day PoC in the target container image with representative jobs.
3. Compare fork cost against a Pulse-card build using the PoC results.
4. If adopted, record an ADR naming an internal owner and add the package to dependency/patch monitoring.
5. Enable on one non-critical queue before any broader rollout.

Operational Impact

Maintenance. Effectively unmaintained upstream. Either take internal ownership (fork, or vendor the source directly into the repo under the MIT terms) or accept that it will rot silently. The recurring cost is not patching — it is the forced port every time Filament ships a major.

Support. No vendor, no SLA, community-only via issues on a 27-star repository. The escalation path is "we fix it," which requires an engineer comfortable with both Filament internals and Laravel queue worker lifecycle. That is a real, if modest, staffing constraint.

Scaling. Every sample is a database write. With many workers running short jobs, sample volume grows quickly; without a retention/pruning policy and proper indexes, the samples table becomes the largest thing in the database and the widget queries get slow. Chart queries must be time-bounded and the dashboard should not be left open on a wall display hammering the table. There is no obvious multi-tenancy or per-queue scoping beyond Filament's own panel auth.

Failure modes. Ranked by severity:

• Panel boot failure from a Filament version mismatch — worst case, since it takes down the admin UI, not just the widget.
• Unhandled exception in the sampler inside a queue event listener — if not wrapped in try/catch, observability code can fail jobs. Verify this before enabling anywhere that matters.
• Missing migration — widget returns 500 on first render.
• Silent misreporting under cgroup v2 or a locked-down /proc — worse than no data, because it drives wrong capacity decisions.
• Unbounded table growth from absent pruning.

Ramp-up. Technically shallow — a small package that reads in an hour. The actual cost is domain knowledge: container memory semantics, cgroup behavior, and queue worker lifecycle. Plan roughly half a day to evaluate, one to three days to integrate or port, and a few hours per Filament major thereafter.

Verdict. Do not adopt as-is. A 0.225 score, a two-year-old release, single-maintainer risk, and functional overlap with first-party Pulse make the risk-adjusted cost higher than the build. If memory trend visibility inside Filament is a genuine requirement, spend the one to two days building a thin Pulse card or an internal listener-plus-chart, and own it outright. Forking is defensible only if the existing widget UX is a hard requirement for stakeholders — and even then, budget for the port on every Filament upgrade.