How to Install and Configure Laravel Debugbar in Laravel 13

To install Laravel Debugbar in Laravel 13, run composer require fruitcake/laravel-debugbar --dev and make sure APP_DEBUG=true in your local .env. The package registers itself automatically and shows a toolbar at the bottom of every HTML page with queries, timing, memory, views and request data. It should only ever run on your own machine.

The package was previously published as barryvdh/laravel-debugbar. Many older tutorials still use that name, so this guide also covers moving to the new package.

Prerequisites

• Laravel 13 with PHP 8.3 or newer.
• Laravel Debugbar 4.x (fruitcake/laravel-debugbar), which supports Laravel 11, 12 and 13.
• A local environment where APP_ENV=local and APP_DEBUG=true.

Step 1: Install the package as a dev dependency

composer require fruitcake/laravel-debugbar --dev

The --dev flag matters. When you deploy with composer install --no-dev, the package is never installed on the server, so it cannot leak data there by accident.

If your project still has the old package, remove it first:

composer remove barryvdh/laravel-debugbar --dev --no-scripts
composer require fruitcake/laravel-debugbar --dev

Then search your code for Barryvdh\Debugbar and replace imports with the new namespace, Fruitcake\LaravelDebugbar.

Step 2: Understand when it is enabled

Debugbar turns itself on when APP_DEBUG is true and the environment is not production or testing. You can override that with one variable:

APP_ENV=local
APP_DEBUG=true
DEBUGBAR_ENABLED=true

Set DEBUGBAR_ENABLED=false when you want a clean page, for example while taking screenshots. There is also a force option for production, but the package itself warns against it, and I never enable it: the toolbar exposes queries, session data and request details.

Step 3: Publish the config (optional)

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

This creates config/debugbar.php. Useful settings include the list of collectors (turn off ones you do not need), the option to show query bindings, and excluded paths such as telescope* or horizon* so the toolbar does not appear inside other dashboards.

Step 4: Read the most useful tabs

• Queries: every SQL statement with its duration and, if enabled, the bound values. Duplicate statements are the classic sign of an N+1 problem.
• Timeline: how long booting, the controller and view rendering took.
• Views: which Blade files rendered and what data they received.
• Models: how many Eloquent models were hydrated. A list page that hydrates thousands of models needs pagination or a narrower select.
• Request and Session: headers, route, middleware and session values for the current request.

Step 5: Add your own messages and measures

The Debugbar facade and the debugbar() helper let you log values and time a block of code. Use them only in local code paths or behind a check, and remove them before you commit if they are temporary.

<?php

namespace App\Http\Controllers;

use App\Models\Order;
use Fruitcake\LaravelDebugbar\Facades\Debugbar;

class ReportController extends Controller
{
    public function index()
    {
        Debugbar::info('Building monthly report');

        Debugbar::startMeasure('orders', 'Load orders');
        $orders = Order::query()
            ->with('customer')
            ->whereMonth('created_at', now()->month)
            ->get();
        Debugbar::stopMeasure('orders');

        Debugbar::measure('Warm cache', function () use ($orders) {
            cache()->put('report:order-count', $orders->count(), now()->addMinutes(10));
        });

        Debugbar::startMeasure('totals', 'Calculate totals');
        $total = $orders->sum('amount');
        Debugbar::stopMeasure('totals');

        return view('reports.index', compact('orders', 'total'));
    }
}

The measures appear as bars on the Timeline tab, which makes it easy to see whether the database or your PHP code is the slow part.

How do you find an N+1 query with Debugbar?

Open a page that lists records with a relationship, for example posts with their authors. If the Queries tab shows one select * from users where id = ? per post, the relationship is lazy loaded. Add with('author') to the query and reload: the repeated statements collapse into a single where id in (...) query. That before and after comparison is the quickest way to prove a fix.

Does Debugbar work with APIs and Livewire?

The toolbar is injected into HTML responses. For JSON API calls, Debugbar can store request data and you can open earlier requests from the toolbar's history on a regular page. Livewire and other AJAX requests are captured too, as long as the page that started them shows the toolbar. For pure API projects, Laravel Telescope is often a better fit.

Common mistakes

• Installing without --dev. The package then ships to production and only your config stands between it and the public.
• Toolbar not showing. Check APP_DEBUG, run php artisan config:clear if config is cached, and make sure the response is HTML with a closing </body> tag.
• Old namespace imports. Barryvdh\Debugbar\Facades\Debugbar will fail after switching packages.
• Judging speed with Debugbar on. Collecting data adds overhead, so absolute timings are slower than real production timings. Compare relative numbers.

How do you verify it works?

1. Run composer show fruitcake/laravel-debugbar to confirm the installed version.
2. Open any page locally and look for the toolbar at the bottom.
3. Set APP_DEBUG=false, clear config, reload, and confirm the toolbar is gone.
4. On your deployment, confirm composer install --no-dev is used so the package is absent.

Which collectors should you turn off?

Every enabled collector adds work to each request. If pages feel slow locally, open config/debugbar.php and disable collectors you never look at, such as the log or the Livewire collector in a project without Livewire. Keep the queries, timeline, views and route collectors, because those answer most performance questions. For query-heavy pages you can also turn on the option that runs EXPLAIN on select statements, which shows whether MySQL or PostgreSQL used an index.

FAQ

Is Laravel Debugbar safe for production?

No. It reveals queries, session values and request data. Install it with --dev and deploy with --no-dev.

Debugbar or Telescope?

Debugbar is best for inspecting the page you are looking at right now. Telescope records requests, jobs, mail and exceptions over time in its own dashboard. Many teams use both locally.

Can I disable it for one request?

Yes. Call Debugbar::disable() early in that request, for example in a controller that streams a file.

References

• Laravel Debugbar on GitHub
• Laravel 13 Configuration: Debug mode
• Laravel 13 Eloquent: Eager loading
• Laravel 13 Telescope