Product Decisions This Supports
- Build vs. buy for internal admin tooling. The recurring "do we build log access into our admin panel, or adopt something small?" question gets a cheap answer. At 77 stars and MIT-licensed, this is a low-commitment experiment: "support and engineers can read logs without SSH" ships in hours rather than a sprint. The decision it de-risks is whether in-panel log access is worth any engineering investment — usually yes, but not much.
- Whether to expand self-serve support. Adopting it generates real usage data for a support-model decision: can non-engineers triage known failures themselves ("that 500 is the fix shipping Thursday"), or does every error need to route to on-call? That is a headcount and escalation-policy call, not a technical one.
- Back-office observability roadmap. If Nova is already where ops, support, and account managers live, this is the cheapest possible upgrade to incident triage. It informs sequencing: add log access to the tool people already have open, or mandate a second tool (Sentry, Datadog, Kibana) the support tier will never adopt.
- Admin-surface consolidation. Adopting it reinforces "Nova is the single pane for internal operations," reducing tool sprawl and context-switching. Declining it — or adopting then replacing it — is evidence for the opposite bet: observability belongs in a dedicated platform.
- Feature scoping and estimation reference. When someone proposes a homegrown log viewer, this is the baseline to beat. File switching, search, pagination, download/delete, and authorization are already built; a custom version routinely costs more than the estimate suggests.
- Where convenience ends and compliance begins. The package forces an explicit stance on log retention, who may view sensitive log content, and whether deletion should be a UI affordance at all. Those are PM-owned policy decisions, surfaced early by a tool that does all three.
- A forcing function on the Nova bet itself. Since this is a Nova Tool, evaluating it forces the "are we staying on Nova?" question — a paid first-party dependency with its own upgrade timetable — into the open rather than leaving it implicit.
When to Consider This Package
- You run Laravel Nova and are staying on it. This is a Nova Tool, not a standalone viewer. No Nova, no candidate — full stop. Nova is a paid first-party product, so this presumes you've already accepted that licensing cost and the composer credentials that go with it.
- Logs are local files on a small number of servers. One app node, or a modest setup where
storage/logs is the source of truth. Good fit for early-stage products, internal tools, and small teams.
- You want an internal convenience, not a system of record. The bar is "the team sees errors faster." That is cleared. Retention policy, audit trails, PII scrubbing, alerting, and structured query are all out of scope — if any of those are requirements, this is the wrong tool.
- You will gate it deliberately. Nova auth alone is not sufficient. Adoption is only responsible with an explicit Gate or
canSee restricting the tool to a named ops/admin role, and ideally download/delete disabled — logs routinely carry env values, DSNs, tokens, and PII.
- You've verified compatibility first. Last release was October 2022, implying Nova 4 / Laravel 8–9. A composer resolution test against your actual Laravel/Nova/PHP versions is the go/no-go gate before any UI work.
- You accept ownership. Single maintainer, zero dependents, no vendor, no SLA. Assume you own the code the day you install it: pin the version and budget a cheap fork path with a named owner.
- Look elsewhere when: you run multiple servers or containers (logs are ephemeral and coverage is silently partial — worse than no tool, because operators will trust it mid-incident); you need structured or queryable logs (Sentry, Datadog, Papertrail, Loki/ELK); you have compliance or data-residency requirements; you need an audit trail of who viewed or deleted logs; you need alerting; or you simply want the maintained default,
opcodesio/log-viewer, which wins on total cost of ownership.
How to Pitch It (Stakeholders)
To executives: This is a small, free, MIT-licensed add-on that lets our team read application error logs from inside the admin panel we already run and already pay for. It shortens the loop between "a customer reports a problem" and "we know what broke," with no new infrastructure and no vendor contract — the cost is engineering hours, not budget. The trade-off is maintenance risk: no release since 2022, one maintainer, a very small user base. So we'd adopt it as an internal convenience behind a compatibility check and a role gate — not as a system of record, and not as our incident-response tool. It is explicitly a stopgap: the moment we run more than one server, the durable answer is centralized logging and this package stops contributing.
To engineering: A Nova Tool that renders Laravel log files in the admin UI. Drop-in, minimal surface area — no migrations, no queues, no external services, roughly 1–2 hours to first value plus a security review. Three caveats worth real time: verify it resolves against our current Nova/Laravel/PHP versions given the stale release cadence (a composer spike in a throwaway branch is the go/no-go gate); confirm the authorization story matches our role model, since log contents plus download/delete endpoints are a genuine secret-exposure surface if a non-engineer gets access; and test against production-sized logs, because parsing happens in-request and a large file can exhaust memory and take down the admin app precisely during an incident. If those three clear, it's a cheap win — pin the version, name an owner, and treat the fork path as part of the install rather than a surprise later.
One-line framing for the roadmap review: a free, low-risk convenience that buys us faster triage on single-node Nova today, with a known expiry date that arrives the day we scale horizontally or need audited, queryable logs.