Tomato Backup Module Laravel Package

Product Decisions This Supports

• Build vs. buy for the backup admin experience, not the backup engine. The underlying problem — scheduled database and file backups with retention and restore — is already solved by spatie/laravel-backup and is not a differentiator. The only real decision here is whether to spend engineering weeks building an internal panel for triggering, browsing, and downloading backups, or adopt a pre-built one. This package is a candidate answer to the second question only.
• Staffing an ops/admin surface in the roadmap. If the roadmap includes a story like "support and ops can verify, trigger, and retrieve backups without an engineer," this package can satisfy the UI portion of that story for near-zero build cost — provided the team is already on Filament/TomatoPHP.
• Scoping a "platform admin" epic. For shops standardizing on the TomatoPHP/Filament module set, this removes one module from a larger admin-platform build. That's a real schedule win, but a small one — it is a convenience layer, not a platform.
• Setting the bar for dependency governance. With 0 stars, 0 dependents, a single maintainer, and a v1.0.0 whose release notes are an empty changelog link, this package is a useful forcing function for a written adoption standard: what evidence do we require before a community package enters the disaster-recovery path? The honest answer here is "not enough yet," and codifying that is itself a PM output.
• Use cases it plausibly fits: conventional scheduled DB + file backups on a single-tenant Laravel app; per-tenant backup controls in a multi-tenant Filament panel; dev/staging reset workflows; a "download the latest backup" button for account managers.
• What it must not be used to justify: a roadmap commitment to disaster recovery, an RPO/RTO claim, a compliance or audit deliverable, or a "backup initiative: done" status. The package is an availability signal for a UI, not evidence that backups are trustworthy. Backups fail silently and are only tested at restore time — so the product risk sits in the restore drill and the alerting, neither of which this package owns.

When to Consider This Package

Consider it when:

• You are already running Filament (ideally v3) and preferably other TomatoPHP modules. The panel integration is the value; without it you're paying a dependency cluster for a wrapper around an artisan command.
• Your requirements are conventional: nightly DB dumps, storage/asset backups, a retention window, manual trigger from admin, optional S3-compatible offsite target.
• You want a starting point, not a finished capability — and you've already accepted ownership of credentials, monitoring, retention policy, and quarterly restore rehearsals.
• You can read and patch the source (it's small) and are comfortable forking if upstream stalls. MIT licensing makes that legally clean; the question is only whether you have the capacity.
• You're willing to pilot on a non-critical app before it touches anything that matters.

Look elsewhere when:

• You need verified restores, point-in-time recovery, immutable/WORM storage, or audit evidence. Use a managed backup service or a purpose-built database tool. A Laravel module cannot satisfy an auditor, and pretending otherwise is the single most expensive mistake available here.
• You have multi-database, clustered, or large (>100GB) data. Dump-based approaches become operationally painful — long CLI runtimes, disk contention at peak, multipart upload fiddliness.
• You are not on Filament, or on a materially different Laravel/Filament major. Configure spatie/laravel-backup directly and skip the layer.
• Version discipline matters. There has been no release since March 2024, and v1.0.0 shipped with no enumerated changes, no migration notes, and no breaking-change list. You cannot infer backward-compatibility policy from it. Until that gap closes, pin an exact version rather than floating a caret.
• You need vendor support, an SLA, or a named escalation path. This is community OSS with effectively no adoption footprint to learn from.
• Your org's procurement or security review requires provenance — dependents count, maintainer history, CVE response track record. Zero dependents means zero community pressure-tested edge cases.

Default position: evaluate, don't adopt. The approach is sound and cheap; the specific artifact is unproven.

How to Pitch It (Stakeholders)

To executives: We're looking at a small MIT-licensed add-on that puts a backup button, schedule, and archive browser into our admin panel, so routine backups stop consuming engineering hours and become something operations can run and verify themselves. Two things to be clear about. First, this does not replace a disaster-recovery or compliance strategy — it is convenience tooling layered on a mature open-source backup library, and it produces no audit evidence. Second, adoption risk is real: the project shows zero stars and zero known dependents, one maintainer, and its 1.0 release shipped with no changelog. Our mitigation is structural — the backup engine underneath is well-established and independent, so if this module is abandoned we lose a UI and keep the capability. Recommendation: pilot on one internal, non-critical application with a proven restore; approve the approach, gate the version.

To engineering: This is a Filament admin module wrapping the standard Laravel backup tooling. Adopt it and we inherit its scheduling, retention, and destination conventions instead of writing them — that's the whole trade. The catch is that v1.0.0's release notes are a changelog link with nothing enumerated, so the API surface, migration changes, and compatibility matrix are unverified. Before we commit: read the source, confirm Laravel/PHP/Filament/spatie/laravel-backup version constraints and whether they're pinned or caret, check whether the UI respects --only-db / --only-files and monitor-tag semantics or quietly bypasses them, and confirm the queue driver has a worker everywhere including staging — otherwise backups silently never fire. Then test an actual restore into a scratch database, not just a backup. Budget for us owning credentials management, failure alerting, retention pruning, and offsite replication regardless of what the package gives us. If the abstractions fight our needs, drop the wrapper and configure the library directly — that integration is one command and a scheduled task.

To the product owner: Scope this as an accelerator for the admin experience, never as the backup feature itself. Write our acceptance criteria in our own spec — destinations, retention window, restore verification, failure alerting, and the named owner of a quarterly restore drill — and treat the package as swappable beneath them. Definition of done is "we restored successfully from an automated backup and were alerted when we deliberately broke it," not "the module is installed." Sequencing: spike in a branch, prove restore before proving scheduling, keep the existing backup mechanism running for one full retention cycle after cutover.