opcodesio/log-viewer: a Laravel log browser you reach at /log-viewer

The problem opcodesio/log-viewer solves for Laravel teams

Laravel writes application logs to files under storage/logs, and the default way to read them is a terminal, an editor, or a tail command. That works until you need to find one stack trace among thousands of lines, or compare an error burst across a day of rotated files. opcodesio/log-viewer puts a browsing interface on top of those files. The README describes it as a companion for a Laravel app so that you "will no longer need to read the raw Laravel log files", and lists search, level filtering, and sharable links to individual entries as the core interactions.

The audience is narrow and clear: a developer or operator with shell or filesystem access to a Laravel host who wants to inspect logs on that host. It is not aimed at teams that need to ship logs off the machine, correlate them with traces, or alert on them. The package reads files where they sit. That single design decision explains both its low setup cost and its ceiling.

How the package reads and serves log files

The repository layout shows the shape of the thing: a src/ directory for PHP, routes/ for the web endpoints, config/ for published configuration, and resources/ with a Vue front end built through Laravel Mix. The package.json lists Vue 3, vue-router, pinia, Tailwind, and axios as build dependencies, which matches the README's claim of a mobile-friendly, keyboard-accessible UI with dark mode. The front end is compiled and published into the host application's public directory, so the browser talks to routes served by your own Laravel app, not to an external service.

According to the README, the package can read the Laravel logs in storage/logs and also other log types: Horizon, Apache, Nginx, Redis, Supervisor, Postgres, and more. That variety implies a parser layer rather than a single hardcoded format. The troubleshooting section confirms it: if your log has a custom format that is not supported out of the box, you define your own custom log parser. There is also an API for folders, files, and log entries, plus download and delete actions from the UI. Delete is worth pausing on. A browser button that removes log files is convenient on a development box and a liability on a production host where those files are your only record.

Installing opcodesio/log-viewer and opening your first log

The requirements are stated plainly: PHP 8.0+ and Laravel 8+. The README's badge lists Laravel 8.x through 12.x, and the v3.24.0 release notes add Laravel 13 support, so the supported range is wider than the badge alone suggests. Installation is two commands. The first pulls the package from Packagist:

composer require opcodesio/log-viewer

The second publishes the front-end assets that the package ships for the browser UI:

php artisan log-viewer:publish

After that, the README says the application is available in your browser at {APP_URL}/log-viewer, giving https://my-app.test/log-viewer as the example. Open that path on a host where storage/logs contains entries and you should see the list of log files with their entries, plus the search and level filter controls. If the page loads but no entries appear, the README points at two causes: an unsupported log format, or a web process that cannot read the files. The Apache example in the README is explicit: to read /var/log/httpd, the web process that serves the app must have read permission on those files, which on Unix systems can be granted with file ACLs. Configuration beyond the defaults is not documented in the README itself; it lives on the project's documentation site.

Where opcodesio/log-viewer is the wrong tool

The package has no documented mechanism for shipping logs to a central store. If you run several services, containers, or hosts, each installation sees only the files on its own machine, and the README's multiple host support refers to configuring several hosts inside one viewer, not to collecting logs from them. There is no mention of retention policy, alerting, or querying across time ranges at scale. For an incident that spans a queue worker, a web node, and a database, this tool gives you three separate browser tabs.

The delete action is the second boundary. The README lists download and delete of log files from the UI as a feature. On a production host, an accidental click removes evidence. Nothing in the README describes an undo, a trash location, or a permission gate on that action, so treat it as a capability to restrict rather than a convenience to hand out.

The third boundary is format. Anything outside the supported set needs a custom parser, which means PHP work before you can read the file. If your logs are JSON lines emitted by a structured logger, check whether that shape is covered before assuming the viewer will render it usefully.

opcodesio/log-viewer compared with a terminal or a full log platform

The nearest alternative is not another package; it is the workflow you already have. grep, less, and tail read the same files with no installation, no published assets, and no route exposed on your application. They are worse at filtering by level across rotated files and worse at sharing a single entry with a colleague, which is exactly what the README advertises as sharable links. If your logs are small and your team is comfortable in a shell, the package adds a web surface for a task the shell already handles.

The other direction is a log aggregation platform, which indexes logs centrally and queries them across services. That approach costs infrastructure and an ingestion pipeline. opcodesio/log-viewer costs two commands and a route. The honest comparison is not features but scope: one reads files on the host, the other moves them off it. Choosing the package means accepting that your logs stay where Laravel wrote them.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-06-11. The most recent release in the same window, v3.24.2, fixes log indices not re-building in some cases, and v3.24.0 from 2026-03-15 added Laravel 13 support along with Octane compatibility improvements. The release cadence visible here includes small fixes and framework-version support, which is the pattern you want from a package that hooks into Laravel internals.

Upgrade cost is mostly the publish step. Because the front-end assets are compiled and published into your application, a new version can require re-running php artisan log-viewer:publish to refresh those assets. Budget that into dependency updates rather than assuming composer update alone is enough. The MIT licence permits commercial use and modification; the LICENSE.md file is the authoritative text, and this is a description of the licence identifier, not legal advice. If you fork or vendor the package, the MIT terms still apply to the copy you distribute.

Editorial conclusion

Adopt opcodesio/log-viewer if you run a Laravel 8+ app on PHP 8.0+ and want to read storage/logs in a browser instead of tailing files by hand. Do not adopt it as a central log platform for many services, and do not expect it to parse a log format it does not support without a custom parser. Before rolling it out, verify that your web process can read the log paths you intend to browse, and check the route protection you plan to put in front of /log-viewer.

Frequently asked questions

Official sources

1. License: MIT
2. opcodesio/log-viewer on GitHub
3. Project website
4. README
5. Releases