Log Viewer Bundle Laravel Package

Getting Started

Start with the compatibility check, not the install. fdekker/log-viewer-bundle is a Symfony bundle for Symfony 6+. Laravel has no concept of bundles — there is no bundles.php, no bundle bootstrapping, and Composer's type: symfony-bundle will install the files but nothing will register. Running composer require fdekker/log-viewer-bundle in a Laravel app gets you a dead dependency and a few hundred KB in vendor/.

So the first question is which of these you actually are:

1. You have a Symfony service in a mostly-Laravel stack (legacy app, internal admin, a queue worker written in Symfony). Then the bundle is directly usable — go to step 2 below.
2. You are 100% Laravel and just want a log viewer. Don't use this. Use opcodesio/log-viewer (or rap2hpoutre/laravel-log-viewer for something minimal). They are the Laravel-native equivalents and will take ten minutes instead of a day.
3. You want this specific UI/feature set in Laravel anyway. Then treat the bundle as a reference implementation, not a dependency — read its source and port the parsing/controller logic into a Laravel package of your own.

If you're in case 1, minimal steps:

• composer require fdekker/log-viewer-bundle
• Register it in config/bundles.php (Symfony Flex may do this for you)
• Import its routing — either via Flex's generated config/routes/fdekker_log_viewer.yaml or an explicit resource: '@LogViewerBundle/...' entry
• Publish/inspect the bundle config (php bin/console config:dump-reference <bundle_alias>) to find the log path and route prefix keys — don't guess them from the README alone
• Add a security.access_control rule before you open the URL in a browser

Where to look first in the repo: the DependencyInjection/Configuration.php (authoritative list of config keys), the routing definition (default prefix), and the controller(s) that read files off disk. The README will be thinner than the code.

Implementation Patterns

Pattern A — read-only sidecar (the only sane way to get this UI into a Laravel shop). Run a throwaway Symfony skeleton as a container alongside your Laravel app, mount the Laravel storage/logs directory into it read-only, and point the bundle at that mount:

• Separate docker-compose service, no public port; expose only through your existing reverse proxy with auth in front
• volumes: - ./storage/logs:/var/log/app:ro — the :ro matters
• Do not mount the whole application directory; the viewer process should not be able to see .env
• This is genuinely useful for multi-container setups where you have 4+ PHP-FPM hosts and want one place to read logs

Pattern B — port the concept to Laravel. The bundle's value is mostly its parsing and level-filtering logic. In Laravel you'd build:

• A LogFileRepository that lists and resolves files under storage_path('logs'), with a hard allowlist of extensions and a realpath() containment check
• A parser service per format (single, daily) that yields structured entries — this is the piece worth borrowing
• A read-only controller + Blade/Livewire view, route registered inside your existing auth middleware group
• A config file for the log path, page size, and max bytes per file

This is roughly a day of work and gives you something you own, with no Symfony runtime.

Pattern C — native Symfony use. If the app really is Symfony, the everyday workflow is: open the route, filter by channel/level/date, and follow the request ID through. The integration tips that matter are gating the route with a firewall and keeping the bundle out of prod unless it's behind real auth. Use Symfony's DI decoration on the bundle's log-reader/parser service if you need custom path resolution (e.g. a per-tenant log directory) rather than forking.

Pattern D — multi-channel mapping. Laravel writes laravel.log, laravel-2024-01-01.log, plus any custom channels. If you're mapping these into a viewer, treat "channel" as a first-class filter derived from the filename, and normalize the two on-disk formats early. Most viewer bugs come from mixing stack-trace continuation lines into the previous entry.

Integration tip that applies to all of the above: put the viewer behind your SSO/forward-auth layer, not behind app-level auth. Log files contain database credentials, API tokens pasted into exceptions, and user PII. A viewer that inherits a weak session cookie is a data breach with a nice UI.

Gotchas and Tips

• Zero Laravel auto-discovery. No service provider, no facade, no php artisan command. There is no amount of config publishing that makes this work in Laravel. Budget for this being a "no" before you budget for anything else.
• Bus factor is low. 44 stars and 0 dependents means you are likely one of a handful of users. Pin an exact version in composer.json, commit composer.lock, and assume you may need to fork. Don't put it on a critical path you can't patch yourself.
• Verify the release actually exists. The listed last release (2026-08-25) is a future date relative to normal package lifecycles; check Packagist for real tags before assuming a version constraint will resolve.
• Route exposure is the classic failure. Bundles typically ship a default route prefix that is easy to guess (/_log-viewer, /logs, etc.). If you install and immediately browse to it "just to test" on a public host, you may have already leaked. Configure the firewall/access_control first, enable second.
• Laravel's Monolog format may not parse. Laravel's default line is [2024-01-01 12:00:00] production.ERROR: message ... with a multi-line stack trace below it. A viewer written against Symfony's default Monolog line format will either drop these or mis-group the trace. Test with a real Laravel log file, not a fixture.
• Large file handling. Check whether the reader streams or does file_get_contents. A 500 MB laravel.log after an incident loop will OOM the viewer process, and that's exactly when you need it. Look for tail/offset support; if absent, add a size cap in config.
• Permissions and mounts. The web user needs read access to the log directory; on SELinux hosts a read-only bind mount still needs the right context (:z/:Z). Symptom is a silent empty file list, not an exception — check the viewer's own log.
• Config cache. In Symfony, changing bundle config requires bin/console cache:clear in prod. This trips people up constantly when the "log path change didn't take."
• Rotation. With daily channels, the file the viewer opened at page load may be renamed mid-request. Resolve the path per-request, not at container boot.
• Extension point worth knowing: Symfony service decoration is how you'd customize path resolution or parsing without forking. In a Laravel port, the equivalent is binding your own LogParser interface in a service provider — design for that from the start so you can swap formats per channel.
• Don't ship it to production by default. Even with auth, a log viewer is an information-disclosure surface with no upside for end users. Gate it behind APP_ENV !== 'production' or a separate admin hostname.