Filament Spatie Laravel Backup Laravel Package

Technical Evaluation

Architecture fit. This is a thin presentation layer, not a backup engine. It ships a single Filament page that reads and drives spatie/laravel-backup's existing configuration (config/backup.php), disks, and queued jobs. That is the right shape for us: no new persistence model, no parallel backup pipeline, no schema changes. It assumes a Filament panel already exists and that the Spatie package is (or will be) the system of record for backup policy. If our backup strategy lives anywhere else (managed RDS snapshots, Vault, cloud provider tooling), this package is a convenience console layered on top — useful, but not the control plane.

Integration feasibility. Low effort, high determinism. composer require, php artisan filament:assets, optional translation publish, one ->plugin(...) line in the PanelProvider, plus a permission seeder for create-backup / download-backup / delete-backup. Customization is well-factored: a plugin-level fluent API for nav icon/label/group/sort (closures supported), usingPolingInterval(), usingQueue(), timeout() / noTimeout(), authorize(), and a documented page-extension path (usingPage()) for headings and grouping. Nothing here requires us to fork or patch.

Technical risk.

• Version coupling is the dominant risk, not code quality. The package tracks Filament majors — the typed string | \BackedEnum | null navigation property and ->plugin() registration imply Filament v3.2+/v4, and the repo carries an explicit 1.x → 2.0 upgrade guide. Every Filament major bump becomes a plugin upgrade we must schedule in lockstep.
• Single-maintainer bus factor (Shuvro Roy, with community PRs). Mitigated by MIT license and a genuinely small surface area — worst case we vendor or fork a few hundred lines.
• Adoption signal is thin (278 stars, ~0 indexed dependents, low composite score). Acceptable here precisely because the blast radius is a UI page; the load-bearing component is Spatie's, which is mature and heavily used.
• Changelog evidence is stale. The changelog fragments we have are 1.x-era translation and Dependabot noise, while the release metadata claims a recent 2.x release. Release recency and changelog content should be reconciled before we trust the upgrade path.
• Authorization is opt-in. authorize() gates page access; the three action permissions must be seeded and assigned by us. Do not assume least privilege out of the box.
• Downloading archives through the browser streams database dumps through PHP-FPM/web workers to an admin's laptop. This is the highest-risk feature in the package from a data-handling standpoint.

Key questions for engineering.

1. Which Filament major and PHP version are we on, and is there a pinned compatible release of this plugin and of spatie/laravel-backup?
2. Is the admin panel internet-facing, SSO/MFA-protected, and are the three backup permissions mapped to a named role rather than individual users?
3. Which queue connection and worker pool executes backup jobs, and what happens to the UI state if that worker is down?
4. Are backups encrypted, and where do they land — local disk, shared volume, or object storage? Multi-node deployments must not use node-local disks.
5. Do we have backup:monitor scheduled with alerting, independent of this UI?
6. Is the download capability required at all, or can we disable/de-scope it and restore via a controlled runbook instead?

Integration Approach

Stack fit. Native fit for a Laravel + Filament admin panel already running spatie/laravel-backup. It adds one navigation entry under a group we choose (recommend Settings or Core, sorted below day-to-day operational pages). No frontend build changes beyond filament:assets.

Migration path. Greenfield is trivial: install, publish assets and translations, register the plugin, seed permissions, assign the backup role. For an existing Spatie deployment, the only migration is the UI — the existing config/backup.php (disks, retention, database dump binaries, notification mail) is respected untouched, so backup behavior does not change on day one. Treat the 1.x → 2.0 UPGRADE guide as a checklist item if we are adopting an older pinned release.

Compatibility. Three constraint surfaces to verify in CI: Filament major version, PHP minor version, and spatie/laravel-backup config schema (v8 vs v9 keys). Also confirm the host has mysqldump/pg_dump available to the web and queue runtime, and that storage credentials resolve in the queue worker's environment.

Sequencing.

1. Staging install with a throwaway disk; verify create → poll → download → delete end-to-end.
2. Confirm queue worker picks up the job and that usingQueue() is pointed at a pool with adequate timeout.
3. Seed permissions and assign to a single backup role; wire authorize() to that role or an email allowlist.
4. Tune polling (default 4s is chatty) and set an explicit timeout() rather than noTimeout().
5. Optionally extend the page class for headings/grouping — cosmetic, defer if not needed.
6. Production rollout behind the panel's existing auth, during a low-traffic window, with a manual backup taken beforehand.
7. Post-rollout: update the DR runbook to describe the UI path and the CLI fallback (php artisan backup:run).

Operational Impact

Maintenance. Near-zero code maintenance; the real ongoing cost is dependency-upgrade choreography with Filament majors. Budget a recurring line item for "verify backup plugin after Filament upgrade" in the platform upgrade checklist.

Support. Onboarding is a documentation problem, not a training problem — the UI is self-explanatory. The support load will concentrate on permission requests ("why can't I delete backups?") and on the download path ("the archive is too large / times out"). Write a one-page runbook covering: create, verify, restore, and who holds the backup role.

Scaling. Three dimensions:

• Concurrency: polling is per-viewer Livewire traffic; at 4s intervals a handful of admins on the page generates steady background load. Raise to 10s+ or restrict page access narrowly.
• Topology: backup jobs execute on whichever worker claims them, so destination storage must be shared or object-based. Node-local disks silently fragment the archive history across hosts.
• Data volume: large databases will exceed PHP max_execution_time and memory on the download path even when the backup job itself succeeds. Prefer direct-from-storage retrieval over proxying through the app.

Failure modes to instrument.

• Queue worker down → job never runs, page polls indefinitely showing an in-progress state. Alert on queue depth and job age, not on UI.
• Timeout mid-dump → partial/corrupt archive retained; ensure retention cleanup removes incomplete files.
• Disk full on destination → backup fails after DB load has already been incurred; alert on free space.
• Missing dump binary or credentials in the worker environment → failure that only surfaces at runtime.
• Accidental delete of the only recent archive — the delete action is destructive and immediate; restrict the permission to a small group and require an offsite copy that this UI cannot touch.
• Polling masking truth: the page shows what the queue reports, not whether a restore would succeed.

Ramp-up. Half a day for a competent Laravel engineer including staging verification and the permission seeder; one day if we need a custom page class, SSO-aware authorize(), and runbook updates. No specialist knowledge required.

TPM position. Approve as a low-risk operational convenience layer, conditional on: (a) it never being the only backup mechanism, (b) backup:monitor alerting existing independently, (c) delete/download scoped to a named role, and (d) a documented CLI restore path that does not depend on this plugin. The package itself is not the risk — the discipline around restore testing is.