- How do I install jkocik/laravel-profiler in a Laravel app?
- Install it as a development dependency with composer require --dev jkocik/laravel-profiler and pin a version constraint suitable for your application. Confirm package auto-discovery on your Laravel version or register the service provider manually. Publish the configuration with vendor:publish, commit config/profiler.php so behavior is reviewable, then register the profiler middleware and choose a storage driver. Keep the package in require-dev and enable it only in local or staging-dev environments.
- Which Laravel and PHP versions does laravel-profiler support?
- The declared compatibility matrix in the latest tag's composer.json is the source of truth, so verify it before adopting the package. The technical assessment suggests checking a Laravel 8 through 11 range and PHP 7.4 or 8.x, but solo-maintainer packages can lag major framework releases. Run a short spike on your exact Laravel and PHP versions rather than assuming support. A blocked framework upgrade can turn a debugging convenience into migration work.
- How does Laravel Profiler compare to Laravel Telescope and Laravel Debugbar?
- Laravel Profiler is a middleware-driven collector set with a bundled timeline inspection UI covering requests, database queries, events, logs, views, memory, and performance metrics. Laravel Telescope is first-party but heavier, while barryvdh/laravel-debugbar provides an in-page toolbar rather than a separate profiler UI. Laravel Profiler sits in the same development-experience layer and is best treated as a trial-tier candidate. Running it alongside Telescope or Debugbar can double listeners and storage, so choose one primary tool per environment.
- Is it safe to run Laravel Profiler in production?
- Laravel Profiler is a development-time observability tool, not a runtime dependency of the product, and it should be enabled only in local or staging-dev environments. The main production risks are sensitive data capture, UI exposure, storage growth, and per-request overhead. Gate it behind an explicit flag such as PROFILER_ENABLED=true and an APP_ENV check rather than relying on package defaults. If it must run in a shared environment, add authentication, an authorization gate, an IP allowlist, redaction, and retention pruning.
- How do I protect the Laravel Profiler UI route?
- The package registers a separate route for its inspection UI, and protecting that route is a configuration responsibility the package does not solve for you. Wrap the profiler route in authentication middleware and an authorization gate, and add an IP allowlist for shared staging environments. Make sure the route is not reachable outside local by default. A profiler route exposed publicly should be treated as an information-disclosure incident because captured request, session, and SQL data may be visible.
- What data does Laravel Profiler collect, and can I redact sensitive information?
- The profiler can collect request and response data, database queries and SQL bindings, events, logs, views, session data, auth identifiers, memory usage, and timeline metrics. That means headers, tokens, request payloads, and session values may be captured and rendered in the UI. Confirm in your spike whether the latest tag provides supported redaction or masking configuration for captured request and session data. Until redaction is verified, restrict UI access and avoid enabling the profiler in environments that handle sensitive customer data.
- How do I configure storage and stop Laravel Profiler data from growing forever?
- Laravel Profiler supports pluggable storage: flat-file JSON by default, plus DB or custom drivers. The assessment notes there is no retention guarantee without a pruning job, so treat storage growth as an operational concern. Choose the driver deliberately, ensure writable storage for the file driver, and add a retention or pruning process for JSON files or database rows. Verify whether the latest tag has a supported pruning mechanism before relying on the package to manage cleanup.
- Does Laravel Profiler work with queues, scheduled commands, and Laravel Octane?
- The request-middleware design gives weak coverage of queue workers, scheduled commands, and artisan execution, so it is not a full replacement for worker-level observability. Compatibility with Laravel Octane also needs verification because middleware and state assumptions can differ under long-running workers. Test queue, scheduler, and Octane behavior in your spike if those paths matter to your application. Use dedicated tools or logging for background job visibility rather than assuming the profiler captures them.
- How much per-request overhead does Laravel Profiler add, and can I profile only some requests?
- Always-on collection with every collector enabled can slow local test loops, and running it alongside Telescope or Debugbar compounds listener and storage overhead. Measure overhead in your own application with all collectors enabled versus a minimal set. The assessment flags on-demand or sampled profiling by header or tag as a question to resolve, so do not assume the latest tag supports selective profiling. Enable the profiler only where needed and keep the collector set as small as practical.
- Is jkocik/laravel-profiler actively maintained, and when should I choose an alternative?
- The package is MIT-licensed with roughly 189 stars and a single-maintainer signal, so treat it as a trial-tier candidate rather than a platform commit. Check the latest release date, declared Laravel and PHP matrix, CI matrix, test coverage, and issue-response cadence before adopting it. Choose Laravel Telescope when you need a first-party, platform-supported observability tool, or Laravel Debugbar when an in-page toolbar fits better. If you adopt Laravel Profiler, pin the version and keep the published configuration forkable so you can migrate away cleanly.