Laravel Backblaze B2 Laravel Package

Technical Evaluation

Architecture fit. The package is a thin Laravel service provider plus a Flysystem adapter that registers a backblaze disk driver wrapping the Backblaze B2 PHP SDK. Architecturally it slots into the Storage facade the same way the S3 and local drivers do, so conceptually it fits any Laravel app that already uses Storage::disk(). The fit breaks down in practice: it targets Laravel 5 / Flysystem 1.x, which means modern Laravel (9/10/11, Flysystem 3.x) will not resolve the dependency graph. Its real architectural value today is as a reference implementation, not a dependency.

Integration feasibility. Low as a drop-in. Composer constraints will conflict on Laravel ≥6 and PHP ≥8. Even on Laravel 5, the B2 native API surface it wraps (authorize account → get upload URL → upload file → poll for file info) has evolved, and the vendored SDK is stale. Critically, Backblaze now exposes an S3-compatible endpoint, so Laravel's first-party s3 driver covers the same storage with zero third-party code. That removes the main reason this package existed.

Technical risk. High. Single maintainer, 53 stars, no releases in years, no security response path. Risks stack: unpatched transitive dependencies (SDK, Guzzle), no Flysystem 3 support (loses streaming, temporaryUrl, visibility, checksum verification), B2 auth-token expiry (24h) and upload-URL expiry handled inconsistently, and no multipart/resumable upload path for large objects. Adopting it means we inherit ownership of a fork on day one.

Key questions.

• Which Laravel/PHP versions are in scope, and is any of them pinned to Laravel 5?
• Do we need B2-native capabilities (bucket-ID-scoped application keys, B2-specific lifecycle rules) that the S3-compatible API can't express, or is S3 semantics sufficient?
• Object size distribution and request volume — do we need multipart uploads, presigned URLs, or parallel transfers?
• Is there an existing fork or internal adapter we can build on, and who owns it?
• What is the data-residency / compliance posture that pushed us to B2 rather than S3?

Integration Approach

Stack fit. Backblaze B2's S3-compatible API is the correct integration point. It maps 1:1 onto Laravel's built-in s3 disk (custom endpoint, region, key/secret, use_path_style_endpoint), keeps us on first-party, security-patched code, and preserves every Storage capability (streaming, temporary URLs, multipart). Reserve the native B2 driver only for a narrowly justified gap.

Migration path. Treat this as a storage-backend swap, not a package install:

1. Abstract: audit code for direct B2 SDK calls and raw Storage usage; force everything through Storage::disk('b2') with a named disk in config/filesystems.php.
2. Prove: stand up a non-prod bucket, run the S3-compatible config against it, and exercise the real access patterns (put/get, large file, presigned URL, delete, listing).
3. Cutover: dual-write or copy-then-flip, with a key-prefix scheme that keeps both backends addressable during the transition.
4. Decommission: remove the old package and its transitive deps from composer.json before the audit closes.

Compatibility. Verify CORS on the bucket for browser presigned uploads, confirm the endpoint/region string B2 expects, check whether the app relies on S3 features B2 approximates rather than implements (object lock, some ACL semantics, certain lifecycle transitions), and confirm TLS/proxy behavior through our egress path.

Sequencing. Discovery and spike (1 sprint) → config + adapter abstraction if any gaps (1–2 sprints) → non-prod validation and load test → production cutover behind a feature flag → dependency removal. If a genuine native-API requirement surfaces, fork-and-upgrade to Flysystem 3 becomes its own workstream with a named owner; do not let it block the S3 path.

Operational Impact

Maintenance. Path A (S3 driver): near-zero — maintained upstream by Laravel and AWS SDK, patched with routine composer update. Path B (this package or a fork): we own it permanently, including the B2 SDK, Flysystem adapter, and PHP 8+/Flysystem 3 port. That is a recurring engineering tax for a capability we can get for free.

Support. The package has no viable upstream support channel — one maintainer, minimal issue traffic, no SLA, no security disclosure process. Internal escalation means reading the B2 SDK source. Budget for that or avoid it.

Scaling. B2 itself scales well and its egress pricing is the reason to be here; the adapter is the constraint. Expect no connection pooling, naive retry/backoff, non-resumable uploads that fail on large objects over flaky links, and B2 API call caps (notably low free-tier daily bucket-list limits) that a poorly cached driver can trip. The S3 driver gives us the AWS SDK's retry, multipart, and transfer-manager behavior out of the box.

Failure modes. Auth-token expiry mid-batch (B2 tokens are short-lived and must be re-authorized); stale upload URLs causing intermittent 401s under concurrency; silent partial uploads with no checksum verification; Flysystem version skew surfacing as runtime method not found errors only on specific code paths; and, with an abandoned package, a transitive CVE with no patch path other than an emergency fork.

Ramp-up. Low for the S3-compatible route — any engineer who knows Laravel Storage is productive in a day, and the config is a dozen lines. High for the native-package route: expect 1–2 engineer-weeks to fork, port to Flysystem 3, and re-validate against the live B2 API, plus ongoing ownership. Onboarding docs should state plainly which backend the disk points at and why, so the next team doesn't rediscover this evaluation.

Recommendation. Do not adopt gliterd/laravel-backblaze-b2 as a dependency. Use Backblaze B2 through Laravel's native s3 disk, keep storage behind the Storage facade so the backend stays swappable, and revisit a native adapter only if a concrete capability gap is proven in the spike.