OpenList: an AList fork that mounts 40+ cloud drives behind one WebDAV endpoint

What OpenList solves, and who it is actually for

Most people accumulate cloud accounts rather than choose one. A Baidu Netdisk account from years ago, a OneDrive tied to a work tenant, an S3 bucket, a home NAS reachable over SMB. Each has its own client, its own search, its own sharing rules. OpenList is a single Go binary that treats all of them as mount points in one virtual file tree, then exposes that tree over HTTP and WebDAV.

The project describes itself as a fork of AList, and the fork rationale is governance rather than features. The README calls it a community-driven fork "built to defend open source against trust-based attacks." The disclaimer goes further: the team states that OpenList has no official association with third-party derivative projects such as OpenListApp/OpenListApp, and that no paid plans or commercial deployments exist. For a self-hoster deciding where to put credentials for a dozen cloud accounts, that statement about who controls the code is the actual pitch.

The audience is narrow and specific. You need to be comfortable running a container, exposing a port, and handing the application OAuth tokens or app passwords for storage providers. If you want a desktop sync client, OpenList is not that; it is a server that other clients talk to over WebDAV or the web UI.

How the storage drivers, WebDAV and the web UI fit together

The repository layout tells you most of the architecture. There is a drivers/ directory at the top level, one implementation per storage backend, and a server/ directory that holds the HTTP surface. The Go module path in go.mod is github.com/OpenListTeam/OpenList/v4, and the dependency list reads like a catalog of provider SDKs: Azure Blob, Aliyun OSS, AWS S3, ProtonMail's crypto libraries, a 115 driver, an SMB2 client, a WebDAV stack.

At runtime you add a storage entry in the admin UI, pick a driver, and supply that provider's credentials. OpenList then presents the remote as a path. Listing a directory fans out to the driver, which calls the provider's API and returns entries in a common shape. Downloads either proxy through the server or redirect to the provider, depending on the driver.

WebDAV is the interoperability layer. The README lists WebDAV as a feature and the go.mod includes an FTPServer library and a forked SFTPServer, so the same tree can be reached over FTP and SFTP as well. That matters because it means you do not need an OpenList-specific client: a file manager, a media player, or a backup tool that speaks WebDAV can mount the aggregate. The README also lists protected routes, permalink copying, package download, offline download, and multi-thread acceleration for single-thread streams.

Installing OpenList with Docker and adding your first storage

The repository ships a docker-compose.yml, and it is the shortest path to a running instance. It mounts the host directory /etc/openlist at /opt/openlist/data inside the container, which is where OpenList keeps its configuration and database, and it maps ports 5244 and 5245.

services:
  openlist:
    restart: always
    volumes:
      - '/etc/openlist:/opt/openlist/data'
    ports:
      - '5244:5244'
      - '5245:5245'
    user: '0:0'
    environment:
      - UMASK=022
      - TZ=Asia/Shanghai
    container_name: openlist
    image: 'openlistteam/openlist:latest'

Bring it up with the usual compose command, then open port 5244 in a browser. The Dockerfile confirms the listening ports with EXPOSE 5244 5245 and sets the data volume with VOLUME /opt/openlist/data/, so the compose file and the image agree.

docker compose up -d

Once the container is healthy, the web UI at http://localhost:5244 is where you add storage. The README does not reproduce the first-login credentials in the text provided here; check the documentation site at doc.oplist.org for the initial admin password rather than guessing. After logging in, add a storage entry, choose a driver such as WebDAV or S3, fill in the endpoint and credentials, and save. The new mount appears in the file browser, and the same path becomes reachable over WebDAV.

The image build takes a BASE_IMAGE_TAG argument with four documented values: base (the default), aria2, ffmpeg, and aio. If you want offline download or media transcoding, that is where the extra binaries come from, and the Dockerfile exposes INSTALL_FFMPEG and INSTALL_ARIA2 as build arguments. The published image is openlistteam/openlist:latest.

