Filament Maillog Laravel Package

Technical Evaluation

Architecture fit

• Package type is a standard Laravel service-provider package with a Filament plugin surface: composer require, auto-discovery, publishable config + migration, and a Plugin implementation registered on a PanelProvider. This is the lowest-friction integration shape available in the Filament ecosystem.
• Value proposition is narrow and well-bounded: capture outbound mail (subject, recipients, rendered HTML/plain body, headers, status) and expose a read-only Filament resource for support and debugging. It does not attempt to become a mail transport, which keeps blast radius small.
• It sits alongside, not inside, the mail pipeline conceptually — but implementation almost certainly hooks Laravel's MessageSending/MessageSent events, which is inside the pipeline. That distinction drives most of the risk below.

Integration feasibility

• Expected requirements: PHP 8.1+, Laravel 10/11/12, Filament v3 (v4 support must be confirmed). Verify the composer.json constraints before committing — Filament major-version coupling is the single most common break point in this category of package.
• Effort estimate for a first working install in a non-production environment: 0.5–1 day for an engineer already fluent in Laravel and Filament. Add 1–2 days for permissions, retention policy, and redaction review before production.
• No external services, no credentials, no queue worker strictly required. Deployment surface is one migration plus one config file — trivially reversible.

Technical risk

• Data sensitivity (highest). Email bodies routinely contain PII, password-reset links, invoice data, and one-time codes. Persisting them to a queryable admin table converts a transient channel into a durable, searchable data store. This is a compliance decision, not a technical one, and must be reviewed before rollout.
• Write-path coupling. If logging happens synchronously during send, a DB failure, oversized payload, or body-render exception can throw inside the mail pipeline. Confirm whether writes are wrapped in try/catch and whether an async option exists.
• Attachment handling. Verify whether attachments are stored (disk path vs. blob) or only referenced. Blob-in-DB attachment storage will balloon the table and degrade the admin UI quickly.
• Filament resource performance. Full-text search over a body column without appropriate indexing will produce slow admin pages at even modest volumes (tens of thousands of rows).
• Vendor concentration. 30 stars, 0 dependents, single-organization maintainer, forward-dated release metadata (2026-08-21) that should be treated as unverified. MIT license means a fork is always available, but nobody has stress-tested this in the wild.
• Multi-tenancy. If the Filament panel uses tenancy, confirm the resource scopes by tenant; a global mail log leaking across tenants is a serious defect.
• Test-environment noise. Confirm it can be disabled in phpunit.xml / non-production environments, otherwise local and CI databases fill with junk rows.

Key questions

1. Does it capture attachments, and if so where are bytes stored?
2. Is the write synchronous or queued, and is it exception-isolated from the send?
3. Are bodies stored verbatim, or is there a redaction/field-exclusion hook?
4. Is there a retention/prune command or scheduled cleanup?
5. Does it support Filament v4, and what is the stated support matrix?
6. Does the resource respect Filament policies and panel tenancy?
7. Does it capture failures (MessageFailed) or only successes?
8. Which columns are indexed, and is search full-text or LIKE-based?
9. Can it be pointed at a separate DB connection?
10. What is the release cadence and issue-response history over the last 12 months?

Integration Approach

Stack fit

• Strong fit for a Laravel + Filament monolith where support or ops staff already work inside the admin panel. The audience for mail logs is non-engineering (support, finance, compliance), and putting the viewer where they already have accounts and RBAC avoids standing up a second tool.
• Weak fit if the org runs a dedicated observability stack (Sentry, Datadog, a transactional email provider with its own log UI). In that case this is a convenience duplicate of provider-side logs, and the PII cost may not be worth it.
• Best positioned for transactional and notification mail only, with marketing/ESP traffic excluded at the mailer level.

Migration path

• Greenfield: install as part of the initial Filament panel build; near-zero cost.
• Existing app: additive and non-breaking. Publish config and migration, run migrate, register the plugin behind an environment check, backfill nothing — logs start from deploy date. There is no historical mail to import, so no migration risk beyond the schema itself.
• If a competing mail-log package is already installed, treat this as a replace-and-drop migration: both will likely hook the same events and double-write.

Compatibility

