Filament Activity Log Laravel Package

Technical Evaluation

Architecture fit. The package is a thin Filament-facing layer over spatie/laravel-activitylog, which is the de facto standard for audit trails in the Laravel ecosystem. Architecturally that is the right shape: Spatie owns the persistence, model morphing (subject/causer), and the activity_log table; this package owns the Filament integration (a plugin/service provider, an ActivityLogResource with list/view pages, and hooks that bind Filament's lifecycle events — create, update, delete, restore — to Spatie's logging API). Because the durable state lives in a first-party-style schema rather than in the package's own tables, adopting it does not create data gravity. If we later drop the package, the audit data and the Spatie dependency remain intact; we would only need to rebuild the viewing UI or point users at a custom resource.

Integration feasibility. Low-to-moderate effort for a Filament-based admin. Expected work is: composer require, publish migrations from Spatie (not from this package), run migrations, register the plugin on the intended panel(s) in the PanelProvider, and decide a subject/causer logging policy. The unknown that drives real effort is Filament major-version compatibility — Filament 3 and Filament 4 have meaningfully different resource/table APIs (schema vs. form, action namespacing, page registration), and a 2-star package with zero dependents is unlikely to have broad CI coverage across the matrix. I would treat "does it install and render on our Filament version" as a spike, not an assumption.

Technical risk. The dominant risk is supply chain and maintenance risk, not technical risk. Signals: 2 stars, 0 dependents, a single apparent maintainer, and a release date (2026-07-07) that is anomalous relative to the current date — possibly a metadata artifact, possibly a mistagged future release. Either way it warrants a manual look at the tag history and commit cadence before we trust it. Counterweights: MIT license (forkable), and the blast radius is small because Spatie does the heavy lifting and the package contributes UI plus a handful of hooks. The most likely failure mode is not data loss but breakage on a Filament upgrade, leaving us with a resource page that throws. Secondary risks: audit-trail completeness gaps (does it capture restore causer correctly? does it log attribute diffs or only the event?), N+1 queries on the activity table when rendering subject/causer relations, and authorization — an activity log exposes who changed what, so panel-level access control and per-record visibility (multi-tenant panels) must be verified, not assumed.

Key questions.

1. Which Filament major versions are supported, and is there a CI matrix proving it?
2. Does it log attribute diffs (old/new values) or just the event, and does it respect Spatie's $recordEvents / logOnly / logExcept semantics?
3. How does it handle causer resolution — does it use Filament::auth(), and does that behave correctly for queued jobs, seeders, and console commands (where causer should be null)?
4. Is the viewing resource tenant-aware? In a multi-tenant panel, can a user in tenant A see tenant B's activity?
5. Who maintains it, what is the issue-response history, and what is the commit cadence over the last 12 months?
6. What is the test coverage, and are there tests at all?
7. Does it support Spatie's batch UUIDs for grouping multi-model operations?

Integration Approach

Stack fit. Clean fit if we are already on Laravel + Filament + Spatie's activitylog — in which case this package is a UI convenience, not a new architectural commitment. If we are not already on Spatie, adopting this package means adopting Spatie as a transitive dependency, which is a reasonable but separate decision (migration, table size, retention policy). If we are not on Filament, this package is irrelevant and we should integrate Spatie directly with a nova/livewire/custom view.

Migration path. Because the schema is Spatie's, migration is genuinely low-risk and reversible:

• Publish and run Spatie's migration first, independently of this package, so the audit table exists regardless of whether the Filament UI works out.
• Add the package, register the plugin on one non-critical panel first.
• Backfill is out of scope: activity logging is forward-only. If we need historical "who changed this" for existing records, that is a separate data-reconciliation effort and should be scoped as such.
• Exit path: remove the plugin registration, keep Spatie, write a custom read-only Filament resource. Roughly 1–2 days of work, which caps our downside.

Compatibility. The two axes that matter are Filament major version and PHP/Laravel version. Verify against our pinned versions explicitly. Also check how the package resolves Spatie's Activity model — if it hardcodes Spatie\Activitylog\Models\Activity rather than resolving a configured model, any custom Activity subclass we use (e.g., for tenant scoping or extra columns) will be ignored by the UI. That is a common and annoying integration seam.

Sequencing. (1) Spike: install in a scratch branch against our exact Filament/PHP versions, exercise create/update/delete/restore, confirm the list and view pages render and paginate. (2) Decide the logging policy — which models are audited, which events, retention window, and who can view. (3) Ship logging (Spatie) behind the scenes without the UI, so we start accumulating audit data immediately. (4) Ship the viewing resource to a small admin cohort. (5) Expand. Do not let the package's UI readiness gate the start of audit collection — that ordering inverts the value.

Operational Impact

Maintenance. The package itself should be nearly maintenance-free to operate; the maintenance burden sits in (a) tracking Filament upgrades and (b) owning the audit data lifecycle. Budget an explicit owner for the Spatie dependency and its migration upgrades, and a documented retention/archival policy for activity_log — an unmanaged activity table is one of the more reliable ways to grow a database unexpectedly, since it scales with write volume, not user count. Assume we may need to fork; MIT makes that cheap, but a fork is a real recurring cost and should be an acknowledged contingency, not a plan.

Support. Effectively self-support. With 2 stars and no dependents there is no community to lean on, no Stack Overflow corpus, and issue response is best-effort from one person. Internal knowledge must be documented rather than assumed. This is acceptable for an admin-only, read-mostly convenience feature; it would not be acceptable for anything on a critical path.

Scaling. Two dimensions. Write side: Spatie's logging runs synchronously in the request lifecycle by default, adding an insert per audited event — fine for admin CRUD, but a bulk import or a queued job that touches thousands of models will amplify write load and table growth. Consider logOnly/logExcept, disabling logging on bulk operations, and queueing if the package/Spatie config permits. Read side: the activity resource joins subject and causer per row; at high row counts this is where N+1s and slow pages appear. Verify eager loading and that the table is indexed on subject_type/subject_id, causer_type/causer_id, and created_at — these indexes are not free and should be confirmed present.

Failure modes.

• Filament upgrade breaks the resource — most likely; symptom is a broken admin page, not lost data. Mitigation: pin the package, upgrade Filament and this package together, smoke-test the resource in CI.
• Silent logging gaps — an event type we assumed was captured (e.g., restore, or bulk forceDelete) is not. Mitigation: an explicit acceptance test per event type, not a visual check.
• Causer misattribution — activity attributed to the wrong user, or to null, when actions occur via queued jobs or console commands. This is the most dangerous failure because it corrupts the audit trail while looking fine. Mitigation: test the async/CLI paths deliberately.
• Authorization leak — cross-tenant visibility of activity. Mitigation: verify tenant scoping in a multi-tenant panel before rollout; treat as a blocker, not a follow-up.
• Package abandonment — low severity given the fork path and thin surface area.

Ramp-up. For a developer already fluent in Filament, roughly half a day to install, configure, and validate in a scratch environment; one to two days to do it properly with policy decisions, tenant-scoping verification, and per-event acceptance tests. For a team new to Filament, add time for the resource/panel mental model. The package's documentation is the gating factor here — with a project this small, expect to read the source rather than the README, so plan the spike accordingly and treat "the README documents it" as unverified until confirmed in code.