OpenList: 45 storage backends in one Go binary, a naming dispute it cannot settle, and extras you must build yourself

AGPL-3.0 and a naming warning the project cannot enforce

The repository exists because of a dispute. Its own description reads "A new AList Fork to Anti Trust Crisis", and the disclaimer names specific lookalikes: OpenListApp/OpenListApp, plus paid proprietary software using the same or a similar name. It states that OpenList has no official association with any third-party derivative projects, that all software, code and services are maintained by the OpenList Team and freely available on GitHub, that downstream projects must not distribute OpenList-based code closed source or violate AGPL terms, and that commercial projects should pick another name. None of that is a mechanism. A disclaimer cannot revoke a name, block a download page, or shut down a paid app, because all it is a request recorded in one file of one repository. What a reader actually gets is a way to tell things apart: when you land on something called OpenList, check whether the source is OpenListTeam/OpenList and whether the LICENSE file is AGPL-3.0, because the project itself says lookalikes exist and that you may install one instead.

The compose file runs as uid 0 and creates world readable files under /etc/openlist

The docker-compose.yml at the repository root is short and specific. It mounts '/etc/openlist:/opt/openlist/data', publishes '5244:5244' and '5245:5245', sets user: '0:0', passes UMASK=022 and TZ=Asia/Shanghai, pulls openlistteam/openlist:latest, and sets restart: always. Two consequences fall straight out of those lines. user: '0:0' means the process inside the container is uid 0, so anything that gets code execution there has root in that namespace and can write anywhere beneath the mounted host directory. UMASK=022 is not a private default either: whatever the service creates under /opt/openlist/data is created readable by other users on the host. On a shared machine or a NAS with several accounts, that data directory is the part you have to lock down yourself; the shipped compose file does not do it.

Two ports get published and neither file says which service answers on which one

Both the compose file and the Dockerfile finish by exposing the same pair: EXPOSE 5244 5245 in the image, and the compose file publishes both to the host. The container entrypoint is entrypoint.sh, and the build stage runs bash build.sh release docker, but neither the compose file nor the Dockerfile labels a port with the protocol it carries. WebDAV appears in the feature list, and FTP and SFTP appear in the storage list as backends, yet neither file maps a port to a surface. If you put this behind nginx you are guessing which listener your WebDAV client should be pointed at, and guessing wrong looks like a mount failure rather than a wrong port. The safe move is to publish only the one you confirmed, bind the other to loopback, and decide deliberately whether a WebDAV surface belongs on a public address at all.

Offline download and multithread acceleration need a base image you choose yourself

The feature list promises Offline download and "Multi-thread downloading acceleration for single-thread download/stream". The Dockerfile shows how much of that is opt-in. The final stage runs on openlistteam/openlist-base-image:${BASE_IMAGE_TAG}, where the build argument defaults to base, and the header comment names the supported values as base (default), aria2, ffmpeg and aio. Two further arguments, INSTALL_FFMPEG and INSTALL_ARIA2, both default to false, and a later ENV line sets RUN_ARIA2=${INSTALL_ARIA2}. So by the Dockerfile's own comment the default image is base, without the aria2 or ffmpeg variants. Rebuilding with the aria2 or aio tag, or setting those arguments to true yourself, means taking on a base image whose contents are not in this repository, and the compose file here pins no such tag. The consequence is that aria2 and ffmpeg support are chosen at build time, and the compose file does not mention it.

Forty five backends share one credential store and upstream APIs nobody here controls

The storage checklist has 45 entries, running from Local storage and S3 through 189cloud, 139yun, DingTalk Docs, CNB and OpenList itself. Two details deserve a close read. Cloudreve is the only line written with a capital [X] while the other 44 use lowercase [x], and in GitHub Markdown both render as a checked box. OpenList also appears in its own list of storages next to GitHub, which means one instance can be pointed at another. go.mod shows what the breadth costs to build: the Azure and AWS SDKs, aliyun-oss-go-sdk, foxxorcat's mopan and weiyun SDKs, SheltonZhu's 115driver, city404's v6 public RPC proto, cloudsoda's go-smb2, fclairamb's ftpserverlib and ProtonMail's crypto stack all sit in one module. Every one of those providers can change its own API, and the version pin in go.mod freezes the SDK, not the provider. Nothing here maps provider changes to broken drivers, so treat a silent listing failure as a provider change first.

go.mod wants Go 1.26 and there is no build command to copy

The module line is github.com/OpenListTeam/OpenList/v4, the go directive reads 1.26.0, and the toolchain line pins go1.27.3. That is a hard constraint for anyone compiling instead of pulling a binary: your Go has to be at least 1.26, and the toolchain line asks for 1.27.3. The top level has everything a Go project needs: main.go, cmd/, internal/, pkg/, server/, drivers/, public/, a Dockerfile.ci, build.sh, a .air.toml for live reload and renovate.json for dependency bumps. The README opening sections print no go build or go install line, and the project points to its documentation at doc.oplist.org. Two direct routes are visible in the repository. Take a tagged binary from the releases page, where v4.2.9 is dated 2026-10-25 and v4.2.8 is dated 2026-10-24. Or read build.sh and reproduce its release target. A third route looks convenient and is not: the compose file pulls the latest tag, and the releases list also carries a floating tag named beta dated 2025-11-11, so pin a version number rather than whatever latest resolves to.

Password protected routes and visitor uploads are two halves of one documented switch

Two adjacent lines in the feature list pull in opposite directions. One reads Protected routes (password protection and authentication). The next reads Web upload(Can allow visitors to upload), delete, mkdir, rename, move and copy. As written, visitor upload is a parenthetical inside the same web management feature that also carries delete, rename, move and copy. The feature list does not say which operations beyond upload visitors can be granted or how they combine with protected routes, so check that in the documentation at doc.oplist.org before enabling visitor uploads on an instance that also fronts private drives. Settle the route configuration before you add the first storage, not after.

Nothing here settles OpenList against rclone, CloudDrive2 or the project it forked

It calls itself a fork, it carries an AGPL-3.0 LICENSE file, and it ships a driver list of roughly four dozen entries. For what it changed relative to AList or how it differs from rclone or CloudDrive2, the project points readers to its documentation at doc.oplist.org. The v4 in the module path tells you the API surface is at a major version four and nothing more. So the driver count is the only comparative evidence you get, and driver count is a poor proxy: this project is built around browsing, previewing, permalinks and direct download in a browser. What it cannot tell you is which of the three fails first against your provider, because there is no compatibility matrix, only a checklist.

Editorial conclusion

OpenList fits an operator who wants one browser-facing window onto many cloud drives and is willing to run the thing themselves. The fork is genuinely active, with v4.2.9 tagged on 2026-10-25 and a push on 2026-11-02, and the deployment details in the repository live in the Dockerfile and compose file, with further documentation at doc.oplist.org. Before deploying, check which base image tag you actually pulled, remember the shipped compose file runs the service as uid 0 with UMASK=022 against the host directory /etc/openlist, and decide which of the two published ports you intend to leave reachable.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. OpenListTeam/OpenList on GitHub
3. Project website
4. README
5. Releases