Statamic Logbook Laravel Package

Technical Evaluation

Baseline note: No prior assessment exists for this package. This document establishes the initial TPM baseline from a single data point — the v4.1.0 release note — and is therefore deliberately weighted toward open questions rather than settled conclusions. Several statements below are inferred from the dependency named in the release and should be validated against composer.json.

Architecture fit The v4.1.0 change is a Composer constraint relaxation: rap2hpoutre/laravel-log-viewer is now allowed at ^3.0 (previously pinned below 3.x). This tells us the package has a hard or soft dependency on a browser-based log viewer, which places it in the developer tooling / observability-adjacent layer rather than in the request-serving critical path. That is a favourable architectural position: surface area is limited, blast radius is contained, and removal is cheap if the package disappoints.

The important architectural question is whether the log viewer is in require or require-dev. A require-dev dependency means the package is a local debugging aid with near-zero production footprint. A production require means a log-reading UI ships to production, which changes the threat model considerably.

Integration feasibility Low effort. Adoption is a standard Composer install plus, at most, publishing config/views and gating routes. Nothing in this release implies new service providers, queues, storage engines, or external infrastructure. Feasibility is essentially "does our Laravel version resolve" — which this release explicitly improves by opening the door to Laravel 13.

Technical risk

Key questions

1. Is laravel-log-viewer in require or require-dev? This single answer determines whether the RCE fix is a production-security item or a local-tooling nicety.
2. Which CVE/advisory does the RCE fix correspond to, and what is the affected version range? We need this for our vulnerability-management record even after upgrading.
3. Does this package's CI matrix actually include Laravel 13, or was only the Composer constraint opened? A constraint without a green test run is a promise, not a guarantee.
4. What is the PHP floor for Laravel 13, and does it conflict with our current runtime targets?
5. Was the previous constraint ^2.x or a narrower pin? If narrower, why — was there a known incompatibility that this release claims to have resolved?
6. Are there published assets (views, config, migrations) from the log viewer that we may have customised?

Integration Approach

Stack fit Native Laravel package, standard Composer distribution, no polyglot or sidecar requirements. Fits a conventional Laravel monolith or modular monolith without ceremony. If we run multiple Laravel applications, this is a per-application install with no shared infrastructure, which keeps rollout independently reversible per app.

Migration path Two distinct paths depending on our starting point:

• Greenfield (no prior install): install v4.1.0 directly. No migration work.
• Existing install on a pre-4.1 version: upgrade to 4.1.0, then explicitly composer update rap2hpoutre/laravel-log-viewer to pull 3.x, then re-publish and diff any customised views/config. The second step is the one that carries risk and should not be left to a later, unrelated dependency refresh.

For consumers still on the old constraint, this release is effectively the only supported path to the RCE fix. That should raise its priority above its semantic-version weight.

Compatibility

• Laravel 13: newly permitted, per the release note.
• Laravel 11/12: presumed still supported under major 4, but confirm against the package's own constraint set.
• PHP: unknown floor; resolve before scheduling.
• Log viewer v2 and v3 are both satisfiable after this change, so mixed-version fleets will not immediately break — but that also means teams can linger on v2 without noticing. Add an explicit check.

Sequencing

1. Read composer.json; classify the dependency as runtime vs. dev.
2. Confirm the advisory ID and affected range for the RCE; record it.
3. Branch, bump to v4.1.0, and deliberately resolve the log viewer to 3.x — do not accept an ambient composer update.
4. Diff published assets; run the application's route/auth tests around any log-viewing endpoints.
5. Validate on a staging app running Laravel 13 if that is our forward target; otherwise validate on current LTS.
6. Roll to one application, hold 1–2 weeks, then fan out.
7. Only after that, adopt the Laravel 13 upgrade separately — do not couple the two changes in one release.

Operational Impact

Maintenance Low, with one caveat. The package itself is small and the changelog cadence appears modest, so ongoing maintenance is mostly "keep the constraint current." The caveat is that our maintenance burden now includes a second project's release cadence — a major bump in the log viewer becomes our problem to triage. Budget a recurring line item to watch upstream advisories, and pin the transitive dependency explicitly in our own composer.json rather than relying on this package's constraint to govern it.

Support Community-supported upstream; no vendor SLA. Appropriate for internal developer tooling, inappropriate for anything customer-facing without an internal owner. Assign a named owner. Since the tooling is debugging-adjacent, an outage degrades developer experience but should not degrade production traffic — verify that assumption by confirming no production runtime code path depends on the viewer.

Scaling Effectively N/A. The package scales with the number of developer workstations and environments, not with request volume. The one scaling-adjacent concern is log volume: a browser log viewer reading large log files on a shared environment can be slow and memory-hungry. If enabled outside local development, restrict to small files or gate the route.

Failure modes

• Constraint regression: a future release re-narrows or conflicts, blocking our Laravel 13 upgrade path.
• Silent stale dependency: teams resolve to log viewer 2.x and remain exposed despite running v4.1.0.
• Route/auth misconfiguration: log viewers commonly ship with weak or environment-gated access control. Misconfiguration here is the highest-consequence failure — log files contain secrets, tokens, and PII.
• Asset drift: customised views/config from v2 not reconciled against v3.
• Composer resolution deadlock with other packages pinning the same transitive dependency.

Mitigations: explicit transitive pin, an environment guard (local/staging only), an auth gate, and an advisory-watch ticket.

Ramp-up Under a day for a developer familiar with Laravel. The only non-obvious learning is understanding that the interesting behaviour lives in the dependency rather than this package, so debugging leads upstream. Document that in the internal runbook so the next person does not start in the wrong repository.

Recommendation: Approve adoption of v4.1.0. Treat it as a security-relevant upgrade rather than a routine patch, and gate rollout on confirming (a) the runtime-vs-dev classification and (b) that access to the log-viewing surface is restricted to non-production environments with an auth gate.