Where OpenList breaks down or is the wrong choice

The honest limitation is that OpenList inherits every provider's rate limit, token expiry, and API breakage. A driver is a moving target. When a cloud vendor changes an endpoint or revokes a client, the mount stops working until the driver is patched. There is nothing in the architecture that can prevent this; aggregation layers are always downstream of the APIs they wrap.

The README's own disclaimer hints at a second problem: naming confusion. The team explicitly warns that third-party projects with similar names exist, including OpenListApp/OpenListApp, and that some are paid proprietary software. If you search for an OpenList client and find one that asks for payment, that is not this project. The README states there are no paid plans and that documentation and API services rely on charitable Cloudflare resources.

A third constraint is scope. OpenList is a server. The related searches around desktop, mobile, Android, APK, and Magisk point at things the README does not describe as part of this repository. If your requirement is a native phone app that syncs files in the background, this project as documented does not provide one, and you would be relying on a third-party client of unknown provenance.

Finally, the licence is AGPL-3.0. That is a deliberate choice for a project whose stated concern is closed-source redistribution, but it has consequences for anyone embedding OpenList in a hosted product.

OpenList compared with rclone and CloudDrive2

The two comparisons people search for most are rclone and CloudDrive2, and the difference is architectural rather than a matter of feature checklists.

rclone is a command-line sync and mount tool. You configure remotes in a config file, then run copy, sync, or mount commands. It has no persistent web UI and no built-in multi-user permission model; you script it or schedule it. OpenList inverts that: it is a long-running service with a database, a browser UI, user accounts, and WebDAV as the access protocol. If your workflow is cron-driven replication between buckets, rclone is the more direct tool. If your workflow is browsing and streaming from a phone or a media player, OpenList's persistent tree is the point.

CloudDrive2 is the closer analogue, since it also aggregates cloud drives and mounts them. The distinction visible in this repository is openness and governance: OpenList publishes its full source under AGPL-3.0, documents a driver directory you can read, and states that no commercial deployment exists. CloudDrive2 is a separate product with its own licensing and distribution model. Which one you pick depends on whether source availability and community governance are requirements for you or merely nice to have.

A fourth option is simply not aggregating: keep each provider's official client. That avoids the driver-breakage problem entirely at the cost of losing the unified tree.

Maintenance cost, release cadence and licence obligations

The repository is not archived, and the last push was on 2026-09-20, one day before the reference point for this article. Releases are frequent: v4.2.6 is dated 2026-09-01, v4.2.5 is dated 2026-08-07, and a beta tag exists from 2025-11-11. A monthly-ish stable cadence means you should expect to pull new images periodically, and driver fixes arrive through those releases rather than through a separate plugin channel.

The upgrade cost is low if you keep the data directory on a host volume, which the compose file already does at /etc/openlist:/opt/openlist/data. Replace the image, restart the container, and the database and configuration persist. The README does not document rollback, so if a release regresses a driver you depend on, your recovery path is whatever backup you took of that directory beforehand. Take one.

On licensing: OpenList is AGPL-3.0. The README's disclaimer asks downstream projects not to distribute OpenList-based code in a closed-source manner and not to use the OpenList name for commercial gain. AGPL-3.0 is a copyleft licence with a network-use clause, which means offering a modified OpenList as a service triggers source-availability obligations. This is a description of the licence identifier and the project's stated position, not legal advice; if you plan to build a commercial product on top of it, have a lawyer read the LICENSE file rather than this paragraph.

Editorial conclusion

Adopt OpenList if you already run AList or another aggregator and want a fork with published governance and a v4.2.6 release dated 2026-09-01. Do not adopt it if you need a vendor SLA, a mobile client, or a guarantee that the upstream AList data directory migrates cleanly, because the README does not document a migration path. Before deploying, mount the config volume at /opt/openlist/data, confirm ports 5244 and 5245 are free, and verify that the AGPL-3.0 obligations fit how you plan to expose the service.

Frequently asked questions

Official sources

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