- What is spatie/laravel-flare used for?
- It connects your Laravel application to Flare, the error tracking service built by Spatie. Once a valid Flare API key is configured, unhandled production exceptions are serialized and sent to your Flare project so you can review them and receive notifications. It is the modern replacement for the older Ignition-based Flare integration.
- How do I install spatie/laravel-flare?
- Install it with Composer using composer require spatie/laravel-flare. Then add your Flare API key as the FLARE_KEY environment variable. You can optionally publish config/flare.php to customize the integration and add the flare channel to your LOG_STACK if you want logs shipped to Flare as well.
- Which Laravel and PHP versions does spatie/laravel-flare support?
- The README states Laravel 11 and above on PHP 8.2 and above, but release notes are inconsistent, mentioning Laravel 10 support in one version and Laravel 11.47+/12.42+/13+ in another. Pin an explicit version and verify the constraints in the package composer.json before committing. Do not rely on the README alone for your support matrix.
- Does spatie/laravel-flare work without an API key?
- Yes. Since version 2.0.6 the package completely disables itself when no Flare key is set. That means you can merge it into a codebase ahead of procurement and leave it inert in local and staging environments, only activating reporting in production where the key is configured.
- Can I use spatie/laravel-ignition alongside spatie/laravel-flare?
- Yes, the two packages are fully compatible. laravel-flare handles production error reporting to Flare, while spatie/laravel-ignition continues to provide the rich local error pages during development. You can install both without conflict.
- Does spatie/laravel-flare send request data and cookies to Flare?
- The package can serialize request bodies, headers, session data, cookies, git metadata, and Livewire component state. Version 2.6.2 added cookie and session censoring because of the sensitivity involved. You should complete a PII review and adjust the config before enabling it in production.
- What are the main risks of adopting spatie/laravel-flare?
- Vendor lock-in is the dominant risk, since errors, traces, and logs are all shaped for one commercial backend and there is no documented export path. Major versions have introduced breaking changes, such as version 3.0.0 removing error solutions and the AddSolutions middleware. Budget time for upgrades and confirm the contractual cost model before committing.
- How do I test an application that uses spatie/laravel-flare?
- The package's own test suite includes integration tests that need a running workbench server and queue worker, but you can run only the unit tests with vendor/bin/pest --exclude-group=integration. In your application, keep FLARE_KEY unset in the testing environment so the package stays disabled and no errors leave your test runs.
- What are good alternatives to spatie/laravel-flare?
- Sentry, Datadog, and Bugsnag are the common alternatives, and many teams already pay for one of them. Flare's differentiators are tight Laravel integration, public error sharing, and a Monolog channel that emits OpenTelemetry-format log entities. If you want vendor-neutral telemetry, evaluate those services before adding Flare as a second spend.
- Is spatie/laravel-flare actively maintained?
- It is maintained by Spatie and ships with official documentation on the Flare website, with recent releases adding a first-class flare Monolog channel and hardening the tracing middleware. The low GitHub star count is misleading because root application dependencies are not counted as dependents and the package was split out of the historically bundled Flare integration. Check Packagist download counts for a better signal.