rap2hpoutre/laravel-log-viewer: a route, a controller, and your log files in the browser

What rap2hpoutre/laravel-log-viewer actually does

Laravel writes exceptions, warnings and your own Log:: calls into files under storage/logs, and the usual way to read them is a shell on the server. This package removes the shell step. It registers a controller, you point a route at it, and the browser renders the log files as a page. The README describes it as a small log viewer for Laravel and shows a screenshot of the result. That is the whole scope: reading files that already exist. It does not collect, ship, index or alert on log lines. It is for the developer or operator who is already inside the application and wants to look at today's laravel.log without SSH. The README states it works with and without log rotate, which matters because a rotated laravel.log plus laravel-2026-05-12.log set is the normal state of a busy application, and a viewer that only reads the current file would hide the history you are usually looking for.

The mechanism is a controller and a view, not a service

The repository layout is small: src/, tests/, composer.json, phpunit.xml, README.md and LICENSE. There is no assets directory and no published JavaScript bundle in the package, which matches the README's claim of no public assets and no vendor routes. The data flow is therefore direct. The route you declare resolves to LogViewerController::index, the controller reads the log files, and the result is handed to a Blade template that the package ships. The README names that template as log.blade.php and says it can be published into resources/views/vendor/laravel-log-viewer/ for customization. Configuration lives in a logviewer.php file that is published into /config/. So the package has exactly two extension points: a view and a config file. There is no queue, no database table, no scheduled command, and no storage layer of its own. If you need to search across rotated files by date, correlate a request id across services, or keep logs after the server is destroyed, this architecture has nothing to offer you and you should not bend it into that shape.

Installing it and opening the logs page

The README gives the install as a single composer command. Run it from the root of a Laravel 12 or 13 application:

composer require rap2hpoutre/laravel-log-viewer

The package is auto-discovered through its service provider, so there is no entry to add to config/app.php in the README's instructions. The second step is the route. The README shows it added to your web routes file:

Route::get('logs', [\Rap2hpoutre\LaravelLogViewer\LogViewerController::class, 'index']);

With those two pieces in place, visiting http://myapp/logs renders the viewer. That path is the one the README uses; the route name is yours to choose, so /admin/logs or /ops/logs works the same way. If the page fails with an InvalidArgumentException in FileViewFinder.php, the README's troubleshooting note points at config caching and gives the fix:

php artisan config:clear

To change the markup, publish the Blade view:

php artisan vendor:publish \
  --provider="Rap2hpoutre\LaravelLogViewer\LaravelLogViewerServiceProvider" \
  --tag=views

Publishing without the tag writes the logviewer.php configuration file into /config/, which is where you change the package's own settings.

The route is the security boundary, and the README leaves it to you

A page that prints stack traces and environment details is a page you do not want on the open internet. The README's installation instructions show the bare route and nothing else: no middleware group, no gate, no authorization callback, no mention of an environment check. That is not a flaw in the code, it is a deliberate minimalism, and it means the access decision is entirely yours. In a Laravel application the fix is to wrap the route in the middleware you already trust, and the README does not prescribe one. Two failure modes follow. First, deploying the package and forgetting the route means the viewer is reachable by anyone who guesses the path. Second, the published log.blade.php is a template in your own resources directory, so any edit you make there is yours to maintain and yours to review; a template that prints raw log content is worth reading before you ship it. The README is silent on both points, and that silence is the strongest argument for treating this as an internal tool rather than a feature you hand to customers.

When rap2hpoutre/laravel-log-viewer is the wrong choice

The README is explicit that this release targets Laravel 12 and 13, and that older Laravel versions and Lumen are no longer maintained, with a pointer to older releases for those. If your application is on Laravel 11 or on Lumen, the current package is not for you and the README says so. Beyond version support, the viewer reads local files. That rules it out for containers where the filesystem is ephemeral, for multi-server deployments where only one instance has the file you need, and for any environment where logs are shipped to a central store and the local copy is rotated away within hours. It also has no query language: the README shows a viewer, not a search interface, so if your workflow is "find every request that touched order 12345 across three services", a file viewer is the wrong tool regardless of how convenient the install is. Finally, the README does not document any access control, retention policy or redaction, so it should not be the thing that exposes production logs to a wider audience than the people who already have server access.

How it differs from Opcodesio/log-viewer and other Laravel log viewers

The related searches around this package are dominated by other Laravel log viewers, and the comparison is worth making because the choice is architectural rather than cosmetic. rap2hpoutre/laravel-log-viewer is the smallest of the group: composer require, one route, no public assets, no vendor routes, a Blade view and a config file as the only extension points. The alternative pattern, represented by packages such as Opcodesio/log-viewer and Arcanedev/log-viewer, tends to ship a richer interface with its own assets and more configuration surface. The difference is not quality, it is where the complexity lives. A viewer with published assets and a larger config tree gives you more control over presentation and filtering, and asks you to manage those assets and that configuration in your deployment. This package gives you almost nothing to manage and almost nothing to configure. If your requirement is a quick page for developers on a Laravel 12 or 13 app, the smaller surface is the advantage. If your requirement is a log console with filtering and a team-facing UI, the smaller surface is the limitation, and you should look at the alternatives the searches point to rather than extending this one.

Maintenance, licence and what upgrading costs

The repository is not archived and the last push was on 2026-05-12, which is the same date as the v3.1.0 release. v3.0.0 landed on 2026-05-11, one day earlier, and v2.5.0 is labelled in the release list as Laravel 12 compatibility, dated 2025-03-10. That sequence tells you the project is still receiving releases, and it also tells you the upgrade path is not a straight line: the jump from 2.x to 3.x happened across two releases in two days, so read the release notes before moving a production application. The licence is MIT, which is permissive and imposes no copyleft obligation on your application; that is a statement about the licence text, not legal advice, and if your organisation has rules about dependency licences you should run this past whoever owns that policy. The practical upgrade cost is low by construction. You depend on one composer package, one route, one optional Blade view and one optional config file. The things that can break on upgrade are the ones you published: a customized log.blade.php and a customized logviewer.php are the two files to diff against the new release.

Editorial conclusion

Adopt it if you run Laravel 12 or 13 and want a log page that is one route and no public assets. Do not adopt it on Lumen or on Laravel versions older than 12, because the README directs those users to older releases and says those frameworks are no longer maintained. Before you deploy, verify what protects the route: the README shows no middleware, no gate and no auth configuration, so the access control is whatever you attach to Route::get('logs', ...) yourself.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. rap2hpoutre/laravel-log-viewer on GitHub
4. README
5. Releases