Capsule Laravel Package

Product Decisions This Supports

• Treating backup, restore, and disaster recovery as a first-class product capability rather than an afterthought: Capsule 3.0.0 supports application-consistent backups across database and filesystem data, with stronger restore validation before destination data changes.
• Build vs. buy: buying a Laravel-native backup package can be justified when the team needs encrypted archives, incremental backups, checksum-bound bases, recorded deletions, and recovery validation without building and maintaining bespoke backup tooling.
• Compliance and security roadmap: encrypted streaming backups (.capsule.enc) and standalone decryption support incident-response, audit, and data-protection requirements by reducing reliance on the original Laravel application for recovery.
• Operational resilience: standalone capsule-decrypt enables recovery outside the production application and backup catalog, which is valuable for break-glass procedures, legal/security review, and disaster recovery runbooks.
• Customer-facing or on-prem product use cases: teams shipping Laravel applications to regulated customers, managed hosting, or air-gapped environments can offer encrypted backup/recovery workflows with documented validation.
• Roadmap sequencing: the removal of Laravel 10/11 and PHP 8.1 support makes platform modernization a prerequisite; plan upgrade work before adopting v3 rather than treating it as a drop-in backup change.

When to Consider This Package

Consider Capsule 3.0.0 when:

• The product runs Laravel 12 on PHP 8.2+ or Laravel 13 on PHP 8.3+, and the team can meet the new extension requirements: zip, sodium, zlib, plus pdo_sqlite for SQLite backup/validation and sqlite3 for SQLite restoration.
• The team needs encrypted, streaming backups without staging a complete local backup archive, and can manage passwords and recovery dependencies separately from the application.
• Recovery validation matters: the release adds checks for archive paths, manifests, checksums, encrypted entries, and incremental bases before changing destination data.
• Incremental backup integrity is important: checksum-bound base archives, recorded deletions, and encryption/password compatibility checks reduce silent recovery failures.
• The organization can operate CLI-driven backup and recovery procedures, including --list and --dry-run review before restores, and can run recovery drills.
• The application needs named or numbered file-root directory preservation on restore; teams should verify layout changes before production upgrades.

Look elsewhere or defer when:

• The product still depends on Laravel 10/11 or PHP 8.1, or cannot install the required PHP extensions or an AES-capable libzip build.
• The team expects encrypted streaming archives to be directly openable by ordinary ZIP software. .capsule.enc files require compatible Capsule tooling and the backup password; decryption produces a plaintext ZIP that must be handled securely.
• The organization requires fully managed database snapshots or point-in-time recovery from a cloud provider rather than application-level backup orchestration.
• There is no operational ownership for secret management, recovery dependencies, local staging capacity, or restore testing. --no-local avoids a complete local backup archive, but SQLite snapshots and filesystem adapters may still use temporary storage.
• The team cannot tolerate the upgrade risk: older snapshot metadata or changes to encryption settings/passwords may cause the next incremental backup to start a fresh full base, and existing full and incremental archives must be kept together.
• Existing backups must remain recoverable exactly as before. v3 does not require converting existing backups, but teams must keep original archives and passwords and confirm the recovery procedure before upgrading production.

How to Pitch It (Stakeholders)

Executives: Capsule 3.0.0 strengthens backup security and recovery independence. Encrypted streaming backups reduce exposure of backup contents and filenames, while standalone decryption gives the organization a recovery path that does not depend on the original Laravel application or backup catalog. Stronger restore validation lowers the risk of restoring corrupted or incomplete data. The trade-off is an upgrade gate: Laravel 10/11 and PHP 8.1 are no longer supported, and required PHP extensions must be available. Approve this as a resilience and compliance improvement only after confirming platform readiness and running a recovery drill.

Engineering: v3 adds encrypted streaming backups via --no-local --encrypt, producing .capsule.enc archives without staging a complete local backup archive. Recovery requires compatible Capsule tooling and the backup password; decryption yields a plaintext ZIP that must be handled securely. Restore validation now checks archive paths, manifests, checksums, encrypted entries, and incremental bases before destination data changes. Incremental backups are checksum-bound and record deletions, with encryption/password compatibility checks. New-format restores preserve named or numbered file-root directories, so use --list and --dry-run before restoring. Plan for Laravel 12/PHP 8.2+ or Laravel 13/PHP 8.3+, required zip/sodium/zlib extensions, SQLite dependencies where applicable, and AES-capable libzip for standard AES ZIP encryption. Keep passwords and recovery dependencies separate from the application, retain existing archives and passwords, and validate the upgrade in a non-production environment before changing production recovery procedures.