- Does websight/l5-google-cloud-storage work with Laravel 9, 10, or 11?
- Not as a drop-in. The package is scoped to Laravel 5 and pins a Flysystem 1.x era GCS adapter plus an old google/cloud-storage client, while Laravel 9 and later ship Flysystem 3.x with a materially different adapter interface. Composer will not resolve it cleanly against current constraints, so modern applications should reimplement the same glue against league/flysystem-google-cloud-storage.
- How do I install websight/l5-google-cloud-storage?
- Require it with Composer, then register the package service provider in config/app.php, since it predates Laravel's auto-discovery metadata conventions. Publish or hand-copy the package config into config/filesystems.php as a new disk entry. On Laravel 5.5 and later you may still need to add the provider manually and merge the config yourself.
- How do I configure a Google Cloud Storage disk with this package?
- Add a disk to config/filesystems.php whose driver matches the binding name the provider registers, and point it at your bucket, project ID, and service account JSON key path. Because the configuration shape mirrors the old Flysystem GCS adapter, expect keys such as project ID, key file path, and bucket name. Verify the exact key names against the package's own config file, since guidance has drifted from current adapter versions.
- Is this package still maintained?
- No. Its last release was September 2016, it has roughly 36 stars and no dependents, and there is no test suite or CI configuration to indicate compatibility guarantees. Treat it as reference source material rather than a dependency your application relies on for updates or security patches.
- What should I use instead for Google Cloud Storage on Laravel 9 and newer?
- Register a GCS disk using league/flysystem-google-cloud-storage together with the current google/cloud-storage client, and write a small custom Storage driver in a service provider. That is roughly fifty lines of glue and removes the dependency on this package entirely. Use this repository only as a reference for provider registration and config key naming.
- Can I fork and modernize this package?
- Yes. The MIT license makes forking straightforward and the code surface is tiny, so the blast radius is bounded. You would bump the Flysystem and GCS SDK constraints, port the provider to Illuminate Support ServiceProvider conventions with auto-discovery, add a config publish stub, and pin versions. The tradeoff is that you then own the fork through every future major version of the Google Cloud Storage SDK.
- Does this package support signed URLs, resumable uploads, or per-object ACLs?
- The adapter is thin: it only surfaces what Laravel's Storage abstraction exposes, so signed URLs, resumable uploads, object lifecycle and retention headers, and fine-grained ACLs are not available through it. If you need those features, work directly with the Google Cloud Storage client rather than through a Flysystem disk. That limitation is one more reason to build your own driver on the maintained adapter.
- Does it support Workload Identity Federation or the GKE metadata server instead of a JSON key file?
- The package's configuration pattern centers on a service account JSON key path, which predates widespread adoption of workload identity and short-lived credentials. Stale guidance here risks encouraging long-lived key files instead of federation or metadata-server credentials. Check what your platform standard mandates first; current adapters and the modern SDK handle application default credentials far better.
- Are there any tests or CI for this package?
- No. The repository shows no test suite and no CI configuration, so nothing indicates verified compatibility with any specific Laravel or Flysystem version. If you fork it, plan to write your own integration tests, for example a fake Storage disk for unit coverage plus a smoke test against a real or emulated bucket before deploying.
- Is it safe to run this package in production?
- The risk is high but bounded: the most likely outcome is that you rewrite the glue, not that your data gets corrupted. The real concerns are abandonment, an unsupported dependency stack with security-relevant auth library drift, and credential handling that favors static key files over workload identity. For anything on Laravel 8 or newer, treat it as source material rather than a production dependency.