- How do I preview Laravel mail in the browser without sending it?
- Install the package as a dev dependency, add a preview mailer entry to config/mail.php, and point your local .env MAIL_MAILER at it. The package registers a custom Laravel mail transport through MailManager, so Mailables, Markdown mail, and notifications sent through the Mail facade are captured and shown in a simple web UI. No real mail service or credentials are required.
- How do I install and configure themsaid/laravel-mail-preview?
- Use composer require --dev for the Composer name, publish the package config, add a preview mailer alongside your existing mailers in config/mail.php, and set MAIL_MAILER=preview only in your local .env. There is no schema, queue, external service, or application-code change. Before installing, verify the canonical Composer vendor and namespace on Packagist: the repository is hosted under spatie while the Composer name supplied here is themsaid/laravel-mail-preview, and the 0 dependents count gives no ecosystem confirmation.
- Which Laravel versions does laravel-mail-preview support?
- Support depends on Laravel's MailManager and transport internals, so pin the package to your framework major and confirm its Composer constraints before rollout. The package is a single-maintainer tool that has changed hands once, so validate it against your target Laravel major rather than assuming broad compatibility. Run a quick spike that sends one Markdown Mailable and one Notification on your target version.
- Is it safe to use laravel-mail-preview in production?
- Treat it as a development-environment tool, never as part of a delivery path. If MAIL_MAILER=preview reaches staging or production, transactional mail is silently written to disk instead of delivered, which is a customer-facing failure with no alerting. Keep it in require-dev and add env-gated config plus a CI or deploy check that fails if the preview mailer is active outside local.
- Does laravel-mail-preview capture queued mail and notifications?
- Yes, anything routed through Laravel's Mail facade or Notification system is captured, including Mailables, Markdown mail, notifications, and queued mail rendered at send time. The evaluation does not describe a fallback to a real transport, so expect captured mail to stay in the preview store rather than being delivered. Confirm queued capture in your own spike if your workers use a separate mail configuration.
- Can I secure or disable the mail preview route?
- The preview route is part of the package configuration and should be middleware-configurable and auth-guarded; confirm the exact options in the published config for your version. Change the path if it could collide with an application route, and disable the route entirely outside local. Do not expose a plaintext mail preview UI on a shared or public host.
- Where does laravel-mail-preview store previewed emails and can I clean them up?
- Previewed messages, including password-reset links and any PII, persist in plaintext on the app filesystem and are served over an HTTP route. Check the published config for the storage location, retention, and cleanup options, and verify whether it respects a non-local filesystem before using it on shared infrastructure. Treat preview storage as sensitive data and clean it up regularly.
- Can I trust the preview rendering for visual QA and automated tests?
- The web UI is built to inspect rendered HTML, plain text, and attachments, which makes it useful as a visual QA signal for Markdown mail, notifications, and multipart messages. For automated tests, use Laravel's Mail::fake() and notification fakes rather than relying on the preview UI, and compare a few real messages against your production transport during the spike. Verify inline images, raw/multipart content, attachments, and localized messages if those matter to your product.
- How is laravel-mail-preview different from Mailpit, Mailhog, HELO, or Mailtrap?
- Mailpit, Mailhog, HELO, and Mailtrap capture SMTP traffic, while this package captures mail inside Laravel and provides a rendered-HTML gallery. It is complementary rather than a strict replacement if your team already runs an SMTP capture tool, so decide whether a second capture mechanism earns its keep. If your app is API-only with no mail surface, the value is near zero.
- Is laravel-mail-preview actively maintained and what are the risks?
- It is a single-maintainer package that has already changed hands once, so validate support for newer Laravel MailManager and transport internals per framework major. The reported 0 dependents means there is no ecosystem evidence confirming the exact vendor string, which is a supply-chain verification task rather than a reason to reject the tool. Intrinsic risk is low; the bigger risk is misconfiguration blast radius, so keep it in require-dev and guard the mailer setting.