mradder/filament-logger
Filament Logger is an audit and activity log package for Filament admin panels, built on spatie/laravel-activitylog. It adds a ready-made activity resource, CSV/JSON exports, dashboard widgets, and automatic logging for models, resources, auth events, and custom events.
Architecture fit. Filament Logger is a Laravel-native, Filament-native audit layer over spatie/laravel-activitylog. It does not introduce a separate audit service or proprietary data store; it publishes config and migrations, writes to the Spatie activity table, and registers a Filament resource for review. For a TPM, that means the package is best treated as an audit-review accelerator for existing Filament admin panels, not as a compliance-grade immutable audit platform. It fits internal back-office, support, and security-review workflows where admins need searchable diffs, saved tabs, exports, and alert hooks without building a custom UI. It is a weaker fit where requirements demand WORM storage, legal hold, tamper-evident chains, or cross-system audit aggregation.
Integration feasibility. Integration is deliberately low-friction: composer require, filament-logger:install, migrate, and registering the activity resource in the panel provider. The package supports PHP 8.2, Filament 3.x, 4.3.1+, and 5.x, plus Laravel 11/12/13 contracts. The README documents guard scoping, redaction, anonymized IPs, ignored fields, pruning, custom events, exports, and dashboard widgets. A TPM can scope a pilot to one panel and a small set of models/events, then expand. The main feasibility gate is not code effort; it is governance: authorization defaults, sensitive-data redaction, retention, and export controls must be validated before broad rollout.
Technical risk. The dominant risk is community-maintained dependency risk: 26 stars, 0 dependents, and a continuation of an earlier package by another maintainer. Documentation, changelog, releases, CI badges, and PHPStan/Sonar signals are positive, but they do not replace adoption evidence or an SLA. Audit logging is security-sensitive; a bug in authorization, redaction, guard scoping, or pruning can expose data or destroy evidence. Compatibility shims across Filament 3/4/5 reduce version risk but may lag future Filament breaking changes. Filament 4 support starts at 4.3.1 because of an upstream security issue, so the exact Filament version must be treated as a hard gate. Spatie activitylog is a mature dependency, but the package’s value is the UI and automation layer, so exit risk should be assessed as “can we fork or replace the UI layer?”
Key questions.
Stack fit. Best fit is a Laravel application already using Filament for admin operations and either already using spatie/laravel-activitylog or willing to adopt it. If the team is on Filament 3.x or Filament 4.3.1+/5.x, the package is technically aligned. If the team is on an older Filament 4.x release, upgrade Filament first. If the product has no Filament panel, the package’s main value disappears. If the team already has a custom audit log, the TPM should decide whether to replace the review UI, reuse the existing Spatie table, or run a dual-write comparison period.
Migration path. Run a non-production spike first. Install the package, publish config and migrations, inspect the generated configuration, and verify the activity table schema against any existing Spatie usage. If Spatie activitylog is already present, avoid duplicate tables and validate log_name, causer, subject, and property mappings. For a custom audit system, do not cut over blindly: dual-write or shadow-read for a bounded period, compare coverage, and keep the old export path until the new one is accepted. Historical backfill is only practical if existing data already matches the Spatie schema; otherwise treat the package as forward-looking audit and preserve old data separately.
Compatibility. Pin the package version and test against the exact Laravel, PHP, Filament, and database versions in production. Pay special attention to Filament 4.3.1 as a security floor, JSON diff rendering on MySQL/Postgres, multi-guard auth event scoping, and multi-panel/tenancy recipes. Validate export behavior against real filtered datasets, not toy data. Check whether dashboard widgets and alert hooks create acceptable query load. Confirm translations and date formatting only if they are user-facing requirements.
Sequencing.
Maintenance. The package adds a small but real maintenance surface: Composer updates, Filament upgrades, Spatie activitylog upgrades, config drift, migration changes, and translation or UI regressions. Because it is community-maintained with low adoption signals, the TPM should assign an internal owner and budget periodic upgrade review. Keep the package pinned, monitor releases and security advisories, and maintain a lightweight fork path. MIT licensing makes a fork possible, but forking is not free; it transfers maintenance to the internal team.
Support. There is no commercial SLA. Support is community issues plus the project’s SECURITY.md disclosure process. The TPM should set expectations accordingly: internal L1/L2 support for admin questions, security escalation to the internal owner, and no vendor escalation path. Before adoption, confirm legal/security acceptance of a community package handling audit data. If audit data is regulated, require an internal runbook covering access requests, export approvals, retention exceptions, and incident response.
Scaling. The activity table will grow with every logged event. Plan indexes, retention, and archive strategy early. Pruning by age and log name is useful but dangerous if it deletes evidence before retention requirements are met. High-volume models, large diffs, and frequent auth events can bloat storage and slow review queries. Dashboard widgets and CSV/JSON exports can become expensive on large filtered sets; test with production-like volume and consider asynchronous exports or read replicas where appropriate. Alert hooks should be rate-limited and routed through an owned channel to avoid alert storms.
Failure modes. Watch for sensitive data leaking into diffs, misconfigured authorization exposing audit records, tenant leakage in multi-panel setups, pruning deleting required evidence, export timeouts or memory exhaustion, duplicate logging after partial migrations, alert webhook failures, and compatibility breaks after Filament upgrades. Also consider operational failure during logging itself: audit writes should not unexpectedly block critical business transactions, and DB saturation can affect both audit and application performance. Define monitoring for log volume, failed exports, alert delivery, pruning jobs, and dashboard query latency.
Ramp-up. Developer ramp-up is low for a Filament team: install, register resource, configure models, and validate policies. Admin ramp-up is moderate because users must learn saved tabs, date presets, diff review, exports, and high-risk filters. TPM ramp-up is mostly coordination: security review, compliance sign-off, retention policy, alert ownership, and upgrade governance. A one-to-two-sprint pilot is reasonable for a single panel; broader rollout should be gated on measured audit coverage, investigation time, export completeness, alert precision, storage growth, and successful upgrade testing.
How can I help you explore Laravel packages today?