Tomato Backup Laravel Package

Product Decisions This Supports

• Splitting one "feature" into two decisions with different risk profiles. This package is not a backup engine. It is a thin TomatoPHP/Filament presentation layer — settings screens, a manual trigger, list/download/delete — sitting on top of spatie/laravel-backup. For a PM that decomposition is the whole insight: the risk-bearing component (archive creation, retention, destination upload) is mature, widely deployed, and boring; the plugin contributes UI convenience worth roughly one to two days of engineering. Evaluate them as separate line items and fund them separately.

• A defensible "don't build it" call for the admin surface. If the stack is already Filament/TomatoPHP, "backup controls in the panel" is a checkbox feature, not a differentiator. Adopting this is legitimate saved UI work — provided it is scoped as such and not promoted into a platform dependency. Write down the exit cost at the moment of adoption, not during the incident that forces it.

• Roadmap sequencing for disaster recovery. If backup/restore has been sitting in the "someday" column, this gives you a shippable v1 — schedule configuration, manual run, destination settings, retention — without spending differentiating engineering time. It frees the team for the work that actually moves the needle: RTO/RPO targets, retention policy, restore drills, and alerting that fires on backup age, not on job status.

• A concrete scope-containment line item for internal tooling and agency/client work. For any project shipping an admin panel on the TomatoPHP stack, this is a defensible "we don't need to write this" entry in the estimate — with the caveat that someone still owns the fork.

• Vendor and maintenance risk budgeting. The decision-relevant facts are: zero stars, zero dependents, a 0.13 composite score, and no release since 2024-04-29. The correct classification is reference implementation to read, and probably fork — not dependency to rely on. Adoption forces an explicit answer to "who is maintainer of last resort?" and a standing budget of one compatibility check per Laravel/Filament major.

• Shaping a "backups included" promise in a SaaS or white-label offer. Useful for packaging — but only after deciding who is accountable when a restore fails. The package answers "can an operator click a button?" It does not answer "who is on call at 3am?"

• A guardrail against letting the UI become the compliance story. Do not point at a backup panel when asked "are we backed up?" The honest answer is a rehearsed restore against a non-production database. Any roadmap or audit narrative that conflates the two will fail at the worst possible moment.

When to Consider This Package

Consider it when:

• You are already running TomatoPHP/Filament and want backup controls in front of non-technical operators without commissioning admin screens.
• Your needs are conventional: scheduled database and/or file dumps to local or S3-compatible storage, with retention. That is exactly Spatie's sweet spot, and the plugin adds a friendly surface over it.
• You can pin the version, fork it into your namespace on day one, and accept that upgrade compatibility is now yours to own.
• You value it as one to two days of saved UI work, not as a strategic platform commitment.
• Someone on the team will actually read the source — it is small enough to audit in about an hour, and that audit should be a precondition of adoption, not a nice-to-have.

Look elsewhere when:

• You are not on the TomatoPHP/Filament stack. Installing an entire plugin ecosystem to obtain a settings page inverts the value proposition. Use spatie/laravel-backup directly with a minimal admin action, or lean on infrastructure-level backups (managed database snapshots, Forge/Envoyer, cloud-native tooling).
• You need point-in-time recovery, immutable/WORM storage, or audited restore drills. These are architectural commitments, not plugin features. Note the gap that will surface in any serious conversation: the underlying engine creates archives but does not restore them, so a "one-click restore" expectation is likely unmet. Verify in the source before it lands in an incident-response runbook.
• Procurement requires a supported vendor with an SLA, CVE response, or a completed security questionnaire. A single-maintainer package with no release in over a year will not clear that gate, and starting the process costs more than the feature saves.
• You need to prove scale behavior — dump locking on a live primary, I/O contention, long remote uploads. The plugin neither causes nor solves these; do not present it as addressing them.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed admin plugin that puts backup controls into our existing admin panel, built on a proven open-source backup library. The upside is a fast, cheap checkbox on a compliance-adjacent capability. The risk is maintenance: near-zero adoption and no release in over a year means that the moment we install it, we own it — including every future Laravel and Filament upgrade. Recommendation: treat the underlying engine as the real bet, treat this plugin as a starting point we may fork, and cap investment at a short evaluation spike. Do not staff it as a supported platform component. Most importantly, do not let it become the artifact we point at when asked "are we backed up?" — the answer to that question is a rehearsed restore, not a package.

To engineering: Evaluate the dependency, not the wrapper. Confirm two things first: version alignment (the April 2024 release places it in the Laravel 10/11 and Filament 3 era) and that its pinned spatie/laravel-backup constraint resolves alongside our existing one rather than silently constraining or downgrading the engine we actually care about. Then determine whether settings persist to a database table or are read from config/backup.php — if it's the database, backup policy gains a second source of truth that will drift from version-controlled config, so keep destination and retention decisions in config regardless. Before wiring any UI, prove the engine in non-production: configure a destination disk, run a manual backup, then restore that archive into a scratch database. Until that restore succeeds once, we have not verified the feature exists — and no amount of panel polish substitutes for it.