Weave Code
Storage Laravel Package
styleci/storage
StyleCI Storage provides a simple, consistent abstraction for persisting and retrieving data across multiple backends. It integrates smoothly with Laravel and PHP applications, letting you swap storage drivers without changing your application code.
StyleCI Storage Is A Cached Secure Storage Provider
Frequently asked questions about Storage
- Is styleci/storage still maintained?
- No. The repository is published under the GrahamDeprecated GitHub namespace, which is an explicit signal that the maintainer has retired it rather than quietly abandoning it. There are zero stars, zero dependents, and no observed consumers, so no third party is validating or patching it. No security advisories will be issued against it and no CVE feed covers it, so treat it as unmaintained.
- How do I install styleci/storage in a Laravel application?
- The intended path is a Composer require followed by publishing the package config and registering its service provider, the same as any Laravel storage package. Before running composer require, confirm that the Packagist name styleci/storage actually resolves to GrahamDeprecated/Storage, because vendor-to-repo drift is a real supply-chain surface here. If the name no longer resolves cleanly, that is a stop sign rather than something to work around.
- Which Laravel and PHP versions does styleci/storage support?
- There is no published compatibility matrix, no test runs against modern Laravel, and no consumer bug reports to infer from. Assume PHP 7.x-era constraints and possibly a Flysystem v1 dependency until a composer why-not run proves otherwise. Validate against your actual PHP minor and Laravel major before committing, since a Flysystem v1 requirement alone disqualifies it from a current stack.
- Does styleci/storage actually encrypt data at rest?
- The package is described as a cached secure storage provider that encrypts payloads on write and decrypts on read, so the intent is encryption at rest. The critical question is where the keys come from: Laravel's Encrypter, a custom key derivation function, or an embedded constant. The third case is a stop-the-line finding and should be checked in the source before anything else.
- Does the cache layer in styleci/storage store ciphertext or plaintext?
- This is not documented and must be verified by reading the source. If the cache stores plaintext, the cache becomes a second, less-governed copy of sensitive data with its own TTL and eviction behaviour. Encrypt-then-cache is the only acceptable arrangement for anything sensitive, and you should confirm it explicitly rather than assume.
- Is styleci/storage safe to use in production?
- It sits in the highest-risk quadrant: an unmaintained, security-sensitive package where both caching and encryption fail silently rather than loudly. An abandoned package here is not a case of fixing it when it breaks, because you will not learn about the break. A future PHP or Laravel upgrade that changes serialization or Encrypter behaviour will surface as data corruption, not as a red build.
- What are the alternatives to styleci/storage for encrypted Laravel disks?
- Laravel's own Storage facade plus a thin custom decorator gets you the same result without importing someone else's internal conventions. Implement encrypt-on-write and decrypt-on-read against current Flysystem and Laravel primitives, with explicit key versioning, and you have the capability rather than the convenience. The honest read is that this package is a few hundred lines of glue over Storage::disk() and Crypt.
- Should I fork styleci/storage or depend on it directly?
- Treat it as a design reference first and a dependency only as a last resort. If a fork is genuinely required, fork under your own vendor namespace, pin the commit SHA, and mark the fork as yours in composer.json. Never depend on styleci/storage transitively through another package, because you would inherit the risk without noticing it.
- Can I swap storage backends without changing application code with styleci/storage?
- The abstraction layer is designed for exactly that, provided it is a clean decorator over Illuminate\Contracts\Filesystem\Filesystem or Flysystem. If it reaches into StyleCI-specific concerns such as its own cache-key conventions, hardcoded disk names, or an assumed queue topology, the fit degrades from dependency to reference implementation. Read the source to see which of those two it is.
- How do I test styleci/storage against my application before adopting it?
- Run a one to two day spike: clone the repository, run its test suite against your PHP and Laravel versions, and read the source end to end. Also validate cache behaviour against your actual driver, since Redis, database, and array stores differ around TTL and serialization. Confirm whether the deprecation is formal, such as an archived repo or a Packagist abandoned flag, before assuming a successor exists.
Weaver
How can I help you explore Laravel packages today?