Since launch, the #1 request was: “Does it work with Laravel?”
Now it does.
DebugPHP just shipped Framework Support — starting with Laravel.
One line. That’s it.
<pre><code>Debug::init(env(&#x27;SESSION_ID&#x27;));
Debug::framework(&#x27;laravel&#x27;);
</code></pre>
Every <code>Log::info()</code>, <code>Log::warning()</code>, <code>Log::error()</code> — instantly on your dashboard. No middleware. No facades. No boilerplate.
If you’re a Laravel dev who ever wrote <code>Log::info()</code> just to check if code runs — this update is for you.
⭐ <a href="https://github.com/CallMeLeon167/debugphp" target="_blank" rel="noopener nofollow">GitHub</a> · 📖 <a href="https://debugphp.dev/docs" target="_blank" rel="noopener nofollow">Docs</a> · 🖥️ <a href="https://dashboard.debugphp.dev/" target="_blank" rel="noopener nofollow">Dashboard</a>
Drop a star if it saves you one debug cycle. That’s all I need. 🤝

Welcome to PHP Dev, a dedicated space for sharing knowledge about PHP and its ecosystem (only PHP directly related).
Help us find good articles and blogposts and provide links. Upvote or downvote, after reading, it's essential

PHP Dev

DebugPHP has added Laravel framework support, allowing developers to stream Laravel log output (Log::info, Log::warning, Log::error) directly to the DebugPHP dashboard with just two lines of code and zero configuration. No middleware, facades, or boilerplate required.

DebugPHP — Framework Support is here. Laravel logs, zero config.

Very interesting project, thanks for sharing!

nice but the Docs has a problem with the SSL

This is amazing, i will read the docs to a better understanding, but is really amazing project.

Shipping the #1 requested feature is always the right call, and Laravel was the obvious first target given its ecosystem size. A few thoughts worth adding to the conversation:
🔹 The two-line integration is the right design decision. Laravel developers are accustomed to elegant, expressive APIs — anything that required middleware registration, service provider setup, or config publishing would have felt out of place. Hooking directly into the existing Log facade means zero behaviour change for the developer; DebugPHP just becomes a silent observer of work they’re already doing.
🔹 The <code>Log::info()</code> debugging pattern is more universal than it gets credit for. Even experienced Laravel developers reach for it constantly — not because they lack better tools, but because it’s the fastest way to confirm execution flow without context-switching out of the codebase. A dashboard that surfaces those logs instantly removes the one friction point that makes the pattern feel dirty: having to go hunting for the output.
🔹 The question worth asking next is context. Raw log entries on a dashboard are useful; log entries tied to a specific request lifecycle, user session, or queue job are invaluable. If the SESSION_ID integration already handles that scoping, it’s the feature that separates DebugPHP from just tailing storage/logs/laravel.log in a prettier UI.
Strong first framework target. Symfony and Slim would be the natural next two — curious whether the framework abstraction layer makes those straightforward to add.