- How do I install gliterd/laravel-backblaze-b2?
- Install it with Composer using composer require gliterd/laravel-backblaze-b2. On Laravel 5 the package's service provider registers a Backblaze B2 filesystem driver, and you then add a disk entry in config/filesystems.php with your B2 key, secret, and bucket details. Because the package targets Laravel 5 and Flysystem 1.x, installation will fail on modern Laravel versions due to dependency conflicts.
- Does gliterd/laravel-backblaze-b2 work with Laravel 9, 10, or 11?
- No. The package targets Laravel 5 and Flysystem 1.x, so Composer will not resolve it against Laravel 9, 10, or 11 and their Flysystem 3.x dependencies. For modern Laravel, use the framework's first-party S3 driver pointed at Backblaze B2's S3-compatible endpoint instead. That keeps you on maintained upstream code and preserves Storage features such as streaming, temporary URLs, and multipart uploads.
- How do I use Backblaze B2 with Laravel's Storage facade?
- With this package, you configure a disk in config/filesystems.php using the driver it registers, then call Storage::disk('b2')->put(), get(), delete(), and similar methods just like any other Laravel disk. The package is a thin service provider plus a Flysystem adapter that wraps the Backblaze B2 PHP SDK. In modern Laravel, the same facade workflow is better achieved with an s3 disk configured against B2's S3-compatible API.
- What is the best alternative to this package for Backblaze B2 in modern Laravel?
- Use Laravel's built-in s3 disk driver with Backblaze B2's S3-compatible endpoint, including your B2 key, secret, region, endpoint, and path-style endpoint settings. This avoids third-party code, stays on security-patched first-party packages, and supports streaming, temporary URLs, and multipart uploads. Reserve a native B2 driver only if you have a specific B2-only requirement that the S3-compatible API cannot express.
- Which Laravel and PHP versions does laravel-backblaze-b2 support?
- The package is built for Laravel 5 and Flysystem 1.x and will conflict with Laravel 6 and newer as well as modern PHP 8 environments. Its vendored Backblaze B2 SDK is also stale, which adds transitive dependency risk. Confirm your Laravel and PHP constraints before attempting installation, and expect Composer resolution failures on current stacks.
- Can I generate signed or temporary URLs with this package?
- The package advertises signed URL support through the Backblaze B2 native API. However, it does not provide the Flysystem 3 temporaryUrl behavior that modern Laravel expects, and B2 auth-token and upload-URL expiry handling in the package is inconsistent. For predictable presigned URLs, use the S3-compatible driver instead.
- Does this package support large file uploads to Backblaze B2?
- The package advertises large-file upload support, but the technical evaluation notes that it lacks a modern multipart or resumable upload path and relies on a stale B2 SDK. That makes it a risky choice for large objects or high request volumes. Laravel's S3 driver against B2's S3-compatible endpoint provides multipart upload support on maintained code.
- Is gliterd/laravel-backblaze-b2 safe to use in production?
- The project has a single maintainer, modest adoption, no releases in years, and no clear security response path. Its unpatched transitive dependencies, lack of Flysystem 3 support, and inconsistent token expiry handling create high technical risk. Adopting it effectively means owning a fork from day one, so most teams should prefer the S3-compatible route.
- How do I migrate from this package to Laravel's S3 driver on Backblaze B2?
- Treat it as a storage-backend swap: audit code for direct B2 SDK calls and raw Storage usage, then route everything through a named disk such as Storage::disk('b2'). Configure an s3 disk with B2's endpoint, region, key, secret, and path-style endpoint, validate real access patterns in a non-production bucket, and cut over with dual-write or copy-then-flip. Remove the package and its transitive dependencies from composer.json once the migration is verified.
- Do I need native Backblaze B2 features that the S3-compatible API cannot provide?
- Most Laravel applications only need object put, get, delete, listing, presigned URLs, and multipart uploads, all of which the S3-compatible API supports. Native B2 capabilities such as bucket-ID-scoped application keys or certain B2-specific lifecycle rules may justify a native driver, but that should be a narrowly scoped exception. If you truly need them, plan a fork upgraded to Flysystem 3 with a named owner rather than blocking the S3 path.