• Pin the package version in composer.json (exact or ~x.y) rather than floating. This is a low-star dependency; you want upgrades to be deliberate.
• Verify coexistence with any existing mail listeners (e.g. audit logging, notification wrappers) — multiple MessageSending listeners are fine functionally but each adds latency and its own failure surface.
• Check DB support explicitly. If the deployment is MySQL 8 or Postgres, JSON and full-text options are available; on older MySQL or SQLite the search story degrades.

Sequencing

1. Sandbox install in a scratch branch; read the migration and the event listener source before running anything.
2. Schema and index review — confirm indexes on created_at, recipient, and subject; decide on a retention window at this step, not later.
3. Access control — wire the resource to existing roles via Filament Shield or policies; default should be admin + support lead only, not all panel users.
4. Redaction/config pass — disable attachment capture if not needed; add an exclusion list for high-sensitivity mailables (password resets, MFA codes) if the package supports it, otherwise gate by mailer.
5. Staging soak with realistic mail volume for one to two weeks; measure insert latency impact on the send path and row growth rate.
6. Production rollout behind the config flag, with a scheduled prune job deployed in the same release. Shipping the logger without the reaper is the most common operational mistake here.
7. Observability — alert on table row count and disk usage; add the prune job to the standard scheduled-task monitoring.

Operational Impact

Maintenance

• Low code-maintenance, moderate ownership burden. The package itself changes rarely, but it is a dependency you will likely end up owning: with 30 stars and one maintainer organization, expect to patch or fork within a 12–24 month horizon, especially across a Filament major version bump.
• Budget roughly 2–4 engineer-days per year for version bumps, plus whatever you spend on the first fork if upstream stalls. MIT licensing makes forking legally trivial; it does not make it free.
• Pin versions and review the changelog on every bump. Do not let Dependabot auto-merge this one.

Support

• No commercial SLA. Support is GitHub issues on a small repo — response times should be assumed to be best-effort. Escalation path must be internal: an engineer who has read the listener code and can patch it.
• End-user support load is actually negative if it replaces "can you check whether the invoice email went out?" tickets that currently route to engineering. That is the primary business case and worth measuring explicitly as a KPI.

Scaling

• Growth is linear in outbound mail volume. A modest SaaS sending 20k emails/month with 30 KB average bodies accumulates roughly 600 MB/month, or ~7 GB/year, before indexes and attachments. At 500k/month it becomes a genuine capacity problem within a quarter.
• Mitigations, in order of preference: (1) scheduled pruning with a 30–90 day window, (2) body truncation for large HTML, (3) monthly partitioning on created_at with partition drop instead of DELETE, (4) separate DB connection so log growth cannot affect application query performance, (5) offload attachments to object storage.
• The admin UI is the first thing to degrade, not the database. Watch Filament resource page load times as a leading indicator and add pagination-friendly indexes early.

Failure modes

• Mail send fails because logging failed — the critical one. Verify exception isolation; if absent, wrap or fork.
• Storage exhaustion — unbounded table growth with no prune job takes down the DB, not just the log.
• PII exposure via the panel — over-broad resource access turns the admin UI into a data exfiltration surface; also a GDPR/DSAR scope problem.
• Payload rejection — large attachments or unusual encodings producing oversized inserts that error or silently truncate.
• Render-time errors — mailables whose bodies depend on runtime state can throw during capture, creating a failure that only manifests when logging is enabled.
• Silent double-logging after a second mail-log package is added.
• Version-skew breakage on a Filament major upgrade, manifesting as a blank resource or a panel boot error.

Ramp-up

• Developer: ~1 day to install and configure; ~2 hours to read the listener and migration well enough to debug it. Requires existing Laravel event-system and Filament plugin literacy, which the team almost certainly has.
• Admin/support user: under an hour. The UI is a conventional Filament table with filters — resend, view, and search are self-evident.
• Ops/SRE: 2–3 hours to instrument row-count and disk alerts and to validate the prune job in staging.
• Compliance/legal: non-trivial. Allocate review time for retention window and data classification before enabling in production; retrofitting a retention policy onto an already-populated table is far more expensive than setting one on day zero.
• Overall onboarding cost is low; the governance cost is the real line item.