CloudSaver: a self-hosted search and transfer front end for Chinese cloud drives

The feature set is four cloud drives and a search box

CloudSaver is described as a cloud drive resource search and transfer tool built on Vue 3 and Express, with responsive layouts for both desktop and mobile, and one-command Docker deployment. The project has 9,316 stars and 781 forks, is MIT licensed, and was last pushed on 2026-04-20.

The feature list has four groups. Search covers multiple resource subscription sources, keyword search and link parsing, plus Douban popularity listings. Transfer supports one-click saving into 115, Quark, Tianyi and 123Pan, including folder-level browsing and selection. There is a multi-user system with registration, login and an administrator versus ordinary user distinction. And there is a responsive design with separate component libraries per platform.

The stack is worth reading because it explains the shape of the UI. The frontend is Vue 3 with TypeScript, Vite, Pinia for state and Vue Router for routing, but it uses two component libraries: Element Plus on desktop and Vant on mobile. The backend is Node.js with Express and SQLite3 for storage. Two UI frameworks in one app is a cost paid for responsive layout, and it is also why the two screenshots groups in the README are split into desktop and mobile sections.

Requirements are modest: Node.js 18 or newer and pnpm 8 or newer.

The repository is stuck at 0.2.5 while the image moves on

This is the most important fact about the project and the README puts it in a bold warning near the top, after a link, not buried at the end. For reasons the author does not specify in the visible text, the newer version's content is not included in this open source repository, which remains at V0.2.5. To use the current product you are told to deploy the Docker image instead.

That is a significant gap between what you can read and what you would run. The `package.json` at the repository root confirms the source tree's version, declaring 0.2.5 with frontend and backend workspaces.

The consequence is straightforward. Anyone evaluating CloudSaver as a codebase is evaluating a version the author no longer ships. Anyone using it is running an image whose contents they cannot inspect from this repository. Both things are true at once, and any honest comparison has to hold both in view.

The project does maintain a version changelog, deployment FAQ and a statement about how updates and feature requests are handled, all hosted on Yuque rather than in the repository, along with official Telegram and QQ groups. Those external documents are where the current product is actually described.

Docker deployment is the documented path, with two registries and two tags

The README gives both a local development path and a Docker path, and the Docker path is the one it recommends. Two registries are offered, Docker Hub and GitHub Container Registry, and two tags, `latest` for stable and `test` for the newest features and fixes.

The single container run is short enough to copy as-is:

docker run -d \
  -p 8008:8008 \
  -v /your/local/path/data:/app/data \
  -v /your/local/path/config:/app/config \
  --name cloud-saver \
  jiangrui1994/cloudsaver:latest

The compose file is the version you would actually keep:

version: "3"
services:
  cloudsaver:
    image: jiangrui1994/cloudsaver:latest
    container_name: cloud-saver
    ports:
      - "8008:8008"
    volumes:
      - /your/local/path/data:/app/data
      - /your/local/path/config:/app/config
    restart: unless-stopped

Two volumes, one for data and one for config, and the distinction matters because the config directory holds the environment file you must edit before anything works. Port 8008 is the published port.

The image build is visible in the `Dockerfile` at the root, and it is a three-stage build. Frontend and backend are each built in their own `node:18-alpine` stages, the final stage installs nginx to serve the built frontend as static files and copies the backend build in, and nginx.conf at the root is baked in as the image's configuration. The container exposes 8008 and starts through `docker-entrypoint.sh`, with `/app/config` and `/app/data` declared as volumes.

The credentials story is the reason the project is insistent about self-hosting

Most of the README's energy goes into one warning, repeated in several sections with different emphases. It concerns credentials. The project handles cloud drive cookies, and the README treats handing those to a third party as equivalent to handing over account passwords. Its stated position is that it has never provided and will never provide any hosted service, demo or public instance, and that any website claiming to be related to the project is an unauthorized third-party deployment.

The FAQ section of the README puts it bluntly: there is no online demo, and using someone else's deployment is not safe. The stated safe path is deploying from the official repository code on your own server.

This is a coherent position for a tool whose core operation requires a logged-in session against someone's cloud drive account, and it is worth respecting. It also means the practical security work lands on you: the configuration directory is a volume you control, so it is your responsibility to protect it, and the registration codes are a real detail rather than a formality.

The default registration codes are published in the README: 230713 for administrators and 9527 for ordinary users. On a deployment reachable from the internet, those are the first thing to change.

The configuration file itself, mounted at `/app/config/env`, holds a JWT secret and Telegram settings including a base URL and a channel list, with a note that the channel configuration stopped taking effect from version 0.3.0 onward.

Local development from source, for the version that is actually here

For anyone working with the 0.2.5 source, the development path is a four-step sequence. Clone, install with pnpm, copy the environment example, and start:

git clone https://github.com/jiangrui1994/CloudSaver.git
cd CloudSaver

pnpm install

cp ./backend/.env.example ./backend/.env

pnpm dev

The root `package.json` shows how the monorepo is wired. Workspaces are `frontend` and `backend`, and the orchestration runs through `npm-run-all`: `dev` fans out to `dev:frontend` and `dev:backend` in parallel, and `build` does the same for the build targets. There are also parallel `install:*` scripts, version bump scripts that bump the frontend workspace first, and `format`, `format:check`, `lint` and `lint:fix` on top of Prettier and ESLint with the Vue plugin.

Two things in that file are worth flagging. The `engines` block asks for pnpm 6 or newer while the README asks for pnpm 8 or newer, which is a small inconsistency between the manifest and the documentation. And the `pnpm.onlyBuiltDependencies` list names `@parcel/watcher`, `bcrypt`, `esbuild`, `sqlite3` and `vue-demi`, which is the allowlist pnpm needs for packages with install scripts; `sqlite3` and `bcrypt` in that list explain why the Docker build is a pnpm build rather than an npm one.

What the project says it will not do

The README closes with a special declaration that reads like a legal notice and functions as a scope statement. The project is for learning and exchange, personal use only with no commercial use of any form, and advertising on the project page is prohibited. It also states that all searched resources come from third parties and that the project makes no guarantee about their authenticity or legality.

That last point is the one to sit with. CloudSaver's search layer pulls from resource subscription sources, so it is a front end over content it does not host and does not vet. The disclaimer is honest, and it means the tool's suitability depends entirely on which sources you configure.

The contribution section is a five-step git walkthrough: fork, create a feature branch, commit, push and open a pull request. The project also lists sponsorship channels including stars, sharing and donations, notes CDN acceleration and security protection are sponsored by Tencent EdgeOne, and includes a HelloGitHub recommendation badge.

Taken as a whole, the repository is a well-organised, honestly labelled open source project whose product has moved past it. The documentation quality is higher than the code's currency, which is the opposite of the usual failure mode and arguably the more useful state to find a project in.

Editorial conclusion

The decision that shapes CloudSaver is that the repository is not the product. The author states outright that the newer version is not published in this open repository, which stays at V0.2.5, and that the Docker image is the way to run it. That leaves an unusual split: the source is readable, MIT licensed and pleasant to browse, but the feature set you would actually use arrives as a binary image whose changes you cannot read. For a tool that handles account cookies, that is a real tension the README spends more space on than any feature list. If you want to run it, use the stable image and change the default registration codes before anyone else can. If you want to extend it, you are starting from the 0.2.5 source, not from the current product.

Frequently asked questions

Official sources

1. Issues
2. jiangrui1994/CloudSaver on GitHub
3. License: MIT
4. README