Tomato Logs Laravel Package

Product Decisions This Supports

• Whether "in-app log viewer" earns a roadmap slot at all. This package converts a vague observability request into a small, concrete feature: read storage/logs from the admin panel instead of SSH-ing into a box. A PM can scope it as an admin-surface convenience item, not a monitoring initiative.
• Tiering the observability investment. It draws a clean line between tier one — "a developer can eyeball an error in staging" — and tier two — "we can investigate a production incident across instances." Adopting this is an explicit decision to fund tier one and defer tier two to Sentry, Better Stack, Datadog, CloudWatch, or Loki.
• Support and triage workflow design. Faster first response without SSH credentials, a support person able to pull a log for a ticket, staging debugging without escalating to engineering. That is a real support-cost line item and it is measurable: engineers stop running tail -f for routine triage.
• Scope discipline — verify the claim before it drives the roadmap. The package description markets an activity log that "records user actions… who did what and when," which reads like an audit trail. The implementation is a Filament screen that reads storage/logs files. Those are different products with different compliance implications. A PM must resolve that mismatch before anyone writes "audit logging" into a roadmap or a customer commitment.
• Platform standardization. If the product already runs TomatoPHP/Filament, this is a near-zero-marginal-cost consistency win. If it does not, adopting it means importing a slice of that ecosystem — a materially different decision with a different carrying cost.
• Build vs. buy vs. adopt. At this size it is not a build-vs-buy evaluation; it is an adopt decision judged on carrying cost. The honest framing is: is the capability worth roughly a day of engineering? Usually yes for staging-only triage.
• Dependency-risk policy, with a live test case. Zero stars, zero dependents, no issue triage, no security-disclosure channel, and a release history that is largely cosmetic (v1.1.2 is a style-only patch). This is a concrete instance of the policy question "how much unmaintained OSS do we tolerate in the admin surface?" — and a chance to answer it before an incident asks it for you.
• Access control and data-exposure scope. A log viewer is a privileged window into stack traces, SQL with bound parameters, request payloads, and occasionally tokens or PII. The package does not enforce an authorization model for you. Including it is a decision about who can see what, redaction, and retention — and the PM owns that decision, not the vendor.
• A pre-committed fork-and-own trigger. Cheap enough to pre-decide: "if this breaks on the next Laravel or Filament major, we fork under our org rather than block the upgrade." That converts an unmaintained dependency from a latent surprise into a planned, costed line item.

When to Consider This Package

Consider it when:

• The application is already on TomatoPHP/Filament, so adoption is a config line and a menu entry rather than an integration project.
• The need is development, staging, or small single-instance production triage — the "engineers currently SSH and grep" stage.
• Observability SaaS budget is zero, and/or the deployment target (shared hosting, single VPS, on-prem appliance) cannot run agents or ship logs off-box.
• Log volume is small enough that reading local files is instantaneous, and keeping log data on-premise is a requirement rather than a preference.
• You are prepared to pin the exact version, gate the route behind an application-owned admin role, and fork on break.

Look elsewhere when:

• You need alerting, cross-host aggregation, retention policy, structured queries, search at scale, or a genuine audit trail. That is a log pipeline, not a file viewer.
• Compliance or privacy obligations apply (GDPR, HIPAA, SOC 2) and logs may contain PII. A file-reading web UI with no redaction guarantees is the wrong control to put in front of an auditor — and it does not satisfy the audit-trail claim in its own description.
• You are not on the Tomato/Filament stack. The mature alternatives are opcodesio/log-viewer (Filament-native, actively maintained, broad adoption) or rap2hpoutre/laravel-log-viewer. Off-stack, this package buys a dependency rather than a feature.
• The team requires a named maintainer, a support channel, or a security response path — none of which exist at this adoption level.
• The use case is production incident investigation across multiple instances. It loads file contents into memory (large files time out), reads local disk only, and offers no aggregation.
• Logs do not land on local disk at all. If they ship to CloudWatch, Loki, or Better Stack, the viewer reads an empty or stale directory.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed convenience that shortens time-to-diagnose by putting a log screen inside the admin panel the team already uses. Direct cost is effectively zero and the integration is measured in hours, not sprints. What it buys is faster first response in staging and dev: fewer SSH round-trips, support able to self-serve a log for a ticket. What it does not buy is monitoring, alerting, cross-instance search, retention policy, or an audit trail — and it should not be presented as reducing monitoring risk. The real spend decision on observability remains open and unaddressed by this. Recommendation: time-boxed adoption on staging only, behind an admin role we own, with the exact version pinned and a documented rule that we fork rather than block an upgrade.

To engineering: A thin Filament plugin wrapping jackiedo/laravel-log-reader. It registers a log-browsing screen — list files, filter by level/date/keyword, download, clear, refresh — inside the existing Tomato admin panel. Prerequisites are Laravel 10/11, Filament 3, PHP 8.1+. Three conditions on adoption: (1) the route is gated by a gate we define in application code, not by panel login — assume no authorization ships by default until proven otherwise, and write the test that asserts a non-admin gets 403 before this reaches a shared environment; (2) switch to the daily log channel with a rotation cap so no single file grows large enough to time out the reader, and treat the destructive Clear action as download-first, or wrap it out of production; (3) keep the integration thin — own the menu entry and route, do not let other code import the package's classes or config keys, so a future swap to opcodesio/log-viewer is deleting a plugin registration rather than rewriting a feature. Last release was 2024-04-29 with no downstream users and no security-disclosure channel; the total surface is roughly a controller, a config, and some views, so the fork cost is about a day — but only if we decide that up front rather than at the moment an upgrade is blocked.

To the team, one line: It shortens staging triage. It is not your observability story, and if someone proposes it as one, that is the misread to correct.