Filament Spatie Laravel Backup Laravel Package

Product Decisions This Supports

• Build vs. buy for an internal ops surface. The core backup engine (spatie/laravel-backup) is already a de facto standard and is not what you're buying here. What you're buying is ~1–3 dev-days of a Filament page: list, create, download, delete, polling. Treat it as a UI accelerator, not an architecture decision.
• Roadmap sequencing for "operational hygiene" work. Backup admin screens are a recurring line item in enterprise procurement questionnaires, SOC 2 / ISO evidence packs, and internal security reviews. This package lets you close that line item in a single ticket rather than a sprint, freeing roadmap capacity for differentiating work.
• Self-service vs. gated operations. The plugin supports an authorize() closure plus explicit create-backup / download-backup / delete-backup permissions. That's a real product decision: do support engineers get one-click backups, or is this admin-only? Decide before shipping, because the permission seeder is manual work your team owns.
• Scope boundary for disaster recovery. This is backup creation and browsing, not restore. If your product commitment is "we can restore within RTO X," this package is at most the evidence-gathering layer — the actual RTO guarantee still lives in infra (managed DB PITR, snapshot policies, offsite replication). Do not let a backup UI be mistaken for a DR strategy in stakeholder comms.
• Multi-tenant / multi-language admin panels. Publishable translations and per-panel plugin registration make this cheap to include in panels serving non-English operators, which matters for EU/LATAM expansion decisions.
• Use cases where this is the clear win: internal admin tools, SMB SaaS with a Filament back office, agencies shipping client portals on Filament, single-tenant Laravel apps where an ops person (not a DBA) needs to pull a database dump before a risky migration.

When to Consider This Package

Adopt when all of the following hold:

• You already run Filament and spatie/laravel-backup (or are willing to adopt Spatie's config wholesale — this package does not abstract it).
• Your team is on a Filament version the package currently supports; verify against the release notes before committing, since Filament majors move fast and this is a thin wrapper that breaks first.
• Your backup need is operational convenience — "grab a dump before deploy," "show auditors we take backups" — not a guaranteed RTO/RPO.
• You accept a single-maintainer, MIT, ~278-star dependency in a privileged admin surface. Pin the version and budget for the possibility of forking. Low blast radius (it's a page, not a data layer), so the downside is contained.
• You can tune timeout(), noTimeout(), and usingQueue() deliberately. Large databases through a Livewire request are a real failure mode; if your DB is multi-GB, back up via queue + a dedicated worker, and consider whether the download path (streaming a large archive through your app server) is acceptable or whether operators should fetch from the disk directly.

Look elsewhere when:

• Restore is in scope. Spatie's package is backup-only; restoring is a manual, documented process. If you need point-in-time restore or a restore UI, this is not the product.
• You need scheduling/retention management in the UI. Retention and schedule live in config/backup.php and Laravel's scheduler. If non-technical stakeholders must edit retention policies, you're building that yourself.
• Compliance requires immutable, WORM, or air-gapped storage with audit trails. This writes to whatever disk Spatie is configured with. Audit logging here is Filament's default activity at best.
• You're not on Filament. The entire value is the UI; without Filament there's nothing to adopt — use Spatie directly.
• Infra-level backups already satisfy the requirement and nobody asked for a UI. Adding a privileged "delete backup" button to an admin panel is a new risk surface. Only add it if a human workflow genuinely needs it.
• Your team already has a Filament page convention and the marginal cost of hand-rolling this is under a day. At that point you're trading maintenance of your own 150 lines for maintenance of someone else's.

How to Pitch It (Stakeholders)

To executives / leadership: This is a low-cost, low-risk close-out of a recurring compliance and operational checkbox. It puts backup creation, browsing, and download behind role-based permissions inside the admin panel we already run — no new vendor, no new infrastructure, no new contract. It reduces dependency on engineers for routine operational tasks (pre-migration snapshots, auditor requests) and gives us a demonstrable control for security reviews. It is MIT-licensed and removable in an afternoon, so the downside is bounded. Important framing: it complements, and does not replace, our infrastructure-level backup and disaster-recovery posture.

To engineering: One Composer dependency plus a plugin registration in AdminPanelProvider. It respects your existing spatie/laravel-backup config — disks, retention, notifications, and schedule are unchanged; only the trigger surface is new. Navigation, polling interval, queue, timeout, and page authorization are all configurable via fluent plugin methods, so no forking is required for normal customization. It exposes three named permissions (create-backup, download-backup, delete-backup) that we seed ourselves, and an authorize() hook for panel-level gating — so access control stays ours. Known constraints to plan for: it does not restore backups, it does not manage schedules or retention, and large-archive downloads stream through the app server, so we should route backup jobs to a dedicated queue and validate against our largest database before rollout. Verify Filament version compatibility and pin the dependency; this is a thin wrapper maintained by a single author, so treat it as a page we could vendor into our own codebase if it ever stalls.