OpenListTeam/OpenList

OpenList is worth a look if your files are scattered across Chinese net disks, OneDrive, S3 and local disks and you want one interface over them. It is a community-governed fork of AList, and its appeal is as much about who controls the code as about the feature set.

The problem

Typical setup: a Baidu netdisk account holds old photos, OneDrive holds work documents, an S3 bucket holds backups, and a local NAS holds everything else. Finding a file means remembering which service it lives on, opening that service's app, and often downloading it before playback. OpenList sits in front of those storages as a web file manager: you add each storage account once, then browse and preview files from one page. It also exposes WebDAV, so desktop and mobile clients can mount the aggregated view.

What's different

The mechanism is a Go server that wraps official SDKs and APIs for each storage backend. The README lists roughly forty supported backends, including Aliyun Drive, OneDrive, Google Drive, S3, WebDAV, Baidu Netdisk, Quark, 115, Mega and FTP/SFTP. Files are streamed or redirected rather than copied into a central pool; the README says it only does HTTP 302 redirects or traffic forwarding and does not store user data itself.

On top of the storage layer it adds previewing for PDF, markdown, code, office documents, images, video and audio, password-protected routes, package download, web upload and cross-storage copy. That turns a pile of accounts into something closer to a personal file portal.

There are real trade-offs. The storage list is broad, but each backend depends on that provider's SDK or API, and the disclaimer warns that using the software is at your own risk, including account bans or throttling. Many of the listed services are Chinese consumer net disks whose terms may not welcome this kind of gateway, so availability can track the provider's mood and not OpenList's release cadence.

The README also positions this as a fork of AList created over a trust dispute in the original project. That governance story is the reason the fork exists, but it does not by itself guarantee a particular maintenance level. The project is free, has no paid plans and relies on Cloudflare-provided charitable resources for docs and API services, according to its own notice.

Who should try it

Good fit: someone with several net-disk accounts and a home server who wants a single browsable index and WebDAV mount without moving terabytes of data. The Docker Deploy path makes it a container you can run alongside other self-hosted services, and the demo lets you see the interface before committing.

Poor fit: anyone expecting a consumer app-store product or a fully managed service. If your files already live in one ecosystem and you do not need cross-storage browsing, the extra account and token management adds work for little gain. If a provider's API change breaks a backend, you are dealing with a community project rather than a vendor support contract, and the README offers no SLA.

Requirements and limitations

You need somewhere to run the server, usually Docker, and you must configure credentials or OAuth for each storage you connect. Since it forwards traffic through the server, bandwidth and stability of that host matter for streaming large files.

The bigger ongoing cost is compatibility. The README's storage checklist is long, but each backend is tied to an external service; when a provider changes its API or tightens access, a storage can stop working until the community updates the adapter. Account safety is explicitly the user's responsibility, with account bans listed as a possible risk. The AGPL-3.0 license also matters if you plan to modify and redistribute it: derivative deployments are expected to stay open under the same terms.

HotRepo's take

HotRepo has one dated observation: on 2026-10-25 the repository was recorded on the daily board with 25,259 stars and a +34 gain that day. That single snapshot supports the repository's age and a moment of activity, but comparison over time is insufficient, so persistence of interest cannot yet be judged.

The concrete thing to verify before relying on it is whether the specific storage you need is still working, not just listed. Use the project documentation and the storage list in the README to check the backend and its configuration notes, and test it with a non-critical account first rather than migrating a primary drive.