Filament User Activity Laravel Package

Technical Evaluation

Architecture fit. This is a Filament panel plugin, so fit is conditional on the application already running the TALL stack (Laravel + Livewire + Alpine + Tailwind) with Filament as its admin surface. It layers two capabilities — an audit-style activity trail and a "currently online" presence indicator — onto the existing panel. It will not adapt cleanly to Blade-only, Inertia/Vue, or API-first applications without custom wiring, and it does not replace a general-purpose audit log if the org needs one for compliance.

Integration feasibility. Mechanically straightforward: Composer install, service-provider auto-discovery, plugin registration in the relevant PanelProvider, publishing migrations/config, and dropping a widget onto a dashboard or adding the companion resource/page. The real work is schema review (does it add columns to users or only new tables?) and confirming the panel middleware stack is the right place for its tracking hook. Estimated engineering effort: 0.5–1 day for a Filament-fluent developer, plus review cycles.

Technical risk.

• Adoption risk (high): 22 stars, 0 dependents, single maintainer (edwink75). There is essentially no production signal. Treat as an early-adopter dependency, not a settled one.
• Release hygiene (high): The listed release date of 2026-05-02 is anomalous — verify whether it is a legitimate tag, a mis-tagged release, or clock skew in the package metadata. Inspect commit cadence, CHANGELOG, and issue responsiveness before committing.
• Version coupling (medium): Filament has had breaking changes across major versions (v2 → v3 → v4). Confirm the supported matrix against the org's pinned Filament and Laravel versions.
• Write amplification (medium): If "active users" is derived from a per-request last_activity_at write, expect DB write pressure proportional to panel traffic. Confirm throttling and indexing.
• Privacy/compliance (medium): User activity tracking is personal data under GDPR/CCPA. Retention windows, export, and who can view the activity log need product-level sign-off, not just an engineering one.
• Widget polling (low–medium): Presence widgets typically poll; confirm interval, auth, and whether polling is cache-backed or hits the DB each tick.

Key questions.

1. Which Laravel and Filament versions are officially supported, and is there a test matrix?
2. Does it write per-request, per-session, or batch/throttle?
3. Is "currently active" derived from the DB, cache, or session store — and how does that interact with our session driver (database vs. Redis)?
4. Does it support multiple guards / multi-tenant panels, or is it single-panel only?
5. Is activity storage self-contained, or does it depend on spatie/laravel-activitylog (and if so, which major)?
6. Is there a pruning/retention command, and is it scheduled?
7. What is the test coverage and CI posture?

Integration Approach

Stack fit. Best fit: Laravel 10/11+ with Filament v3+ admin panels, session driver already database- or Redis-backed, and an existing policy around user data access. Poor fit: headless/API-only services, non-Filament admin UIs, or orgs that already standardize on spatie/laravel-activitylog for audit (overlap risk).

Migration path. composer require → publish config and migrations → review migration diff → php artisan migrate in staging → register the plugin in the target PanelProvider → add the widget to the dashboard → configure retention and pruning schedule. Non-destructive if it only adds tables; if it alters users, plan a reversible migration and a backfill strategy.

Compatibility. Pin exact versions of the package, Filament, and Laravel in composer.json. Validate against the org's session driver, queue driver, and timezone configuration — presence and activity timestamps are sensitive to all three. Confirm Filament's panel discovery and widget registration mechanism matches how the plugin expects to be registered.

Sequencing.

1. Spike (1 day): install in a throwaway branch, confirm version compatibility and inspect the migration diff.
2. Schema review + privacy sign-off: confirm no PII beyond user ID/timestamp is captured, or that redaction is configurable.
3. Staging soak (3–5 days): observe query volume, widget polling behavior, and presence accuracy under realistic concurrency.
4. Pilot: enable on one non-critical panel or a single dashboard for a subset of users.
5. Full rollout with a documented kill switch (disable plugin in PanelProvider, optionally roll back the migration) and a retention job in production.

Operational Impact

Maintenance. Single-maintainer MIT package with low commit velocity. Budget ~1 dev-day per quarter for dependency hygiene and Filament major-version tracking. If the feature becomes load-bearing (e.g., feeds a compliance report), plan to vendor-fork or wrap it behind an internal interface so it can be swapped.

Support. No commercial support, no downstream dependents to lean on for community answers. The team is effectively an early adopter: expect to file issues and self-patch. Escalation path is "our engineers read the source."

Scaling. The dominant scaling risk is write amplification if activity is recorded per request — verify throttling and index last_activity_at (or equivalent). The presence widget scales with dashboard concurrency; set a conservative poll interval (e.g., 60s+) and prefer cache-backed presence lists over per-tick queries. Activity tables grow linearly with traffic — enforce a retention window and a scheduled prune.

Failure modes.

• Filament major-version bump breaks widget registration or resource discovery (no upstream guarantee of timely fixes).
• Migration collision with an existing users schema or with spatie/laravel-activitylog.
• Stale or inflated "online" counts due to session driver mismatch or missing pruning.
• Timezone bugs in activity timestamps confusing incident timelines.
• PII leakage if activity payloads capture more than intended.
• Polling storms on dashboards with many concurrent admins.

Ramp-up. Low for a Filament-fluent team — half a day to read the source and wire it up. Allow 1–2 days total for the spike, schema review, and staging validation. Product/legal involvement is required for the privacy review, which is typically the longest-lead item in the rollout.