- What is Laravel Mailbook and how is it different from Mail::fake()?
- Mailbook is a dev-only Laravel package that renders your mailable and notification classes at the /mailbook route so you can inspect them in a browser without triggering a real send. Mail::fake() is a testing utility for asserting that mail was sent, whereas Mailbook gives you a visual, browsable catalog of every email your app can produce. You register mails in routes/mailbook.php and the package handles the rest.
- How do I install Mailbook in a Laravel application?
- Run composer require --dev xammie/mailbook, then run php artisan mailbook:install. The install command creates a routes/mailbook.php file where you register your mails and publishes the package configuration. No manual service provider or route registration is required, and you can optionally publish views and config for customization.
- Which Laravel and PHP versions does Mailbook support?
- As of v1.12.1, Mailbook supports Laravel 10, 12 and 13 on PHP 8.1 through 8.5. Laravel 11 support was explicitly removed in that release, so applications still on Laravel 11 must stay pinned at v1.12.0 or lower. Laravel 10 is still listed as supported even though it is past end of life, so confirm the maintainer's version policy before planning framework upgrades.
- How do I register mailables and notifications in routes/mailbook.php?
- Use Mailbook::add() inside routes/mailbook.php, passing either a class string or a closure. You can register mailables from App\Mails and email notifications from App\Notifications in the same file. After registering, visit /mailbook to browse and preview every entry.
- Can I use dependency injection and model factories when registering a mailable?
- Yes. Closures passed to Mailbook::add() are resolved through Laravel's service container, so you can type-hint services as closure parameters and have them injected automatically. You can also call app() inside the closure if you prefer manual resolution. Model factories such as User::factory()->make() are the usual way to build realistic preview data.
- How do I set the notifiable user for a notification preview?
- Mailbook exposes a to() method on registered notifications so you can specify the notifiable recipient. The documentation shows creating a user with User::factory()->create() and passing it to that method. Without a notifiable, recipient-dependent parts of the notification cannot be rendered correctly.
- Is Mailbook safe to leave installed in production?
- Mailbook is a dev-only package and should be installed with the --dev flag, but a misconfigured config/mailbook.php, for example one with send_to enabled, can still expose previews or send real mail if the routes are reachable. Guard the routes behind an environment check or feature flag and add a CI/CD gate that blocks mailbook routes in production. Review the published config and routes before every deploy.
- What does Mailbook's database rollback feature do?
- Mailbook can wrap each preview in a database transaction and roll it back, so models created by factories or other writes never persist. This keeps shared environments and CI runs clean when previewing mailables that touch the database. On large applications with complex transactions, monitor how long rollbacks take, since they can add noticeable overhead.
- What is the comment() method for registered mailables?
- Introduced in v1.12.1, comment() lets you annotate a registered mailable with human-readable context such as the owner, the triggering event or the business purpose. It turns the preview catalog into a self-documenting register of outbound email, which is useful for QA, support and compliance conversations. Decide as a team whether comments are mandatory for every registered mailable and who keeps them accurate.
- Does Mailbook support queued mailables and notifications?
- Mailbook handles queued mailables and notifications, and a fix in v1.8.4 addressed previews for queued mailables. Edge cases such as delayed jobs are still worth testing in your own application, because queue connections and serialization behave differently from a synchronous send. If a preview fails, check your queue configuration before assuming the mailable is broken.