Filament Google Drive Backup Manager Laravel Package

Product Decisions This Supports

• Backup/DR destination decision: whether Google Drive is an acceptable offsite target for the app's database and uploaded-file backups. This package turns that into a Filament configuration exercise plus a scheduled job, rather than a custom OAuth + Drive API integration.
• Build vs buy: adopt an OSS package vs. engineering a bespoke Drive backup pipeline. The package covers disk configuration, OAuth token lifecycle, scheduling, and an admin-facing UI — the parts that are tedious rather than differentiating.
• Roadmap: "backup & restore" as a shippable admin capability. v0.4.3 materially raises confidence here: it fixes a mode where backups silently failed on long-lived queue workers (Horizon with --max-time=0), so the feature can be trusted in a production queue topology rather than only in web-request context.
• Operational trust and support cost: the new explicit "stored Google account must be reconnected" error replaces an opaque 401 on the next Drive call. That converts a silent DR gap into an actionable signal — alertable, runbook-able, and debuggable by whoever is on call.
• Risk acceptance: the package is pre-1.0 (0.4.x). The decision this supports is not "no risk" but "bounded risk": pin the version and wrap it behind an internal backup interface so a future swap is a config change.

When to Consider This Package

Consider it when:

• You run Laravel + Filament and want scheduled backups written to Google Drive without owning the OAuth refresh-token dance and Drive client plumbing.
• You operate queue workers. v0.4.3 or later is effectively mandatory — earlier versions hold a stale cached disk and expired access token for the life of a persistent worker, producing 401 Invalid Credentials on every run even after reconnecting the account.
• You want a single-destination, single-account backup path with an admin UI, and you're comfortable with community OSS at a 0.x version.
• You already pay for Google Workspace/Drive storage and want to use it as the offsite copy rather than adding another vendor.

Look elsewhere when:

• You need multi-destination fan-out (S3/B2/GCS in addition to or instead of Drive), retention automation with legal hold, or restore workflows beyond what the package exposes.
• You are subject to compliance regimes (HIPAA, SOC 2, PCI) that require vendor controls and auditability you cannot get from a community package plus a consumer-grade Drive account.
• Your backup payloads are large enough that Drive API quotas and resumable-upload limits become the dominant engineering concern.
• You need point-in-time or streaming replication, or you are not on Filament.
• You require a supported SLA, or your team cannot absorb 0.x minor-version churn — budget migration time for 0.x bumps even though patch releases like this one are fix-only.

How to Pitch It (Stakeholders)

Executives: A small, low-cost addition that gives the admin panel a genuine offsite backup path to storage we already pay for. The latest release fixes a real reliability gap — backups running on background workers could quietly stop working after an OAuth token expired, and nobody would know until a restore was needed. That failure mode is now corrected, and the remaining failure case surfaces as a clear "reconnect the Google account" message we can alert on. Residual risk is modest: it's a pre-1.0 open-source dependency, mitigated by pinning the version and isolating it behind our own backup interface.

Engineering: A thin Filament integration over Laravel's filesystem and the Drive adapter. The non-trivial parts are OAuth token refresh and Laravel's per-process disk caching. v0.4.3 calls forget() on the resolved disk on every run so each backup mints a fresh access token — this is the fix for the Horizon stale-token 401 — and makeDriveService() now throws on a failed refresh-token exchange instead of letting a revoked token degrade into an opaque Drive error. No breaking changes in this patch: pin to ^0.4.3 and add an alert on the reconnect error. Keep the integration behind our own service interface so a future destination change (S3, multi-target) is configuration, not a rewrite.