stepanenko3/nova-logs-tool
A Laravel Nova tool that lets you browse, search, filter, and manage application log files directly from the Nova dashboard, making debugging faster without needing SSH or filesystem access.
Build vs. buy for admin-panel log access. If Nova is already licensed and in use, this package closes the "add a log viewer to the admin panel" ticket for the cost of one composer require and one tool registration. The out-of-the-box surface — browse files in storage/logs, search and filter entries by level or keyword, severity highlighting, paginated detail view, download, clear — is roughly one to two sprints of internal work. Default call: buy, and spend the reclaimed sprint on the actual incident workflow.
Roadmap: a self-service ops and support surface. This is a low-effort, high-visibility item that ships inside the admin panel the company already pays for. No new vendor, no procurement cycle, no platform-team capacity. It widens the audience for production diagnostics beyond engineers without widening infrastructure.
Deferring a centralized logging purchase. A credible stopgap that can push a Datadog/Loki/ELK decision out a quarter or two — until log volume, retention requirements, multi-instance correlation, or compliance scope genuinely force it. Pitch and record it explicitly as a deferral, never as a substitute. If it is written into the roadmap as "our logging solution," someone will later mistake a file browser for an observability stack.
Support escalation reduction — the metric that justifies it. Scoped log access behind Nova's existing authorization removes the "can an engineer grep the log for me" loop. Instrument escalations per week and time-to-first-diagnosis, not feature adoption or seats. Those two numbers are the business case; if they don't move, the tool is a toy.
Upgrade-window planning. v3.0.0 is a major release whose only listed change is Laravel 12 support, which almost always means older Laravel/Nova ranges were dropped. Treat it as a scheduled dependency bump tied to the Laravel upgrade train — never a background composer update. Budget roughly half a day of staging verification (list → view → download → delete). "Still on Laravel 11" is a reason to pin ^2.3, not a reason to fork.
Backlog hygiene. Close any ticket whose acceptance criteria is "let us see application logs in the admin" as satisfied. Explicitly do not close tickets asking for log aggregation, alerting, retention tiers, cross-service correlation, or PII redaction — that is a different product with a different budget line.
TAM calibration, not adoption signal. 27 stars and 0 dependents looks alarming until you note the addressable market is gated by a paid Nova license and file-based logging. The funnel is narrow, so the number is small by construction. Decide on bus factor and cost-to-replace, not on stars.
Adopt when all of these hold:
^2.3. Never *.single or daily). If logs go to stdout and are aggregated elsewhere, there is nothing on disk to browse.Look elsewhere when:
Risk note for the record. v3.0.0 is the healthiest signal this project has produced: the maintainer is tracking current framework releases, and a second contributor landing the compatibility PR is the first evidence of a contributor base beyond the author. That materially softens — but does not eliminate — the bus factor. The structural weakness is unchanged: nothing in the ecosystem depends on this package, so there is no downstream pressure to keep it working across future Nova majors. Two consequences: pin explicitly (^3.0 or ^2.3) and read the changelog before every bump; and keep treating it as a replaceable convenience, not infrastructure. Extension points are thin — for regex search, tail-follow, redaction, or audit logging of clears, fork it (MIT) or write a sibling Nova tool; don't wait on upstream.
To executives: "This is a free, MIT-licensed add-on for the Nova admin panel we already pay for. It gives support and QA self-service access to application logs, which shortens incident diagnosis and cuts the 'can an engineer check the logs' interruptions. No new infrastructure, no new vendor, no procurement cycle — it is a Composer dependency and a few lines of registration. The latest major version adds Laravel 12 support, which signals the project is keeping current, and it picked up a second contributor. The honest caveat is scale: small community project, one primary maintainer, and it reads one server's local disk — so it is not our answer for fleet-wide log correlation. We mitigate by pinning the version, restricting access to ops roles, and treating it as swappable: about a day to replace if it goes stale. Call it a bridge to a real logging decision, not the decision itself."
To engineering: "One Composer dependency, one registration in NovaServiceProvider::tools(), no migrations, no schema, no coupling into request handling — it only mounts inside Nova. v3.0.0 is a major bump gated on Laravel 12: verify it against our Nova version on staging before merging, and pin either ^3.0 or ^2.3 depending on where the Laravel upgrade stands. Gate it behind Nova authorization — admins/ops only — because log files contain PII and credentials, and don't rely on the UI to redact; handle that in config/logging.php with processors. Two operational musts: keep log rotation on (daily with capped LOG_DAILY_DAYS, or OS logrotate) so the listing stays navigable and files don't OOM the request, and institutionalize download-before-clear so every incident has an auditable snapshot attached to the ticket. In containers, mount storage/logs or point the tool at the container path or you'll be reading stale files. Keep the fallback warm: laravel-log-viewer or a ~30-line custom Nova page. If we ever need cross-instance correlation, that's the trigger to revisit centralized logging — not a reason to extend this."
How can I help you explore Laravel packages today?