- How do I install beyondcode/laravel-dump-server in a Laravel app?
- Install it as a dev dependency with composer require --dev beyondcode/laravel-dump-server. Package auto-discovery registers the service provider, so no manual wiring is required. Then run php artisan dump-server and call dump() anywhere in your app to stream output to that console.
- Does laravel-dump-server support Laravel 12 and PHP 8.4?
- Yes. Release 2.1.0 adds Laravel 12 support and includes PHP 8.4 deprecation fixes, with no new features or public API changes. Check the exact php, illuminate/*, and symfony/var-dumper constraints in composer.json before upgrading.
- Should I install laravel-dump-server in production?
- No. It is developer tooling that should be pinned in require-dev and excluded from production images with composer install --no-dev. The dump-server command opens a local TCP listener that could expose dumped values such as request payloads or model attributes if it were ever present in production. Verify the package is absent under --no-dev as an acceptance criterion rather than relying on convention.
- What is the difference between laravel-dump-server and dd()?
- dd() halts the request and stops execution so you can inspect a single point. Laravel Dump Server captures dump() output from your running application and displays it in a dedicated console or browser without interrupting requests. That keeps your workflow moving when you need to inspect several values in one pass.
- How do I change the host or port used by the dump server?
- Config publishing is optional and only needed if you want to override the host or port used by the server. Run the package's vendor:publish command to create the config file, then adjust the host and port values to match your environment. The default setup requires no configuration at all.
- Does laravel-dump-server work with Docker, Sail, or Laravel Octane?
- The server binds a local TCP listener, so Docker, Sail, and Octane/Swoole setups need the host and port to be reachable from your app process. The package assessment flags container localhost behavior as an open question, so smoke-test it in your environment before standardizing on it.
- Is laravel-dump-server actively maintained, and what is the maintenance risk?
- It is a single-maintainer project with a low release cadence, so plan for reactive rather than proactive compatibility with future Laravel majors. Both 2.1.0 changes came from first-time contributors, which is a healthy ecosystem signal but also confirms the maintainer is not driving day-to-day development. With 1,554 stars and an MIT license it is a well-known utility rather than a foundation other packages build on.
- Will laravel-dump-server cause Composer conflicts with my pinned dependencies?
- Release 2.1.0 is a minor bump with no declared breaking changes, but the Laravel 12 and PHP 8.4 support almost certainly widened the php, illuminate/*, and symfony/var-dumper constraints. Widened constraints can create Composer solver conflicts in tightly pinned monorepos even when no application code changed. Run composer update against your full lockfile matrix before scheduling the bump.
- How does laravel-dump-server compare to Ray, Debugbar, Ignition, or Telescope?
- Native dump()/dd(), Ray, Debugbar, Ignition, and Telescope all cover adjacent debugging ground. The narrow differentiator here is streaming dumps to a local console without a paid desktop dependency. The real product decision is tool consolidation, because unresolved "which dumper when" ambiguity costs onboarding time for every new engineer.
- Does adding laravel-dump-server affect application performance or the request lifecycle?
- It registers one service provider and one Artisan command, with no middleware, routes, migrations, queue workers, or event listeners. It holds no persistent state and does not touch your application's runtime graph, so it adds no surface to performance budgets or customer-facing behavior. As a require-dev dependency excluded via --no-dev, it cannot affect request latency or uptime.