RClone Manager wraps rclone in a Tauri desktop app and a headless server

Two products from one codebase, switched by Cargo features

The repository builds a desktop application and a server from the same source, and the mechanism is the build script in the package manifest rather than a separate project. There is a `dev:portable` and a `build:portable` target, a `dev:flatpak` and a `build:flatpak` target, a `dev:headless` and a `build:headless` target that points at a different Tauri configuration file, and a `dev:android` target. The headless build uses `src-tauri/tauri.conf.headless.json` and turns on the `web-server` and `tray` features, while the Android target turns on the `mobile` feature. The headless variant has its own release tag, published the same day as the desktop v0.3.3 release, and its own directory in the repository with a README. So a single Angular and Rust codebase produces a Linux, Windows and macOS desktop app, a Flatpak and portable build, an Android build, and a web server variant, and the differences are declared as features at build time.

Nautilus is the file manager and the app is the workflow layer

The feature list describes two layers that use rclone differently. The first is Nautilus, a built-in file manager for browsing, editing, moving, copying, renaming and deleting files on remote storage, with an inline file viewer giving previews for videos, images, PDFs, audio and text. The second is the workflow layer, where Visual Workflows let you design and automate multi-step cloud pipelines on an interactive node based canvas, with cron triggers, folder watchers and instant alert notifications. Quick Runs is a third piece, a status-aware card grid for one-click cloud operations and saved CLI flag presets. The architectural point is that the file manager is a thin surface over rclone's own operations, while the workflow builder is where the app adds something rclone does not have on its own: a way to describe a sequence of operations and have it triggered on a schedule or a filesystem event.

Mount and serve put your remote into the local filesystem

Mount and serve management is the feature that makes the app feel like a desktop tool rather than a browser for cloud storage. Mount controls let you expose a remote as a local path, and serve management covers WebDAV, SFTP, HTTP and FTP, so a remote can be published over a network protocol without setting up a separate server for it. The Job Watcher then gives you real-time transfer monitoring and bandwidth control for the operations that are running. Mounting and serving are exactly the operations rclone exposes as mount and serve subcommands, so the value here is that you can point at them from a control panel rather than from a terminal. It is worth noting what the app does not claim: the overview describes rclone as the backbone, so the mounting and serving behaviour, including which flags apply, comes from the rclone version in use rather than from anything specific to this interface.

rclone-rc-limitations.md is the file that tells you what will not work

The repository root contains a document called rclone-rc-limitations.md, and the presence of that file says more about the project than a feature list does. RClone Manager works by driving rclone, and the remote control interface rclone exposes has limits that a GUI can run into. The application, the version numbering at 0.3.x, and the release notes' habit of shipping a headless build alongside the desktop one all point to a project that is still finding those edges. If you are evaluating this app for anything serious, that file is the first thing to read after the documentation wiki, because it is the difference between a tool that wraps rclone completely and one that wraps most of it with documented gaps. A project that publishes its own limitations list at the root of the repository is doing something few GUI wrappers bother to do, and it should change how you test the tool before committing to it.

Installing the desktop build on Linux, macOS and Windows

The distribution story is wide. On Linux the README lists an AUR package installed with `yay -S rclone-manager`, a git variant with `yay -S rclone-manager-git`, a Flathub application installed with `flatpak install io.github.zarestia_dev.rclone-manager`, and direct downloads as .deb, .rpm, .AppImage and a portable tar.gz from the releases page. The Flatpak route has its own troubleshooting guidance in the wiki, covering Flatpak specifics and update handling.

yay -S rclone-manager

flatpak install io.github.zarestia_dev.rclone-manager

The Android build is labelled Beta in the summary line, and it carries a specific capability: Android SAF and DocumentsProvider access to cloud remotes in the system file pickers through the Storage Access Framework, plus an in-process VFS mount bridge that does not need root. That is the sort of capability that justifies a Tauri based approach on mobile, since a web view shell can present native file pickers. The other desktop platforms are covered by their own sections of the installation page, and the wiki link at the top of the readme is the entry point for the per-platform instructions.

The headless build is a web server with volumes and environment variables

The headless mode is a separate product for a VPS or a NAS, and its configuration is documented in the compose file and the Dockerfile. The container image is published as `ghcr.io/zarestia-dev/rclone-manager:latest`, the container is named rclone-manager with a restart policy of unless-stopped, and the web interface is served on port 8080, mapped from the host.

services:
  rclone-manager:
    image: ghcr.io/zarestia-dev/rclone-manager:latest
    container_name: rclone-manager
    restart: unless-stopped

    ports:
      - '8080:8080'

Two volumes matter. One named volume holds the app data and the rclone binary, which is auto-downloaded on first run, and the other holds rclone.conf. The environment section is where the operational decisions sit: PUID and PGID default to 1000 and are meant to match your host user to avoid permission problems on mounted volumes, with an optional PGIDS for supplementary groups. There is also an optional master secret for the encrypted credentials store, and optional basic authentication for the web UI, and the file notes that a TLS certificate and key can be set for encrypted traffic.

Translations are coordinated through Crowdin and nine README files

The localisation approach is visible at the repository root, where README files exist in English, Turkish, Simplified Chinese, Traditional Chinese, French, Spanish, Brazilian Portuguese, Russian and Japanese, and the header links to a Crowdin project. There is a crowdin.yml file at the root, and a `sync:flags` script in the package manifest, alongside `sync:providers` and `sync:endpoints` scripts that update flag, provider and endpoint lists, and an `audit:i18n` script that checks the translation keys. That last script matters more than it looks. A GUI with per-locale strings across many services has a failure mode where a new key exists in the source but is missing in a translation, and the audit script exists to catch that in CI rather than in a bug report. The project also runs a Husky pre-commit hook, has LINTING.md, a CHANGELOG.md, a CONTRIBUTORS.md and a CODE_OF_CONDUCT.md, so it is a project with the usual trappings of a maintained repository rather than a single developer script.

Licence, tooling and the shape of the Rust side

The project is GPL-3.0 licensed, with the licence file at the repository root, and the default branch is `master`. The Angular side is on version 22 with the CDK, common and compiler packages all at the same minor, and the test tooling follows the Angular CLI conventions with `ng test`, a no-watch CI variant and a coverage variant. The lint script is unusual in a good way: it runs eslint over the TypeScript and HTML files and then changes into the Rust directory to run `cargo clippy -- -D warnings`, so warnings in the Rust code are treated as failures. The format script does the same pairing with prettier and `cargo fmt`. The Rust side lives in the `src-tauri` directory, and there is a Dockerfile, a docker-compose.yml, an entrypoint.sh and a packaging directory, which is the standard set of pieces for shipping a Tauri application through every channel. Releases v0.3.3 and v0.3.2 are dated 2026-09-23 and 2026-08-24, and the last push was on 2026-10-15.

Editorial conclusion

RClone Manager suits a person who already uses rclone and wants a graphical file manager, a way to trigger the same operations from cards, and a set of scheduled workflows without writing shell scripts. It does not suit someone who needs rclone to run in a container today without reading the configuration notes, because the headless image expects specific volumes and environment variables, and it does not suit a team that needs long term API stability, since the version is still 0.3.x. Before you deploy the headless build, set PUID and PGID to match your host user, decide whether the web UI needs basic authentication, and read rclone-rc-limitations.md in the repository, which is the file most likely to change your expectations about the remote control interface.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Zarestia-Dev/rclone-manager on GitHub