fruitcake/laravel-debugbar: a PHP Debug Bar integration for Laravel development

What fruitcake/laravel-debugbar is for

Laravel applications hide a lot of work behind a single request. A page render can issue dozens of queries, load several views, dispatch events and write log entries, and none of that is visible in the response body. fruitcake/laravel-debugbar attaches PHP Debug Bar to the Laravel request lifecycle and surfaces that work in a toolbar rendered into the page. The README describes it as a package that integrates PHP Debug Bar with Laravel, including a ServiceProvider that registers the debugbar and attaches it to the output.

The audience is a developer working on a Laravel app locally. The package is meant to be required as a dev dependency, and the README states it is enabled when APP_DEBUG is true and the environment is not production or testing. That combination makes the intended setting fairly narrow: a local or staging machine with debug mode on.

The README carries two warnings that define the tool's boundaries. The first is a caution that the DebugBar should be used only in development, because on publicly accessible websites it will leak information from stored requests by design. The second is that it can slow the application down, since it has to gather and render data, and that disabling collectors is the remedy when slowness appears. Neither warning is boilerplate; both describe how the package behaves.

How the ServiceProvider and collectors are wired

The architecture is a ServiceProvider plus collectors. The provider registers the debugbar and attaches it to the output, and it bootstraps collectors that know how to read Laravel internals. The README lists custom collectors specific to Laravel: QueryCollector shows all queries including binding and timing, RouteCollector shows information about the current route, ViewCollector shows the loaded views and optionally the shared data, EventsCollector shows all events, and LaravelCollector shows the Laravel version and environment but is disabled by default.

Others replace or extend the base set. SymfonyRequestCollector replaces the RequestCollector with more information about the request and response. LogsCollector shows the latest log entries from the storage logs and is disabled by default, as are FilesCollector, ConfigCollector and CacheCollector. The package also bootstraps LogCollector for log messages and SymfonyMailCollector for mail, and it keeps the default collectors: PhpInfoCollector, MessagesCollector, TimeDataCollector with booting and application timing, MemoryCollector and ExceptionsCollector.

The disabled-by-default group is the interesting part. ConfigCollector can print configuration values, CacheCollector can print cache events, and FilesCollector lists files included or required by PHP. Each of those is potentially large, so leaving them off keeps the toolbar readable and limits the overhead the README warns about. If you enable them, you are choosing a heavier request in exchange for more detail.

On Laravel Octane, the README states that version 4.x works out of the box and nothing needs to be added to the config. If you are upgrading from 3.x, the instruction is to remove the 'flush' config for Debugbar in config/octane.php.

Installing fruitcake/laravel-debugbar and a first use

The package is installed with Composer, and the README recommends requiring it only for development. Run this in the project root:

composer require fruitcake/laravel-debugbar --dev

Laravel uses package auto-discovery, so the README states you do not need to add the ServiceProvider manually. The debugbar appears when APP_DEBUG is true and the environment is not production or testing. To change the defaults, publish the package config:

php artisan vendor:publish --provider='Fruitcake\LaravelDebugbar\ServiceProvider'

That writes config/debugbar.php into your application, where you can set debugbar.enabled or the DEBUGBAR_ENABLED value in .env, and where the README says you can include or exclude the vendor assets (FontAwesome, Highlight.js and jQuery), or restrict them to 'js' or 'css'. Highlight.js needs both css and js for syntax highlighting.

With the toolbar visible, the facade is the quickest way to push your own data into it. The README shows messages at PSR-3 levels and manual timing:

Debugbar::info($object);
Debugbar::error('Error!');
Debugbar::addMessage('Another message', 'mylabel');

Debugbar::startMeasure('render', 'Time for rendering');
Debugbar::stopMeasure('render');
Debugbar::measure('My long operation', function () {
    // Do something…
});

Helper functions cover the same ground. debug($var1, $someString) dumps all arguments as a debug message, and collect([$var1, $someString])->debug() returns the collection while dumping it, like $collection->dump(). The debugbar() helper mirrors the facade for measures. Exceptions go in with Debugbar::addThrowable($e) inside a catch block.

Enabling and disabling at run time, and the injection trade-off

