Ali Oss Storage Laravel Package

Product Decisions This Supports

• China-region feature delivery. Choosing a storage backend for user-generated content, documents, avatars, or exported reports when the product is hosted on Alibaba Cloud. This package is the last mile that makes Aliyun OSS usable through Laravel's native Storage facade, so "can we ship media uploads in the CN environment?" becomes a config decision rather than a sprint of custom SDK work.
• Build vs. buy (adopt vs. write). Roughly 500 lines of glue vs. 522 stars of prior art. The honest comparison is not "this package vs. nothing" but "this package vs. half a day of a senior engineer wrapping the official aliyuncs/oss-sdk-php in a Flysystem adapter." The 2.1.0 maintenance release shifts this marginally in favor of adoption — someone is still fixing real bugs in this adapter, including endpoint handling, which is the single most common source of broken OSS integrations — but it does not lower the cost of long-term ownership.
• Cloud vendor strategy / multi-cloud posture. If the roadmap includes a CN launch alongside an existing AWS/S3 footprint, the decision is whether OSS becomes a first-class disk alongside S3 or a special case. Using the Storage facade abstraction keeps that option open — an argument for this package as a thin adapter only if we commit to never leaking OSS-specific calls into domain code.
• Cost and compliance decisions. OSS is typically cheaper than equivalent S3 capacity in-region and satisfies data-residency expectations for CN users. This supports a "store CN user data in CN object storage" position that is easy to defend in a security review.
• Use-case fit: private buckets with signed URLs for customer documents, user media pipelines, nightly database/asset backups, and static asset offload behind Aliyun CDN — all standard Storage operations, all within this package's likely capability envelope.
• Roadmap gating — revised. The prior decision-relevant fact was "last release 2018-04-02." That is now superseded: a 2.1.0 bugfix release has shipped, addressing endpoint-related errors and directing users to ^2.1. This downgrades "abandoned dependency" from a likely disqualifier to an open question, and adds two new decision items: (a) whether we pin ^2.1 specifically — older 1.x pins carry the endpoint bugs the release fixes — and (b) whether one bugfix release constitutes a maintenance track record. It does not. Keep adoption as a time-boxed evaluation, but reclassify it from "probably dead" to "lightly maintained, unverified."

When to Consider This Package

Consider it when:

• The product is on Laravel 5.x–8.x-era code, or a spike confirms compatibility with the version in use. This remains the gating unknown; 2.1.0 is a bugfix release and tells us nothing about Flysystem major-version support.
• Aliyun OSS is already the chosen backend — the decision is settled and this is only the adapter.
• Needs are conventional: put, get, exists, delete, url, temporaryUrl, directory listing. No multipart resumable uploads, no server-side image processing, no STS/temporary-credential flows for browser-direct uploads.
• The team is small and speed to a working CN upload path matters more than adapter elegance.
• All OSS access is confined to a thin internal service/repository, so swapping adapters later is a contained change.
• You pin ^2.1 explicitly. Do not inherit an older constraint from a previous evaluation — the endpoint fixes are the reason to be on this line at all.

Look elsewhere when:

• The codebase is Laravel 9+ / Flysystem 3. Migration-era packages are usually incompatible, and the failure mode (silent breakage in file URLs or visibility handling) is expensive to discover in production. Prefer a maintained Flysystem adapter or a short in-house wrapper over the official SDK. A 2.1.0 bugfix release is not evidence against this risk — versioning here tracks the package, not the Flysystem generation underneath it.
• You need features beyond filesystem basics: chunked/multipart upload for large media, callback-driven processing, bucket lifecycle and archive tiers, cross-region replication. These belong in the official SDK, not a storage driver.
• Security or procurement review requires an actively maintained dependency. A single recent bugfix release is a data point, not a cadence: ask for the commit history across the last 12 months, issue response times, and whether 2.x has a stated support window. If the answer is "one release after a long gap," a single-maintainer package will still likely fail that gate regardless of code quality. MIT licensing clears the legal question; maintenance does not.
• The organization already standardizes on a different cloud. Mixing providers to reuse one adapter is the wrong trade.
• You cannot absorb the cost of forking. If the package needs patches for the current Laravel version, you now own a fork — budget for it explicitly or decline.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can enable file and media storage for our China-region users in days instead of weeks by adopting an open-source, MIT-licensed adapter that plugs Aliyun's object storage directly into our existing Laravel storage layer. The project shipped a maintenance release — 2.1.0 — that fixes endpoint-related errors, so the "is this library dead?" concern I flagged earlier is materially weaker than it was, though one release is not yet a track record. There is no license cost, no vendor lock-in at the code level, and it keeps us free to run the same product on AWS elsewhere. I'm still recommending a time-boxed technical validation before we commit it to the roadmap, with a fallback of writing a thin wrapper around Alibaba's official SDK — estimated at one to two engineer-days. The decision needed is approval for that validation spike, not for the dependency itself.

For engineering (the ask): Spike it behind the Storage facade, pinned to ^2.1 — do not evaluate against an older 1.x constraint, since endpoint handling is precisely what 2.1.0 changed. Install, configure a disk in filesystems.php, exercise put/get/exists/delete/url/temporaryUrl against a test bucket on our target Laravel version, and confirm behavior for visibility, path prefixes, and public vs. private URLs. Given the release notes, spend deliberate time on the endpoint matrix: internal vs. public endpoint, custom domain, and region-specific hosts — verify url() and temporaryUrl() produce resolvable links in each case, not just that they return a string. Success criteria: no changes to domain code, and an interface boundary that lets us replace the driver without touching callers. If the spike fails on Flysystem compatibility, we stop and build the ~150-line adapter against aliyuncs/oss-sdk-php instead — same facade contract, no fork, no orphaned dependency. Either way we get a storage abstraction we control; the package is a shortcut, not an architecture.