Nova Logs Laravel Package

Technical Evaluation

Architecture fit. The package is a Laravel Nova Tool — a Vue front-end bundle plus a small PHP service provider and controller that reads files from storage/logs and renders them. There are no migrations, no queue workers, no external services, and no persistent state. That makes the architectural footprint genuinely trivial: it attaches to the Nova admin surface and adds a read path over files that already exist. It fits a single-node or small-fleet Laravel monolith where Nova is already the internal operations console. It does not fit containerized/autoscaling deployments (ephemeral per-instance storage/logs → silently partial coverage), and it cannot be a system of record: no indexing, no retention policy, no audit trail, no alerting, no PII scrubbing.

Integration feasibility. High, conditional on Nova being present. composer require → vendor:publish → nova:publish → register in NovaServiceProvider::tools() → wrap with canSee(). Roughly 1–2 hours to first value plus a 30-minute read of src/ that doubles as the security review. The hard dependency is laravel/nova — a paid first-party product requiring repo credentials in auth.json / COMPOSER_AUTH. If that resolution fails, it is a repo-auth problem, not a package bug. As a TPM: treat the throwaway-branch composer spike as the go/no-go gate before committing anyone's sprint time, because the last release (October 2022) presumes Nova 4 / Laravel 8–9 and your stack may have moved.

Technical risk. Four material risks, in priority order:

1. Secret exposure surface. Logs routinely contain .env values, DSNs, bearer tokens, and PII. The viewer converts that from "someone with shell access" to "anyone with a Nova login." Nova auth is not an authorization model here; a Gate/canSee on a named ops role is mandatory, and download/delete should be disabled or tightly gated.
2. In-request parsing. No streaming, no index. A 100MB laravel.log can exhaust memory_limit or the gateway timeout and take down the Nova route precisely during an incident. Must be tested against a production-sized file in staging.
3. Maintenance abandonment. Single maintainer, zero dependents, no release in ~3 years, no vendor, no SLA. Assume you own the code on install.
4. Authorization/path correctness. Verify the file-serving code resolves against a fixed base path (no traversal) and that delete/download endpoints carry additional checks beyond tool visibility.

Key questions to answer before adoption.

• Which Nova major and PHP/Laravel versions are we actually on, and does it resolve?
• Single node, or more than one? (If more than one, stop — the tool is actively misleading.)
• Who is the named gate — which role may view, and does anyone get delete/download?
• What is our current max log file size and channel config (single vs daily with bounded retention)?
• Do we have a compliance/data-residency or "who viewed what" audit requirement? (If yes, disqualifying.)
• What is the exit path and who owns the fork when Nova 5 lands?
• Is the durable answer centralized logging, and if so is this explicitly a stopgap with a sunset trigger?

Integration Approach

Stack fit. Laravel + Nova only. No Nova, no candidate — full stop. Presumes the Nova licensing cost and composer credentials are already accepted sunk decisions. Fits PHP 8.x-era apps on Nova 4 / Laravel 8–9; unverified outside that band.

Migration path. There is no data migration — adoption and removal are both one-line changes to tools(). Register behind an environment flag so staging gets it first and production is dark until validated:

config('services.nova_logs.enabled')
    ? \PHPJunior\NovaLogs\Tool::make()->canSee(fn ($r) => $r->user()?->can('viewLogs'))
    : null

Rollback is: remove from tools(), run nova:publish, composer remove. No cleanup, no residue. That reversibility is the strongest argument for piloting rather than building.

Compatibility. Two gates, both cheap. (a) Composer resolution against your real Nova/Laravel/PHP versions in a throwaway branch. (b) php artisan nova:publish in the deploy pipeline — composer install in CI will not republish the Vue bundle, and the resulting blank panel is routinely misdiagnosed as a broken package. Pin to an explicit "1.x.x" constraint with composer.lock committed, and run quarterly composer audit.

Sequencing.

1. Verify Nova credentials and composer resolution (go/no-go, ~10 min).
2. Read vendor/php-junior/nova-logs/src — locate the log-path config, the serving controller, and whether download/delete endpoints exist and what guards them.
3. Define the Gate and role; decide delete/download policy (recommend: read-only).
4. Register behind the env flag, restricted to the ops gate.
5. Staging test with a production-sized log file and against your actual retention config.
6. Ship to ops only; establish the runbook and 2–3 named searches (order ID, email, route).
7. Widen to a read-only support role once the runbook exists and usage justifies it.
8. In parallel, set daily channel retention (LOG_DAILY_DAYS) and add Log::withContext(['request_id' => ..., 'user_id' => ...]) so search is reliable rather than lucky.
9. Reassess at the next Nova major; escalate to fork-or-replace then.

Operational Impact

Maintenance. The recurring cost is low but nonzero and entirely yours: pinned version, committed lock, named engineer, a fork branch you can patch. Realistic fork work if needed — redaction, a view-audit table, a hard file-size cap — is about a day. Budget that decision upfront rather than discovering it during a Nova upgrade. Quarterly composer audit is the floor.

Support. No vendor, no SLA, no upstream response expectation. Support burden is internal: a runbook, a documented search syntax, and an explicit statement that search is literal (no regex, no structured queries, no guaranteed case-insensitivity). The upside is real — once the Gate exists, a read-only support role triages known 500s ("fix ships Thursday") without paging on-call, which is a measurable escalation-volume reduction and a genuine headcount-policy input.

Scaling. The tool scales to exactly one thing: a small number of nodes with persistent local storage/logs. Past that it degrades in the worst possible way — it keeps working, but shows one instance's logs while operators assume they're seeing everything. That is worse than no viewer. Containerized or autoscaling deployments are disqualifying; the durable answer is centralized logging (Sentry, Datadog, Loki/ELK, Papertrail). Secondary scaling limit: file size. Cap log size independently of the viewer; the viewer has no streaming.

Failure modes to plan for.

• Large log file → memory_limit or gateway timeout → Nova route down mid-incident.
• composer install without nova:publish → blank/stale panel.
• Rotated file recreated by a different user (www-data vs deploy user) → permission denied; check ls -l storage/logs before blaming config.
• Deleting the active log file → writer holds the handle; file looks gone or empty until next write. Confusing mid-incident; prefer channel rotation and, if deletion is allowed at all, restrict to archived files.
• Timezone drift across Laravel log timestamps, app TZ, server TZ, and the customer's reported time → chasing the wrong window.
• Silent partial coverage on multi-node.

Ramp-up. First value in ~1–2 hours of engineering. Total responsible adoption — gate, staging test with production-sized logs, runbook, named owner — is closer to a half-day to a day. Support-tier onboarding is cheap once the runbook names two or three concrete searches. The organizational payoff (in-panel triage, fewer SSH loops, a defensible answer to "build or buy internal admin tooling") arrives fast; the cost of getting the authorization and file-size story wrong arrives faster.