Local Storage Adapter Extension Laravel Package

Product Decisions This Supports

• Files module storage strategy for PyroCMS 3 / Streams Platform deployments. This package is the local-disk driver for the Anomaly Files module: it decides where uploaded assets land (server filesystem) and how they're resolved. If your product is a self-hosted or on-premise PyroCMS build, this is the default "no cloud dependency" storage path.
• Build vs. buy on storage abstraction. The package is a thin adapter over a local filesystem contract — small surface area, MIT-licensed, no proprietary hooks. The real decision it informs is whether to (a) keep the vendor adapter, (b) vendor/fork it into your codebase, or (c) replace it with Laravel's native Storage facade + Flysystem local driver. Given zero dependents and a 2015 last release, the rational PM call is (c) for greenfield and (b) for maintenance of existing installs.
• Cloud-vs-local hosting roadmap. It anchors the "runs entirely on customer infrastructure, no S3/GCS egress" story — relevant for regulated, air-gapped, or cost-sensitive segments where per-GB object storage billing is a sales objection.
• Migration/technical-debt scoping. Its staleness (last release Aug 2015, no releases since, zero stars/dependents) is a concrete line item in any "upgrade the CMS stack" epic: you cannot assume upstream patches, so plan to absorb maintenance.
• Feature gating around file handling. Anything you build on top of the Files module (thumbnails, versioning, per-tenant directories, CDN offload) inherits this adapter's constraints; knowing it's local-only bounds which storage features are feasible without an additional driver.

When to Consider This Package

Consider it when all of the following hold:

• You are already running (or inheriting) a PyroCMS 3 / Anomaly Streams Platform application where the Files module is the file-management layer and this adapter is the wiring it expects.
• Your deployment target is a single-server or shared-filesystem topology where local disk is the correct and intended storage backend (on-prem, air-gapped, dev/test parity, or low-volume internal tooling).
• You are pinning dependency versions and can freeze a compatible Laravel/Streams combination — you are not expecting upstream fixes, security patches, or new features.
• The cost of a fork is acceptable: the code is small, MIT-licensed, and forkable, so you can own it internally if needed.

Look elsewhere when:

• You are building new software. Laravel's first-party Storage facade with the Flysystem local adapter covers the same ground with active maintenance, documentation, and a modern API — there is no product reason to adopt a decade-old, zero-dependent adapter.
• You need multi-cloud or CDN-backed storage, signed URLs, streaming uploads, or lifecycle policies. This adapter does not provide them; you need an S3/GCS-compatible driver.
• You require a supported dependency with an SLA, security disclosure process, or active maintainer. Zero dependents and no releases since 2015 mean no community safety net.
• You are on a PHP/Laravel version newer than the package's era and cannot verify compatibility — the integration risk likely exceeds the integration value.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed open-source component that lets our CMS store uploaded files on our own servers rather than in a cloud bucket. It costs nothing to license and supports an "all data stays on customer infrastructure" positioning that helps in regulated and on-premise deals. The catch is maintenance: it was last released in 2015, has no active user base, and receives no upstream updates. Treat it as a legacy, internally-owned component, not a vendor dependency. My recommendation is to keep it only where it already runs, budget a modest engineering effort to fork or replace it during the next platform upgrade, and standardize new work on Laravel's built-in storage layer.

For engineering: It's a thin local-disk adapter for the Anomaly Files module — small API surface, MIT, easy to read and vendor. It's effectively unmaintained (last release 2015-08-01, zero dependents), so we should assume no upstream fixes and either pin-and-fork or migrate to Storage/Flysystem local. No lock-in risk given the license and size; the risk is purely maintenance and version compatibility. Please confirm the supported PHP/Laravel matrix before we commit it to any roadmap item.