Cloudreve: A self-hosted file manager that puts storage providers behind one interface

The problem Cloudreve solves

Cloudreve addresses a common pain for individuals and small teams: scattered files across local disks, object storage, and vendor clouds, each with its own web console, upload tool, and sharing mechanism. Instead of logging into five dashboards, you get one self-hosted web application that presents all those storage locations as a single file tree. The target user is someone who wants the convenience of a cloud drive like Dropbox or Google Drive but insists on owning the control plane. It is not a sync client; it is a management and sharing layer. The README lists support for Local, Remote node, OneDrive, S3 compatible API, Qiniu Kodo, Aliyun OSS, Tencent COS, Huawei Cloud OBS, Kingsoft Cloud KS3, and Upyun. That list defines the scope: if your storage is not in that set, Cloudreve is the wrong tool.

How the data flows: direct transmission and background downloads

The core architectural choice is that uploads and downloads go directly between the client browser and the storage provider, not through the Cloudreve server. The README calls this 'directly transmission from client to storage providers.' That means for a large file on S3, the browser talks to S3, and the Cloudreve server only coordinates the session. This reduces server bandwidth and CPU load, which is a real advantage for a self-hosted box on a modest connection. For offline downloads, Cloudreve integrates with Aria2 and qBittorrent. You point it at a download node, and it fetches files in the background, then stores them to your configured backend. The README also mentions multiple download nodes to share the load, so you can run several Aria2 instances and distribute work. The front end is React with Redux and Material-UI, the back end is Go with Gin and ent. That separation is standard, but the direct-transfer pattern is what makes Cloudreve different from a simple file browser.

Deployment: one binary, but configuration lives in the docs

The README does not give a single command to run. It points to the Getting started page for a quick local deployment and a separate Deploy page for production. The project publishes releases with prebuilt binaries, and there is a Docker image at cloudreve/cloudreve. Building from source is documented separately. The stack is Go and React, so a source build requires both toolchains. The actual configuration keys are not in the README; they live in the docs site. That is a gap for a quick evaluation. You will need to read the docs to learn about the configuration file, database setup, and how to attach storage providers. The README does say 'all-in-one packaging, with all features out of the box,' which suggests the binary includes the web assets. For a test, you download a release, run it, and follow the quickstart. For production, expect to set up a reverse proxy and a database, likely MySQL or SQLite, though the README does not specify which.

Storage providers and the WebDAV layer

The storage provider list is the project's main selling point. Local storage is the simplest: files live on the server's disk. Remote node means another Cloudreve instance can act as a storage backend, which is useful for distributing load. OneDrive and S3-compatible APIs cover a huge range of commercial object storage. The Chinese cloud vendors (Qiniu, Aliyun OSS, Tencent COS, Huawei OBS, Kingsoft KS3, Upyun) are a strong fit for users in that region. WebDAV support is listed as covering all storage providers, so you can mount Cloudreve as a network drive on your desktop and access files from any backend. That is a practical feature for daily use. The direct-transfer mechanism works per provider, so each backend needs its own credential configuration. The trade-off is that adding a new provider requires code changes, not just config. The README does not mention a plugin API, so the list is fixed.

Features beyond file storage: preview, archive, and metadata

Cloudreve is not just a file browser. It can compress and extract archives, preview videos, images, audio, and ePub files online, and edit text, Markdown, diagrams, and Office documents in the browser. It also extracts media metadata from files and lets you search by that metadata or by tags. That makes it a viable media library for a small team. Drag-and-drop upload with parallel resumable upload is a standard expectation, and Cloudreve has it. Sharing is handled via links with expiration dates, which is a common pattern. Multi-user and multi-group support means you can give different people different access levels. The README also mentions PWA and dark mode, which are nice but not core. The archive and preview features are what push Cloudreve beyond a simple storage manager into a collaboration tool.

A real limitation: the GPL-3.0 license and the configuration learning curve

The most concrete limitation is the license. Cloudreve is GPL-3.0, which means if you modify and distribute the software, you must release your modifications under the same license. For an internal tool that you never distribute, that is often acceptable, but if you plan to offer a hosted service or embed Cloudreve in a commercial product, you need legal advice. The README is clear about the license, so there is no ambiguity. The second limitation is that the README is thin on operational details. It does not document the configuration file format, the database schema, or how to migrate between versions. The docs site covers those, but the README alone is not enough to run a production instance. The release cadence is fast: 4.18.0 in July 2026, 4.17.0 in June, 4.16.1 in early June. That means upgrades come often, and each may change config keys or behavior. You must read release notes before upgrading. The project is not archived and has recent activity, so maintenance is ongoing, but the cost of keeping up is real.

Alternatives and how they differ

The closest alternative is Nextcloud, which is also self-hosted and supports external storage. Nextcloud uses a different approach: it is a full platform with apps, sync clients, and a plugin ecosystem. Cloudreve is a single-purpose file manager with a narrower scope. Nextcloud's external storage support is often implemented as a mount that routes through the server, whereas Cloudreve's direct transfer avoids that bottleneck. If you need calendar, contacts, and collaboration apps, Nextcloud is the better fit. Another alternative is Filebrowser, a simpler Go-based file manager that focuses on local files and has a lighter footprint. Filebrowser does not have multi-cloud support or WebDAV across providers. If you only need local disk management, Filebrowser is simpler. If you need multi-cloud and direct transfer, Cloudreve is the specific match. The difference is in the storage abstraction layer: Cloudreve treats each provider as a first-class backend with its own upload path, while Nextcloud treats them as mounts and Filebrowser ignores them entirely.

What to verify before you adopt

Before committing, check three things. First, confirm that your storage provider is in the supported list and that the direct-transfer path works for that provider. The README lists the providers, but it does not say which ones support resumable upload or direct transfer; that detail is in the docs. Second, read the current version's configuration documentation. The config schema changed between major versions in the past, so do not copy an old config file blindly. Third, test the WebDAV endpoint with your desktop client. The README claims WebDAV covers all providers, but that is a claim to verify in practice. Also decide whether the GPL-3.0 license is acceptable for your use case. The project is active, with a release every few weeks, so you can expect fixes and new features. That activity is a positive sign, but it also means you should pin a version and plan for regular upgrades.

Editorial conclusion

Adopt Cloudreve if you need a single web UI and share-link layer over several storage backends, especially if you already use S3-compatible storage or OneDrive and want direct uploads that bypass your server. Do not adopt it if you require a per-file audit trail beyond basic metadata, or if your organization cannot accept GPL-3.0 for a web service. Before deploying, verify that the specific storage provider you plan to use is in the supported list, check the version-specific configuration schema in the docs, and test the mobile or PWA experience if that matters to you. The project is actively maintained with frequent releases, so pin a version and read the changelog before upgrading.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes