Site Backup Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for backup/restore. Gives us a concrete buy candidate for a "site backup and restore" epic instead of hand-rolling dump + restore orchestration. Evaluate it on the restore half, not the backup half — dumping is commodity; restoring safely is the expensive part.
• Roadmap scoping: backup ≠ restore. The bundle's stated differentiator is a restore UI that verifies checksums and does not break the app mid-restore. That supports splitting the roadmap into "backup exists" (cheap) and "restore is safe and self-service" (the actual milestone), rather than treating them as one line item.
• Acceptance criteria for integrity. "Checksum integrity" lets us write a testable requirement — every backup is verifiable before it can be restored, and a mismatch blocks the restore — instead of the usual untestable "backups must be reliable."
• Admin/ops surface decisions. A Twig-rendered restore UI forces product questions we'd otherwise defer: is restore self-service for ops, or gated behind an engineer approval? Who can trigger it? Does it live in our admin panel or a separate console? These are product decisions, not implementation details.
• Use cases to test against: pre-deploy snapshots, staging refresh from production-like data, agency/on-prem client site rollback, migration abort-and-recover, DR readiness demonstrations.
• Explicit non-goals for this evaluation. Nothing in the package supports Laravel apps, multi-tenant per-tenant scoping, cloud/object-storage retention lifecycle, PITR, or encryption-at-rest. Do not let a pilot imply those are covered.

When to Consider This Package

Consider it when:

• The product is on Symfony 7.4 or 8.x with PHP 8.2+ and can absorb the ^7.0 || ^8.0 constraint. This is a Symfony bundle — it does not transfer to Laravel, where DI, service providers, and Blade differ enough that evaluation effort is better spent on a native option.
• You specifically need in-application restore, and the "app stays usable during restore" property is worth paying for. That is the one claim here that is genuinely hard to build.
• You can fund a time-boxed spike and a written go/no-go. The integration surface is conventional (bundle registration, config keys, routes behind your firewall, storage paths, Twig/Vite assets), so the spike is cheap.
• MIT licensing and a small, conventional bundle footprint fit vendor policy.

Look elsewhere when:

• Adoption risk is disqualifying. 0 stars, 0 dependents, no third-party usage, single maintainer. There is no external evidence of production use and no community bug surface. Also verify the reported last release date (2026-10-24) — a future-dated release is a data-quality signal, not a maturity signal.
• You need managed DR: provider snapshots, pgBackRest, Velero, object-storage lifecycle, retention policy, audit trail. Keep restore out of the application path entirely.
• You need multi-tenant isolation, per-tenant backup scoping, encryption-at-rest, SBOM, or a vendor SLA.
• Your compliance posture requires a supported vendor with named support obligations.

How to Pitch It (Stakeholders)

Executives. We have a low-cost candidate to close the "backup and restore" gap without building it. It's a small MIT-licensed Symfony bundle that performs full-site backups with checksum verification, and — the part that matters — offers a restore flow designed so the application does not break while a restore is in progress. Cost to evaluate is low; cost to adopt is currently unproven, because the project has no external users. Recommendation: fund a one-to-two-week spike with written exit criteria, not a roadmap commitment.

Engineering. Architecturally it's ordinary: a DI extension with configuration keys, a Twig-backed restore UI, Vite/TypeScript frontend assets, and tests colocated with behavior. Integration is register the bundle, mount routes behind our existing firewall and role model, point it at storage, and wire checksum verification into the deploy/rollback runbook. Our review must answer four things: (1) what locking or concurrency semantics actually back the "doesn't break the app mid-restore" claim; (2) what happens on interrupted restore — clean rollback or partial state; (3) how credentials and backup contents are protected; (4) whether restore can be triggered by anyone below admin.

The risk to state plainly is adoption risk, not technology risk. Zero stars and zero dependents means no production-user evidence and a bus factor of one. If the spike passes, mitigate mechanically: fork or vendor under MIT, pin the version, and add our own integration tests around backup creation, checksum mismatch, and interrupted restore. Define the exit criteria up front — restore a production-like dataset inside an acceptable window, no data loss on interruption, and a clean removal path if we walk away.