- How do I install jackiedo/log-reader in a Laravel application?
- Install it with composer require jackiedo/log-reader, then publish the package config file using Laravel's vendor:publish command. The service provider registers a config file, a LogReader facade, routes, controllers, and Blade views, so wiring is typically measured in minutes rather than sprints. The real work is governance: gating the routes behind authentication and authorization and deciding whether delete and download should be enabled at all.
- Which Laravel and PHP versions does jackiedo/log-reader support?
- The last release was 2023-02-18, which predates current Laravel majors and recent PHP releases, so official compatibility is unverified and unclaimed. The code surface is small and mostly framework-agnostic, so it plausibly runs on Laravel 8 through 10, but you should smoke-test it against your target versions. Treat it as unmaintained until proven otherwise, and be prepared to fork if you hit an incompatibility.
- Does log-reader work with JSON or custom-formatted log channels?
- No. The package parses Monolog's default line format from files such as storage/logs/laravel.log using regex, so it assumes the standard formatter. Teams using JSON formatters, custom channel formatters, or non-standard stack output will see partially parsed or completely unparsed entries. Validate parser output against real samples from each channel before adopting it, because parser fragility is the most likely source of broken-tool tickets.
- How do I secure the log reader routes in production?
- The routes registered by the service provider are not a security boundary on their own, so wrap them in your application's existing auth middleware and an explicit authorization gate limited to admins or engineers. Logs routinely contain PII, stack traces with absolute paths, environment hints, and occasionally leaked credentials from failed HTTP calls, so an authenticated-but-unauthorized viewer is a privilege-escalation and data-exfiltration vector. The package has no audit trail, so keep that in mind for compliance requirements.
- Can I read log contents programmatically instead of using the built-in UI?
- Yes. The LogReader facade gives you programmatic access to log contents, which is the more interesting extension point than the bundled Blade browser. Many teams expose curated log health signals, such as error counts or recent exception files, through a first-party admin endpoint rather than shipping the vendor UI. That approach lets you keep authorization, audit, and data exposure under your own control.
- How do I configure which log files the package reads?
- Publish the package config and point it at storage/logs or any other path you want to browse. Confirm the configured file pattern matches your actual channel layout, whether that is a single laravel.log file, dated daily files, or a stack of multiple channels. If the pattern does not match how your channels write files, the browser will show nothing or only partial entries.
- Can users download or delete log files from the log reader UI?
- Yes, the Blade UI includes download and delete actions alongside the paginated log browser. Delete is destructive and irreversible, and the package provides no audit trail for who removed a file. If read-only access covers your support use case, disabling those actions removes most of the operational risk.
- Is jackiedo/log-reader suitable for multi-node clusters or serverless deployments?
- No. It is an in-process convenience shim over the local filesystem, reading whatever sits in storage/logs on the instance handling the request. On ephemeral containers the logs vanish with the instance, and in a multi-node cluster you only ever see one node's logs. Best fit is a single-region Laravel 8 to 10 monolith on a VM or container with a persistent log volume and no existing log aggregation stack.
- How actively is jackiedo/log-reader maintained, and what is the exit cost?
- The last release was in February 2023, the repository has roughly 149 stars, and there are zero Packagist dependents, which is a weak production signal. There is little community pressure to fix edge cases, so expect to own any bugs you find. The exit cost is near zero, since it is a few hundred lines of MIT-licensed code you can vendor or fork if the maintainer disappears.
- What are the alternatives to log-reader for browsing Laravel logs?
- If you need real observability with aggregation, search, and retention, use a centralized stack such as Loki or Datadog rather than a filesystem viewer. For the narrower goal of giving support engineers a read-only log console without SSH, comparable open-source in-app viewers such as rap2hpoutre/laravel-log-viewer exist, or you can build a small admin endpoint on top of the LogReader facade. Framing this package as a Datadog replacement will disappoint; framing it as a convenience console will not.