Backup Laravel Package

Product Decisions This Supports

• Build vs. buy for backup/export plumbing. This package is a candidate to satisfy the "create an archive and put it somewhere" primitive instead of building filesystem/archive-handling code in-house. The decision it informs is narrow and concrete: do we write our own archive + destination layer, or adopt a small MIT library and own only the operational wrapper (scheduling, retention, alerting, restore drills).
• Roadmap: data portability and self-hosted/on-prem commitments. Export/backup capability is frequently a gating requirement for self-managed deployments, on-prem customers, and enterprise security reviews. This supports sequencing that work earlier or later based on deal pressure.
• Compliance and retention checkbox features. Customer-facing "download your data," "scheduled snapshots," and "retention policy" items are often sold as features but are mostly orchestration around an archive primitive. This package de-risks the estimate for those roadmap items.
• Tenant/account-level export and offboarding. Supports account deletion/offboarding workflows that require producing a portable archive before data is purged.
• Migration and onboarding tooling. Internal tooling that snapshots or exports state before/after migrations, tenant moves, or environment promotions.
• Incident readiness for internal tools. Low-cost safety net for admin panels, internal services, and non-critical datasets where a managed backup product is overkill.
• Explicitly not supported: positioning this as an enterprise-grade backup platform (no evidence of PITR, deduplication, encryption key management, immutable/WORM storage, or vendor SLA). Any roadmap item promising those must be scoped as net-new work, not "we adopted a library."

When to Consider This Package

Consider adoption when:

• The product is a PHP application with self-managed infrastructure, and the need is a primitive: build an archive, hand it to a destination, done.
• You are willing to wrap it behind an internal BackupService interface so the dependency is swappable in days, not quarters.
• Your team already owns — or is prepared to own — the operational layer: scheduling, concurrency, failure alerting, retention enforcement, storage lifecycle, and restore verification. The library does not remove this work.
• The first integration target is internal tooling or non-critical data, giving you a low-blast-radius pilot before customer-facing exposure.
• You have done diligence on the basics: PHP version support, test coverage, release cadence (latest release dated 2026-08-20, so verify the actual history), open issue responsiveness, and a security review of the dependency tree.

Look elsewhere when:

• You need point-in-time recovery, incremental/deduplicated backups, encryption-at-rest with managed keys, immutable storage, or cross-region replication. Those are platform concerns, not library concerns.
• Procurement requires vendor support, SLAs, SOC 2/HIPAA evidence, or a named maintainer with a support contract.
• The application is Laravel and the team wants batteries-included behavior (scheduling hooks, notifications, database dumpers, retention config). A more widely adopted, Laravel-native package will be cheaper to operate and easier to hire for.
• Data volumes are large or the system is distributed — database-native and infrastructure-native tooling will outperform a generic PHP archive library.
• Adoption risk is unacceptable for the use case. 25 stars and 0 dependents means essentially no external scrutiny, no community answers, and a real bus-factor exposure. Treat it as "small utility we vendor and can replace," never as a foundational dependency in a revenue-critical path.

Diligence checklist before committing: pin the version, run your own restore test, confirm the license (MIT — permissive, no copyleft concern), and record an exit plan in the ADR.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have recurring asks for data export, scheduled snapshots, and self-hosted backup guarantees — items that gate enterprise and on-prem deals but that we currently have no owned primitive for. This is a small, permissively licensed (MIT) PHP library that handles archive creation and delivery, letting us satisfy those asks with a fraction of the custom code and without locking us into a vendor. The trade-off is maturity: it has minimal adoption (25 stars, no dependent projects), so we would adopt it behind an internal interface, pilot it on internal tooling first, and keep the ability to swap it out. Recommended decision: approve a time-boxed pilot; do not represent it as an enterprise backup platform.

For engineering (the summary they need): Composable primitive for creating and archiving backups — we consume it inside a scheduled command and keep everything operational in our codebase: scheduling, locking, failure alerting, retention, storage credentials, and restore testing. Wrap it behind an internal interface, pin the version, and write an ADR with the swap criteria. Do not let it leak into business logic.

For security/procurement: MIT licensed, small dependency surface, no copyleft obligation. Not a substitute for an audited backup platform; we retain responsibility for key management, access control, and restore validation. Request a dependency review before any customer-data use.

Risk statement to state plainly: 0 dependents and 25 stars is a signal, not a dealbreaker. It means we are an early adopter and must budget for the possibility of maintaining a fork. If the roadmap ever depends on this package for customer-facing, regulated, or revenue-critical data, revisit and migrate.