Laravel Vanguard Laravel Package

Product Decisions This Supports

• Tenancy architecture: v2.7’s VANGUARD_TENANCY_DATABASE_MODE=single lets a PM support a shared-database SaaS model without forcing a database-per-tenant migration. It clarifies the product boundary (database backed up once at the landlord level; tenant backups cover files only) and avoids over-engineering tenancy for apps that do not need physical isolation.
• Compliance and data-protection roadmap: Opt-in age encryption (VANGUARD_ENCRYPTION_ENABLED) and dedicated backup/restore connections give concrete answers for security reviews, especially PostgreSQL Row-Level Security environments where a dump taken as the application role is incomplete. Encryption keys are supplied only at restore time, which supports key-management policies rather than embedding secrets in storage.
• Infrastructure and cost decisions: Native Cloudflare R2 support (VANGUARD_R2_*) and an S3-compatible disk abstraction allow a build-vs-buy decision on remote storage without writing custom adapters, and can reduce egress costs versus default S3 destinations.
• Operational reliability as a product requirement: The pg_dump/server major check (warn or strict) turns a silent backup-corruption risk into an explicit release or runbook decision. The health screen reporting both majors gives support and on-call teams a shared source of truth.
• Roadmap and scope control: v2.7 deliberately excludes single-tenant row restore from a shared database and refuses encrypted restores from the HTTP endpoint/job. A PM can use these boundaries to plan follow-on work—key escrow, UI-driven restore, row-level extraction—rather than assuming they are already covered.
• Build vs buy: Every opt-in feature ships with safe defaults and no config republish requirement. That lowers the cost of adopting the package over bespoke scripts, while the install drift report and explicit failure modes reduce long-term maintenance toil. Use cases include multi-tenant Laravel SaaS, regulated deployments needing encrypted archives, and platform teams that want a health-checked backup surface without owning dump/restore orchestration.

When to Consider This Package

Consider Vanguard when:

• The product is a Laravel application with multi-tenancy, particularly PostgreSQL with Row-Level Security, and needs scheduled landlord and tenant backups, restore endpoints/jobs, a health dashboard, and pluggable remote storage.
• The team wants opt-in encryption at rest with explicit refusal of plaintext fallback, or wants to target Cloudflare R2 or an S3-compatible store without maintaining custom filesystem adapters.
• The tenancy model is shared-database and the team accepts files-only tenant backups in that mode; or the model is database-per-tenant and dedicated backup/restore connections are needed to satisfy RLS and least-privilege requirements.
• Operational maturity matters: install drift reporting, loud failures for missing binaries or recipients, and PostgreSQL major-version checks are valued over minimal configuration.

Look elsewhere when:

• The product needs point-in-time recovery, WAL archiving, or incremental/differential backups beyond periodic full dumps.
• The roadmap requires restoring a single tenant’s rows out of a shared database, or requires encrypted restores from the HTTP API/job rather than the console with an operator-supplied identity file.
• The team expects managed database snapshots (e.g. RDS) to be the primary backup mechanism, or the application is not Laravel/PHP.
• The product needs a fully hosted backup UI with built-in key escrow and per-tenant self-service restore; Vanguard’s v2.7 boundaries intentionally leave those as application or follow-on concerns.

How to Pitch It (Stakeholders)

To executives: Vanguard v2.7 reduces compliance and operational risk without forcing a tenancy migration or a config rewrite. Encryption at rest, dedicated backup roles for RLS environments, and explicit failure modes instead of plaintext fallback give auditors and customers concrete answers. Cloudflare R2 support can lower storage egress costs, and the opt-in defaults mean no forced upgrade work for current deployments. This is a build-vs-buy decision that favors buying: the package now covers backup correctness, storage flexibility, and install drift reporting that would otherwise become internal tooling.

To engineering: The release is deliberately non-breaking for applications that use Vanguard directly: defaults preserve 2.6.1 behavior, no migration or config republish is required, and tests cover each default. The meaningful engineering choices are opt-in—dedicated connections for RLS-correct dumps, shared-database tenancy mode, age encryption, PostgreSQL version checks, and R2 disks. The only package-extender impact is the optional fourth parameter on BackupManager::createRecord() and the need for subclasses that write their own backups to call assertEncryptionReady() before dumping or archiving.

To security and compliance: Encrypted archives are opt-in, use age recipients, and never store the private key; restores require an operator-supplied identity file or stdin. Missing binaries or recipients fail before the dump, with no plaintext fallback, and encrypted backups are refused by the restore endpoint and job with a 400 that names the console command. The new authentication documentation clarifies that the dashboard requires a logged-in user by default while authorization remains in the application via Vanguard::auth(), with guidance for platform-operator-only access in multi-tenant deployments.