Weave Code
Debug Laravel Package
orchestra/debug
Orchestra Debug provides debugging helpers and service providers for Laravel applications, making it easier to inspect application state and troubleshoot issues during development. It is part of the Orchestra Platform ecosystem.
Orchestra Debug provides a lightweight debugging layer for Laravel applications built on the Orchestra Platform. It centralizes debug-mode detection and exposes convenient diagnostic helpers, letting developers inspect configuration, environment, and runtime state without scattering ad-hoc checks throughout the codebase.
- Debug mode management — detect and toggle application debug state consistently.
- Diagnostic helpers — quick inspection of config, environment, and services.
- Framework integration — hooks into Laravel's logging and exception handling.
- Extensible contracts — register custom collectors for project-specific diagnostics.
- Zero-config defaults — works out of the box within the Orchestra ecosystem.
Frequently asked questions about Debug
- What is orchestra/debug used for?
- Orchestra Debug is a lightweight developer-tooling layer for Laravel applications built on the Orchestra Platform. It centralizes debug-mode detection and exposes diagnostic helpers so you can inspect configuration, environment values, and runtime state without scattering ad-hoc checks across the codebase. It also hooks into Laravel's logging and exception handling and lets you register custom collectors through extensible contracts. It is a require-dev companion, not application architecture.
- Which Laravel versions does orchestra/debug support?
- Version 3.4.0 of orchestra/debug exists specifically to bump compatibility for Laravel 5.4, so treat 5.4 as the supported target. Always open the package's composer.json and read the illuminate/* constraint before assuming anything newer works, because it almost certainly does not. If your application is on Laravel 5.5 or later, this package is the wrong tool.
- How do I install orchestra/debug in a Laravel 5.4 application?
- Install it as a dev dependency with composer require --dev orchestra/debug:^3.4 and pin the version explicitly. Then manually register Orchestra\Debug\DebugServiceProvider in the providers array inside config/app.php. Finally, run vendor:publish to copy the configuration stub into your app so you can tune the debug settings. There are no further steps, and the blast radius is only a handful of files.
- Does orchestra/debug support Laravel package auto-discovery?
- No. Laravel 5.4 predates package auto-discovery, so integration requires explicit manual registration of the service provider in config/app.php. You also need to publish the config file yourself. Plan for those three steps in your setup docs or onboarding notes, since they will not happen automatically.
- Is orchestra/debug safe to leave enabled in production?
- No. An environment-gated debug layer that can render SQL bindings, config values, or environment entries is one misconfigured staging .env away from a real data leak. Use two independent defenses: build release artifacts with composer install --no-dev so the package is physically absent, and add a CI assertion that it never appears in production dependencies. Also add an explicit application-side environment guard such as app()->environment('local', 'development') so a stray .env value is not your only line of defense.
- Can I run orchestra/debug alongside Laravel Debugbar or Telescope?
- You technically can, but you should not. Running it next to Debugbar, Telescope, or any existing query listener causes double collection and distorts the exact timings you installed a profiler to read. That is worse than having no profiler, because it produces confidently wrong performance data. Pick one diagnostic stack per environment and disable the others explicitly.
- Does orchestra/debug require the Orchestra Platform?
- It is built for the Orchestra Platform ecosystem, where the service-provider conventions already match and the zero-config defaults work out of the box. Outside an Orchestra admin stack, you are adding a provider, a published config, and listener footprint to get behavior other tools already deliver. Before committing, verify whether the provider hard-requires other Orchestra packages or runs standalone.
- Does the orchestra/debug panel redact secrets, and how is access gated?
- The published configuration is the place to check, and you should confirm this before deploying anywhere shared. Establish exactly what the gate keys off: APP_DEBUG, APP_ENV, a dedicated config key, or all three combined. Confirm the gate is fail-closed by default so that a missing or malformed setting disables the panel rather than exposing it. If redaction of env values and credentials is not guaranteed, add an application-level authorization check in front of it.
- What are the best alternatives to orchestra/debug for newer Laravel versions?
- On Laravel 5.5 and above, the correct answers are Laravel Telescope, barryvdh/laravel-debugbar, or Clockwork. All three are actively maintained with real community validation, which orchestra/debug lacks. If you must keep orchestra/debug on 5.4, isolate every call behind a thin adapter with start, mark, and log methods so swapping tools later is a one-file change instead of a grep across the codebase.
- Is orchestra/debug actively maintained, and how do I remove it later?
- Expect minimal external validation: no stars, no dependents, and no community bug reports, which means your team is effectively the QA function. Plan the removal path from day one, because the realistic outcome at your next Laravel upgrade is a rip-out rather than a replacement. Removal is composer remove plus deleting the provider line from config/app.php and the published config file. There is no migration path to a successor package, so budget for re-instrumenting with Debugbar or Telescope at that point.
Weaver
How can I help you explore Laravel packages today?