The facade exposes enable() and disable(), so the debugbar can be toggled during a request. The README adds a note that matters: once enabled, the collectors are added and can produce extra overhead. If you want to use the debugbar in production, the advice is to disable it in the config and enable it only when needed. The same note repeats that by default it can only be enabled in debug mode and non-production environments, and that not installing it in production at all is highly recommended.

There is a second trade-off around injection. By default the debugbar is injected just before </body>. Setting the config option 'inject' to false hands rendering to you through Debugbar::getJavascriptRenderer(). The README warns that skipping auto-injection disables the Request information, because that data is added after the response; the alternative it offers is adding the default_request datacollector in the config.

If you need a collector the package does not ship, the facade and the container both accept one. Debugbar::addCollector(new DebugBar\DataCollector\MessagesCollector('my_messages')) registers a collector directly, and the same call works through App::make('debugbar'), which is useful when you want to register from a service provider of your own.

Where the debugbar is the wrong tool

The most concrete limitation is stated in the README itself: do not use Debugbar on publicly accessible websites, because it will leak information from stored requests by design. That is not a configuration mistake you can patch around with a flag; the toolbar stores request data and renders it. A staging server reachable from the internet is the same problem as production.

The second limitation is overhead. The README says the package can slow the application down because it gathers and renders data, and suggests disabling some collectors when slowness appears. On a request that already runs near a timeout, enabling ConfigCollector or FilesCollector is the wrong move.

A third boundary is the environment gate. The debugbar is enabled only when APP_DEBUG is true and the environment is not production or testing. If you are chasing a bug that reproduces only under APP_DEBUG=false or under the testing environment, the toolbar will not appear, and the README does not describe a supported way to force it there. For API-only projects the toolbar has nothing to render into, since it is injected before the closing body tag of an HTML response.

Finally, the package is a request-level profiler, not an application-wide one. It shows the current request's queries, views, events and timings. It does not aggregate across requests, and the README does not claim otherwise.

fruitcake/laravel-debugbar compared with Laravel Telescope

The natural alternative for Laravel diagnostics is Telescope, and the difference is architectural rather than cosmetic. Laravel Debugbar renders into the response, so the data lives in the page you are already looking at and disappears when you navigate away. Telescope stores entries in a database and gives you a separate UI you open in its own route, which means it survives the request and can show entries from other requests, including ones you did not make yourself.

That distinction decides the choice. If you are iterating on a single page and want query bindings and view data next to the rendered output, the debugbar is the shorter path: one Composer require and no storage. If you need to inspect what happened on a request that already finished, or you want a history, the debugbar's model does not provide it, and a storage-backed tool does. The README describes no persistence layer for the debugbar.

The README also points to the broader PHP Debug Bar documentation at php-debugbar.com for configuration options beyond what the Laravel package documents, which is where to look if the config file does not cover your case.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-06. Releases are frequent: v4.4.3 on 2026-09-01, v4.4.2 on 2026-08-20 and v4.4.1 on 2026-08-04. The repository ships an UPGRADE.md and a CHANGELOG.md at the top level, so version-to-version changes have a documented home, and the README's Octane note is an example of what an upgrade can require: removing the 'flush' config from config/octane.php when moving from 3.x to 4.x.

The licence is MIT, which is permissive and places few obligations on how you redistribute the package. That is a statement about the licence identifier in the repository, not legal advice; check the LICENSE file and your own organisation's rules.

One migration detail is worth flagging because it affects dependency files. The README states the package name changed to fruitcake/laravel-debugbar, and that if you are using barryvdh/laravel-debugbar you can replace it with composer remove barryvdh/laravel-debugbar --dev --no-scripts. The --no-scripts flag matters here: it stops Composer scripts from running during the removal.

Editorial conclusion

Adopt it for local Laravel development, where query bindings, view data and event timing are otherwise scattered across log files. Do not install it on a publicly reachable site: the README states it will leak information from stored requests by design. Before adopting, verify that APP_DEBUG is true and that the environment is neither production nor testing, because those two conditions gate the debugbar; then decide which collectors to disable, since the README warns that gathering and rendering data slows the application down.

Frequently asked questions

Official sources

1. fruitcake/laravel-debugbar on GitHub
2. License: MIT
3. Project website
4. README
5. Releases