- What is backstage/mails used for?
- backstage/mails is a Laravel package for storing reusable email templates in the database and sending them with dynamic per-send variables. It also adds a Filament admin surface for inspecting logged mail and mail events. Treat it as a convenience and observability layer for support and QA, not as a system of record.
- How do I install backstage/mails in a Laravel app?
- Install it with Composer, publish the package config and migrations, run migrations, and register the plugin in your Filament PanelProvider. The mechanics are straightforward for a Laravel developer, but you should validate the full flow in staging first. The bigger work is access control, retention policy, and data classification.
- Does backstage/mails require Filament?
- Yes. The package is built to plug into an existing Filament admin panel, so a Filament panel should already exist or be planned. If your team uses Nova, Backpack, or a custom admin, this package is a poor fit. Adopting it without Filament means adopting Filament too.
- Which Laravel and Filament versions are supported by backstage/mails?
- The provided context does not pin exact Laravel or Filament version support, so check the package composer constraints and any CI matrix before adopting it. Filament major-version compatibility is the binding constraint, not Laravel alone. Pin backstage/mails to an exact version and test app upgrades in CI.
- Does backstage/mails store full email bodies or only metadata?
- The context does not confirm whether backstage/mails stores full rendered HTML bodies, headers, and attachment metadata or only metadata. This is the most important thing to verify in a staging spike because full-body capture can put password resets, invoices, PII, and tokens into a queryable table. Inspect the actual schema and row contents before enabling it broadly.
- Is backstage/mails safe for queued mail in production?
- Queued-mail behavior and fail-safety are not confirmed in the provided context. Before production, verify whether it hooks MessageSending or MessageSent events or replaces the mail transport, and whether logging is wrapped in try/catch. A logging exception must never suppress outbound mail.
- Can I redact or exclude sensitive fields in backstage/mails?
- Redaction and field-level exclusion support are not specified in the provided context. If those controls are absent, restrict access with an explicit permission and consider scoping capture so sensitive transactional mail is excluded. Pair any capture with retention limits and data-classification notes.
- Does backstage/mails include pruning and retention for logged emails?
- Built-in pruning is not confirmed, so assume you may need to add a scheduled prune command and an index on created_at. Agree a retention window with security or legal, with 30 to 90 days being a common starting point. Gate the Filament resource behind an explicit permission rather than panel access alone.
- Can I scope mail capture per environment, mailer, or tenant in backstage/mails?
- Per-environment, per-mailer, and per-tenant capture scoping are not confirmed in the provided context. Use an environment flag such as MAIL_LOG_ENABLED and roll out to production last. Confirm these controls before relying on the package in a multi-tenant or regulated app.
- What are alternatives to backstage/mails for logging sent mail in Laravel?
- If you do not use Filament, compare this with a custom MessageSent listener or another Filament-compatible mail-log package. Evaluate body capture, redaction, retention, queued-mail behavior, and fail-safe logging before choosing. backstage/mails is most compelling when a Filament panel already exists and the team accepts a single-maintainer plugin dependency.