Weave Code
Web Log Viewer Bundle Laravel Package
greenskies/web-log-viewer-bundle
A web-based log viewer bundle for PHP applications that lets developers inspect, search, and filter application logs from the browser. It provides a simple interface for navigating log files and debugging issues without direct server access.
GreenSkies Web Log Viewer Bundle is a Symfony bundle that brings your application's log files into the browser. Instead of tailing files over SSH, you can browse, filter, and inspect log entries through a simple web interface — handy during development or on staging environments.
It integrates into a Symfony app, exposing log files read from your configured directories. Built for quick debugging, it keeps setup minimal so you can start reading logs immediately.
- Browse and paginate log files through a web UI
- Filter entries by level, date, or text
- View formatted, readable log lines instead of raw output
- Configurable log directory paths
- Simple Symfony bundle registration
Frequently asked questions about Web Log Viewer Bundle
- Can I install greenskies/web-log-viewer-bundle in a Laravel application with Composer?
- No. This is a Symfony full-stack bundle: it expects Symfony\Component\HttpKernel\Bundle\Bundle, a DependencyInjection extension, FrameworkBundle service wiring, and Twig templates registered against the Symfony kernel. Laravel has no bundle or extension system, so Composer may download the files but nothing will boot or register. There is no supported path to consume it as a Laravel dependency.
- Does this log viewer handle daily rotating logs or only a single monolithic log file?
- The package is a browser front end for Symfony log files that lets you browse, search, and filter without shell access. Because the last release dates to 2018, its tailer logic most likely assumes a single monolithic file rather than Laravel's daily channels or per-service logs. If you need multi-channel support, treat the parsing code as a reference and re-implement it against your actual log layout.
- Which Laravel versions does this package support?
- None. Framework support stops at the Symfony level, and the 2018 release predates PHP 7.4 and 8.x hardening, so it carries Symfony 3 and 4 API assumptions that will not boot on a current Symfony LTS either. There is no Laravel version matrix to check because Laravel was never a target.
- What is the best Laravel alternative for viewing logs in the browser?
- Evaluate opcodesio/log-viewer first: it is actively maintained and Laravel-first, so it installs cleanly and follows Laravel conventions. If you want zero third-party surface, write a small internal route guarded by an existing role gate. Either option keeps log access inside your current auth, audit logging, and CSP posture.
- How do I build a simple Laravel log viewer myself instead of using this bundle?
- Add a route such as /admin/logs behind an existing role gate, read files through Illuminate\Support\Facades\File, and render with Blade. Restrict reads to an allowlisted directory and a fixed enum of filenames so the log path can never be user-influenced. The parsing and offset logic is roughly 150 to 300 lines, so a working version is about a one to three day task.
- How do I test a Laravel log viewer without exposing real log files?
- Point the viewer at a fixture directory in your test environment and use Storage::fake or a temporary path with sample lines, including multi-line stack traces. Assert that requests for paths outside the allowlist return 403, that unauthenticated users are redirected, and that the response never echoes raw file paths back to the client. Cover the offset and tail logic with unit tests so rotation and truncation do not break rendering.
- Is greenskies/web-log-viewer-bundle still maintained?
- No. The last release was 2018-03-12, the repository shows about 4 stars and 0 dependents, which indicates the package was found through indexing rather than adoption. An unmaintained log viewer means no CVE channel, no security patches, and no upstream to escalate to. You would own the entire vulnerability surface.
- Is it safe to render raw log files in a web UI in production?
- Only with strict controls, because logs contain stack traces with DSNs, API keys and PII, plus internal file paths, and a user-influenced log path invites traversal. Keep the viewer behind your existing guard or SSO, use an allowlisted directory and filename enum, add audit logging and a tight CSP, and never co-locate it with shared application credentials. Check whether PCI, HIPAA, or GDPR scope forbids rendering raw log lines in a browser at all.
- Can I run the bundle as a standalone Symfony sidecar instead of porting it?
- Yes, that is the only realistic install-style option, and it means isolating it completely. Use a separate container with a pinned PHP 7.4 or Symfony 4.4 LTS base image, a read-only bind mount of a log volume, no shared credentials or .env, and a network policy allowing ingress only from your VPN or SSO proxy. Never place it in the Laravel pod.
- How much work is it to migrate off this package or port its functionality?
- There is nothing to migrate: no existing install, no dependents, no schema, and no data migration. The decision is sidecar versus port versus buying a maintained package, and the port deliverable is a controller, a Blade view, and roughly 150 to 300 lines of line-parsing and offset logic. Budget one to three days, and start with a short discovery spike to confirm in-browser log viewing is a real operational need rather than a workaround for poor production debugging.
Weaver
How can I help you explore Laravel packages today?