Tomato Backup Laravel Package

Technical Evaluation

Architecture fit. This is not a backup engine; it is a thin TomatoPHP/Filament presentation and settings layer over spatie/laravel-backup. That decomposition should drive the whole evaluation, because the two components carry very different risk. The risk-bearing half — archive creation, retention pruning, disk upload, notifications — is mature, widely deployed, and uninteresting in the best sense. The plugin half contributes settings screens, a listing/download surface, and a manual trigger. Architecturally it fits cleanly only if the target application is already on the TomatoPHP/Filament admin stack. In that case it slots in as a panel plugin with a published config, adds no new runtime services, and requires nothing beyond a destination disk, a queue worker, and a live scheduler. In any other stack it is a foreign dependency introduced to obtain a settings page, which inverts the value proposition.

Integration feasibility. Feasible and small — the package is readable end to end in about an hour, and installation follows the standard Filament plugin pattern plus the mandatory spatie/laravel-backup config publish. The real integration work is not the plugin; it is the surrounding prerequisites: a configured destination disk (with the Flysystem S3 adapter and correct root/permissions if remote), a dedicated queue for backup jobs, cron-driven schedule:run, and raised memory_limit/max_execution_time on the backup worker. Those are hours of platform work that the plugin neither supplies nor reminds the operator about. Treat the plugin as one to two days of saved UI work, not as the delivery of a backup capability.

Technical risk. Four items dominate:

1. Maintenance abandonment. 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 possibly fork, not dependency to rely on. Installing it transfers all future Laravel/Filament upgrade compatibility to us.
2. Version drift against the engine. The last release sits in the Laravel 10/11 and Filament 3 era. Its pinned constraint on spatie/laravel-backup may silently constrain or downgrade the engine version we actually want — a wrapper pinning an old engine is worse than no wrapper. This must be verified on a throwaway branch before adoption, not discovered during an upgrade.
3. The restore claim. The description advertises restore directly from the admin panel; the underlying engine creates archives but has no restore command. Whatever the panel exposes is either a download link or a narrow database-import helper. Until this is confirmed in source and rehearsed against a scratch database, it must not enter any incident-response or compliance conversation.
4. Two sources of truth. If the plugin persists settings to a database table, backup policy gains a second origin that will drift from version-controlled config/backup.php. Destination, retention, and encryption decisions should stay in config regardless.

Secondary but real: with encryption: 'default', archives are encrypted with APP_KEY, so a key rotation renders every prior backup unreadable. That is a policy decision we own, not a plugin defect.

Key questions to answer before committing.

• Are we already on TomatoPHP/Filament? If no, the answer is spatie/laravel-backup plus a minimal action — do not adopt the plugin.
• Does the wrapper's dependency constraint resolve cleanly alongside our existing spatie/laravel-backup version, or does it constrain it?
• Does the service provider read settings from config/backup.php or from a settings table?
• What exactly does the panel's "restore" affordance do in source — and has anyone executed it end to end?
• Do we have a named maintainer-of-last-resort for a fork, with budget for one compatibility check per Laravel/Filament major?
• For which environments is mysqldump against a live primary acceptable, and where do we need a read replica instead?

Integration Approach

Stack fit. Adopt only on an existing TomatoPHP/Filament panel. The value is one to two days of saved admin-screen work in front of non-technical operators; it is not a platform commitment. On any other stack, the correct move is spatie/laravel-backup directly with a single Filament action or artisan command wrapping Artisan::call('backup:run', ['--only-db' => true]) — that is the entire value the wrapper adds, reproducible in one class.

Migration path. There is nothing to migrate from; this is a greenfield capability for most teams. The genuine migration concern is the fork: an MIT license, negligible community, and no release in over a year make forking into our own namespace on day one the cheapest insurance available. A repositories VCS entry pointing at our fork costs twenty minutes now and prevents an abandoned package from blocking a future framework upgrade.

Compatibility. Verify in a throwaway branch, in this order: (1) install and run composer why-not/composer update --dry-run to confirm the pinned spatie/laravel-backup constraint does not downgrade the engine; (2) confirm the exact plugin class name from vendor/tomatophp/tomato-backup/src/; (3) publish config/backup.php and read it before touching the panel; (4) determine whether settings live in config or a table. Only after those pass should the Filament plugin be registered in AdminPanelProvider.

Sequencing. Prove the engine before the UI — this is the sequencing decision that matters:

1. Configure a destination disk (local plus an S3-compatible target; multiple disks are cheap insurance against a backup living on the same volume as the data).
2. Run php artisan backup:run --only-db and php artisan backup:list from the CLI.
3. Restore that archive into a scratch database. Until a restore has succeeded once, the feature does not exist.
4. Establish the dedicated backup queue, the scheduler entries (--only-db nightly, --only-files weekly, backup:clean daily, backup:monitor daily), and age-based alerting wired to a channel a human reads.
5. Only then register the plugin and expose it to operators, with the artisan commands documented in the runbook as the fallback when a framework upgrade breaks the panel.

If the work is being scoped as a checkbox item against a disaster-recovery gap, the honest v1 is steps 1–4 with step 5 optional. Steps 1–4 are also the part that survives if the plugin is later dropped.

Operational Impact

Maintenance. We become the maintainer the moment we install it. Budget one compatibility check per Laravel and Filament major, plus an owner for the fork. The wrapper is thin enough that a fix is usually hours rather than days — but only if someone has already read the source. Assign that reading as a precondition of adoption, not a follow-up task.

Support. No vendor, no SLA, no CVE response, no security questionnaire survival. This will not clear procurement in a regulated or enterprise buyer's process. Internally, support for "the backup panel is empty" and "the restore button doesn't work" lands on whoever owns the panel, and both symptoms point at infrastructure (dead scheduler, missing worker) or at the gap between what the description promises and what the engine does.

Scaling. The plugin neither causes nor cures scale problems, and it should not be presented as addressing them. Two engine behaviors set the ceiling: mysqldump against a live primary holds locks and creates a write-stall window — for anything non-trivial, point the dump at a read replica; and large file payloads will hit PHP memory_limit and max_execution_time, which should be raised on the backup queue worker specifically rather than globally. Long remote uploads occupy a worker for minutes; sharing the default queue means user-facing jobs stall behind a database dump.

Failure modes, roughly in order of severity:

• Retention plus silent failure. backup:clean deletes the last good archive while backup:run has been failing quietly for weeks. The only mitigation is backup:monitor with alerting on backup age, set conservatively at roughly twice the backup cadence — not 30 days. Build this before enabling aggressive retention, not after.
• Dead scheduler or missing worker. A panel listing an empty backup table looks identical to a panel whose scheduler has never run. Nothing in the UI tells the operator the difference.
• APP_KEY rotation. Every encrypted archive becomes unreadable, discovered at restore time. Either set an explicit backup.password held in a secrets manager outside the app, or accept that key rotation requires re-encrypting archives first.
• Misconfigured S3 disk. Fails at upload time after the archive is already built — wasted minutes and, without alerting, a false sense of coverage.
• Policy drift. If settings live in a database table, a panel edit silently diverges from what the repo says the policy is, and nobody notices until an audit.

Ramp-up. Low for a competent Laravel engineer: the source audits in about an hour and the engine is well-trodden. The ramp-up cost that actually matters is organizational, not technical — it is the restore drill. Write the procedure down (fetch archive, unzip, mysql < or pg_restore, rsync the files payload), rehearse it against a non-production database, and record who is accountable when a restore fails. The package answers "can the operator click a button?" It does not answer "who is on call at 3am?" Until that drill has been run, the panel must not become the artifact we point at when asked whether we are backed up.