Weave Code
Laravel Google Cloud Storage Laravel Package
superbalist/laravel-google-cloud-storage
A Laravel filesystem driver for Google Cloud Storage, letting you use GCS as a native storage disk through Flysystem. Configure credentials and bucket settings, then read, write, and delete files with Laravel's familiar Storage API.
A Google Cloud Storage filesystem for Laravel
Frequently asked questions about Laravel Google Cloud Storage
- What does superbalist/laravel-google-cloud-storage do?
- It registers a gcs filesystem driver into Laravel's FilesystemManager so a Google Cloud Storage bucket can be used through the Storage facade. The actual storage work is delegated to superbalist/flysystem-google-storage on top of Flysystem v1. Beyond a disk entry in config/filesystems.php and the package's service provider, no application-layer changes are required.
- Which Laravel and PHP versions does this package support?
- It requires illuminate/support ~5.4|~6.0|~7.0|~8.0 and league/flysystem ^1.0, so it targets Laravel 5.4 through 8. Laravel 9 and above ship Flysystem 3, where the adapter interfaces changed, so Composer will not resolve the dependency there. PHP 8.1, 8.2 and 8.3 compatibility has not been validated because the last release was September 2020.
- How do I configure a Google Cloud Storage disk with this package?
- Add a disk entry to config/filesystems.php with the driver set to gcs, along with your bucket and project ID. Credentials are supplied through GOOGLE_APPLICATION_CREDENTIALS or the standard GOOGLE_CLOUD_* environment variables. After that you use Storage::disk('gcs') exactly like any other Laravel disk.
- Is superbalist/laravel-google-cloud-storage still maintained?
- No. The repository is archived and the final release was September 2020, so there is no security-patch path and no response to Google Cloud Storage API or auth-library changes. Transitive dependency CVEs will land on your application with no upstream fix. Treat the package as a scheduled migration rather than an ongoing dependency.
- Should I adopt this package for a new Laravel project?
- No. For new work use league/flysystem-google-cloud-storage, which Laravel documents as the first-party route to a gcs disk. The architecture is the same minus the abandoned wrapper, and the application-facing Storage::disk('gcs') contract is largely unchanged. Adopting the archived package just creates migration debt on day one.
- How do I migrate from this package to the first-party Google Cloud Storage adapter?
- Install league/flysystem-google-cloud-storage, register the gcs driver in config/filesystems.php, and delete any published config or service-provider override the old package required. Spike it on a branch and run your existing test suite plus storage-touching integration tests against a staging bucket. Diff behaviour on url(), temporaryUrl(), visibility, putFileAs and directory listing semantics before swapping the composer requirement. Keep the disk name gcs so application code stays unchanged; on Laravel 9+ this is mandatory, and on Laravel 8 it de-risks the framework upgrade.
- Does the package support signed URLs, temporary URLs and visibility?
- Those capabilities come from the underlying Flysystem adapter and are available on Flysystem 1 with Laravel 5.4 through 8. Signed URL generation, bucket-root prefixing and visibility mapping are, however, exactly where behaviour can diverge from the first-party adapter. Verify each one explicitly during a migration spike rather than assuming parity.
- What happens if I try to install this on Laravel 9 or 10?
- Composer will fail to resolve the dependency graph because the package pins league/flysystem ^1.0 and illuminate/support up to 8.0, while Laravel 9+ requires Flysystem 3. Forcing it with dependency overrides is not a fix, since the adapter interfaces changed and the driver will not work. Move to the first-party adapter instead.
- How do I find out whether my application depends on this package's internals?
- Search the codebase for references to Superbalist\ classes and to the package's service provider, because those are the only places a facade-level swap leaks. Inventory every disk, bucket and credential in use and note any package-specific behaviour that must be replicated. Most applications only touch Storage::disk('gcs') and need no code changes at all.
- What is the risk of keeping this package installed long term?
- High, and concentrated in two facts: Flysystem 1 is end-of-life and the package is archived, so there is no security-patch path. Google SDK drift will surface as transitive CVEs on your own dependency tree with no upstream fix. Sequence the migration inside your Laravel upgrade workstream, migrate non-production environments first, soak for a release cycle, then switch production behind the existing gcs disk name.
Weaver
How can I help you explore Laravel packages today?