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.
Architecture fit. This is a leaf-node dependency: a Nova tool that mounts a UI panel, reads files from storage/logs, and exposes list/view/filter/download/delete actions. It does not touch request handling, routing, the ORM, queues, or the database — no migrations, no schema, no service provider hooks into the request path. For third-party code that is the best achievable shape: it can be removed with a one-line revert and leaves no residue. The important framing decision is that this belongs to the internal admin-tooling backlog, not the observability roadmap — it is a file browser, not a logging platform. Fit is strong only when Nova is already licensed and logging is file-based on local disk. It reads per-instance disk and will not correlate across nodes, aggregate, alert, or apply retention policy.
Integration feasibility. Composer dependency plus one registration in NovaServiceProvider::tools(), a vendor:publish, and a cache clear. No infrastructure, no vendor contract, no procurement cycle. Realistically half a day to a day including authorization gating, config review, and a staging smoke test of the full loop (list → view → filter → download → clear). The config surface advertised (file list, access control, permissions) is worth reading before assuming defaults — most integration surprises live there.
Technical risk. Ranked:
laravel.log can blow memory_limit or the gateway timeout. Requires rotation discipline.storage/logs inside the PHP container is not the host directory.Key questions. Is Nova licensed, and on which major? Which Laravel version are we on — can we take ^3.0, or must we stay on ^2.3? Is logging file-based on disk, or shipped to stdout and aggregated elsewhere (in which case there is nothing to browse)? Who is authorized, and where is that gate enforced? What is our rotation and retention policy (daily + LOG_DAILY_DAYS)? Single instance or fleet? Does compliance scope (SOC 2, HIPAA, PCI) apply — because a raw-log file browser is a data-exposure surface, not a control. Who owns the fallback and what triggers it?
Stack fit. Laravel + Nova, PHP 8.2+ on the Laravel 12 line, file-based logging (single or daily). Standard Nova tool registration; no new runtime components. The value proposition to stakeholders is that this replaces the "add a log viewer to the admin panel" ticket — roughly 1–2 sprints of internal work — for one composer require.
Migration path. Greenfield install; no data migration and no cutover. The exit path is deliberately cheap: laravel-log-viewer or a ~30-line custom Nova page over the same directory convention, or fork it outright (MIT). Pin explicitly — ^3.0 or ^2.3, never *.
Compatibility. Verify the exact Laravel + Nova pair on the target tag before bumping; read the tag's composer.json rather than trusting the changelog. Nova 3 additionally requires nova:publish; Nova 4+ auto-discovers assets. Two patterns worth standardizing: gate registration behind authorization (Gate::allows('viewLogs') ? new NovaLogsTool() : null), and skip registration in local where a terminal is faster. For non-default log directories (per-worker or per-channel), register a separate tool instance with a distinct label rather than expecting one panel to see everything.
Sequencing.
^3.0 vs ^2.3.config:clear + optimize:clear.Maintenance. Low steady-state cost — no schema, no request-path coupling, nothing to patch weekly. The recurring cost is version-window work: this is a major-version dependency tied to the Laravel upgrade train, so budget half a day of staging verification per framework/Nova upgrade. Treat it as a scheduled bump, never a background composer update, and keep it out of unrelated feature branches so a broken tool is attributable.
Support. No vendor, no SLA. It needs a named internal owner (platform or ops) even though the code rarely changes. The measurable return is escalation reduction: track escalations per week and time-to-first-diagnosis, not feature count. Any ticket whose acceptance criteria is "let us see logs in the admin" closes as satisfied; any ticket asking for search-at-scale, alerting, retention, or aggregation does not — that is a different product.
Scaling. Scales with instance count only in the sense that it does not scale at all: it is per-instance local disk. At high log volume the UX degrades and per-node browsing becomes actively misleading during a fleet-wide incident. Requires rotation and a retention cap to keep the file listing navigable. The trigger to revisit centralized logging is concrete: multi-node correlation, alerting, retention tiers, or compliance scope.
Failure modes. Empty panel from file permissions (the #1 cause, and it fails silently rather than erroring); OOM or gateway timeout on oversized files; stale or missing files from container/host volume mismatch; no-op config changes from a stale config cache; silent breakage after a Nova major; permanent unaudited deletion in production; PII exposure through an under-gated panel. Also a behavioral failure mode: an engineer confidently reading one node's log while the error is on another.
Ramp-up. Effectively zero for anyone who already knows Nova — it is a table and a file list. The real onboarding artifact is a one-page runbook: open the newest daily file, scan the tail, copy the trace, download the raw file onto the ticket, then clear. Engineering ramp-up is half a day. The TPM's effort is concentrated in the two decisions that cannot be delegated: the access policy and the upgrade-window plan.
How can I help you explore Laravel packages today?