# rclone-ui: a Tauri desktop front end for rclone, listed in seven package managers

> The README links to one organisation and the repository metadata to another. One row in the package manager table installs a command line tool, not the GUI.

**rclone/rclone-ui** — The cross-platform GUI for rclone & S3.

- Repository: https://github.com/rclone/rclone-ui
- Website: https://rcloneui.com
- Stars: 2,308 · Forks: 93
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/rclone-rclone-ui

## A thin layer, described as one

The tagline is precise about what this project is. It calls itself a light, transparent layer on top of rclone, to manage remotes and tasks in a more user-friendly way, and the package description says it is the GUI for rclone and S3. That word light matters more than marketing copy usually does, because it describes the architecture.

The tree contains src-tauri alongside src, which is the shape of a Tauri application: a web frontend in one directory and a native Rust shell in the other. The GUI is not a web page you point a browser at, and it is not a reimplementation of rclone. It is a desktop program that drives rclone.

The topics list is where the scope shows. Alongside rclone and its gui tags there is tauri, tray, and tray-menu for a system tray presence, fuse and fuse-filesystem for mounting remotes as a local filesystem, and then the backends themselves: s3, backblaze-b2, dropbox, google-drive, google-cloud-storage, ftp, and sftp. rsync is in the list too, and cyberduck appears alongside it as a comparison point.

Those topics are a promise about what the interface can talk to, and it is worth reading them as a feature list rather than as keywords. A GUI that covers S3 and its compatible providers, the major consumer cloud drives, and both FTP flavours is covering the cases people actually use rclone for, and adding a filesystem mount means a remote can appear as a drive letter or a mounted directory rather than something you sync from a command line.

One detail in the topics is a rename that never finished. It carries hero-ui, heroui, and nextui, which is the same component library under three names, since the library previously called NextUI was renamed HeroUI. Three tags for one dependency is harmless, but it does tell you the topic list is maintained by hand rather than derived.

## Seven package managers, and one of them is not the same kind of thing

The README's package manager table is the centre of the document, and it is a table of eight rows rather than seven, which is where the first thing worth knowing comes from.

The commands are as follows.

```bash
flatpak install com.rcloneui.RcloneUI
brew install --cask rclone-ui
scoop bucket add extras && scoop install rclone-ui
choco install rclone-ui
winget install --id=RcloneUI.RcloneUI -e
npx rclone-ui
+```

Five of those install a desktop application through a real package manager: Flatpak, Homebrew cask, Scoop, Chocolatey, and WinGet. That is an unusually complete spread for a Tauri app, and it is the part of this project that most reduces friction for a new user.

The sixth does not belong in the same list, and this is the contradiction worth your attention. The npm command sits in a row beside Flatpak and Homebrew with an npm badge, implying you get the same artifact. The manifest says otherwise. The publish script is a call that publishes the cli directory, so the npm package named rclone-ui is the command line companion, not the GUI. The tree confirms it with a cli directory sitting alongside src-tauri.

So when you read that row, npx rclone-ui is a way to invoke the CLI. It is genuinely useful, and for scripting or for a headless machine it may be the only part you need, but it does not install the desktop window. The type of artifact differs in kind, not in version.

Both facts come from the project and both are current in their own file. Rather than pick one, the check is quick: read the publish script and the cli directory's own manifest, and you will see within a minute whether the package you are about to run is a binary that opens a window or one that operates on remotes from a shell. If you are installing on a machine with no desktop session at all, that distinction decides whether this project is usable to you.

The final two rows are mobile store listings, an Apple App Store entry and a Google Play entry under a different application id. Those are a separate product surface from the Tauri desktop app, and the README does not explain how they relate to the desktop build, which is worth checking before you assume the mobile app manages the same remotes as the desktop one.

## The links point at a different organisation than the repository does

Every self-reference inside the README uses one organisation path, and the repository it lives in uses another. This is the single most confusing thing about reading the project.

The download counter badge, the issue links, the star history chart, the translation links at the bottom of the file, and the contributing links all use the path rclone-ui followed by rclone-ui. The package manifest agrees with the README: both its repository URL and its author URL point at that same path.

The repository itself, and this is where you are reading it, is under the rclone organisation. So the project's internal documentation consistently refers to a path that is not where the project lives.

Three explanations fit. The most likely one is a repository move or transfer where the internal links were not all updated, which happens because GitHub redirects old paths so nothing visibly breaks and there is no pressure to fix them. The second is an organisation rename in the opposite direction, where the documentation was written after the rename and the fork or original path stayed as it was. The third is that the two paths are simply two related projects and the documentation points at a sibling repository.

You cannot tell which from inside the repository, and you should not need to. The observable consequence is what matters: any automation you write that constructs URLs from the strings in the README will construct the wrong ones, and any badge count you read will reflect whatever the redirect resolves to at the time you read it.

The check is concrete and takes a minute. Open a recent release and look at which path its assets actually download from, and open an issue link from the README and see where the browser lands. Whatever those two resolve to is the current canonical location. Use that in your own tooling, and treat the README's strings as historical.

## Direct downloads cover seven architecture and format combinations

Underneath the package manager table the README lists direct downloads, and the coverage is worth reading carefully because it is broader than most projects attempt.

Windows has an Arm build and an x64 build. macOS has an Apple Silicon build and an Intel build. Linux has an AppImage, a deb, and an rpm, and there is a separate Linux Arm set with the same three formats.

That is two Windows architectures, two macOS architectures, and six Linux artifacts across two architectures, so fifteen direct downloads if you count every combination. Building for Windows on Arm is the kind of target most desktop projects skip because the tooling for cross-compiling to it is awkward, and having it here suggests the release pipeline handles it deliberately.

The manifest corroborates that. There are dedicated build scripts for macOS on Apple Silicon, a universal macOS build, macOS on Intel, Windows on x64 using a specific cross-compilation runner, Windows on Arm with the same runner, and Linux on Arm. There is also a WebAssembly target and a script key literally named below targets do not work, whose value just echoes you heard me. A joke key in a manifest is harmless and mildly informative: it tells you the author tried targets that did not build and chose to say so in the file rather than delete the evidence.

The build command itself has a detail worth noting. The web build runs the compiler and then invokes the bundler through Node with a raised heap size of about four gigabytes. When a frontend build needs that much memory, the dependency graph is large, and the embedded PDF viewer packages in the dependency list are four separate modules at the same version, which is consistent with a component library that pulls in a rendering engine.

There is also a script for generating Cargo sources for Flatpak packaging, which is how the Flatpak listing stays buildable against a Tauri project that depends on native code.

One caveat on the macOS path. The environment example file lists Apple signing variables including a signing identity, an Apple ID, an app-specific password, and a team ID, and it also lists Azure credentials for Windows signing and a signing key pair for update manifests. That means these builds are code-signed, and for macOS in particular a notarised build is what makes the download open without a gatekeeper warning on first launch.

## The Docker section is one paragraph and a link

The README's third section is short. It frames Docker, homelab, and server usage as a way to control your server, your homelab, or someone else's PC, managing remote rclone instances, and then it links out to a guide hosted on the project website.

That framing is worth pausing on, because it reveals a scope the desktop app alone would not suggest. rclone itself is designed to be run as a long-lived service on a machine you are not sitting at, and this project's answer to that is to point its interface at a remote instance rather than at a local binary.

So the same application covers two different use cases. Locally, it is a desktop GUI over your own rclone configuration. Remotely, it is a control panel for a server you administer from a laptop. That is a genuinely useful capability, and it is also the one that determines whether this project fits your setup, because the remote path depends on the server-side piece being deployed and reachable, and the README does not describe that configuration inline.

The guide lives on the project's own documentation site rather than in the repository. That is a normal choice and it keeps the README short, but it means the one section explaining the server deployment is the one you cannot read offline and the one most likely to drift from the code, since nothing in the repository links a version to it.

If your use case is the desktop app, this section does not matter to you at all. If your use case is managing a server, this section is the whole project and you should read the guide before installing anything, because the requirements on the server side, credentials, network exposure, and what the guide assumes about rclone's own configuration server are what determine whether it works.

## A roadmap pointing at a section that is not there

The Roadmap section opens with a note saying finalized items have been moved to the Features section, and then links to a discussion thread about version three.

The Features section does not exist. Reading the README top to bottom, the headings after the opening block are Package Managers, Downloads, Docker/Homelab/Server Usage, Roadmap, the star history chart, and Contributing. There is no Features heading anywhere in the file, which means the note points at a section that was removed or renamed and the reference was not updated.

This is a small thing, and it is the kind of small thing that tells you something. A README pointing at a section that is gone usually means features that used to be listed as pending have been shipped, and the heading was deleted without redirecting the reference. That reading is consistent with the repository's own state: the version is 3.7.5 and the newest release tag is a 3.x tag, so a great deal has in fact shipped since any early roadmap.

The Contributing section is more informative. It lists three good first problems, and two of them are infrastructure: upgrading the repository to a newer major version of the build tool and the UI library, and introducing the newer compiler for React components. Both are the kind of task that means the current code is behind the current ecosystem, and it tells you the project is not claiming to be on the leading edge of its own stack.

It also says merged pull requests receive a Lifetime License. That phrase does not correspond to any licence grant in the repository, and the manifest declares Apache 2.0 while a LICENSE file sits at the root. Read the LICENSE file rather than the README line, since that is the document with legal effect. The lifetime licence line is best understood as the project's welcome to contributors rather than as a licence grant.

For anyone evaluating the project's direction, the linked version three discussion thread is the place with actual content, since the roadmap list itself has been emptied out.

## Conclusion

rclone-ui is worth installing if you want a desktop front end to rclone without living in a terminal, and the distribution work is the strongest part of the project: seven package managers plus direct downloads for two Windows architectures, both macOS architectures, and two Linux architectures with three formats each. Two things to check before you rely on the README's own claims. First, the internal link mismatch, where the README and the package manifest both point at one organisation path while the repository lives at another, and the practical resolution is to test which path a release asset actually resolves from rather than trusting either string. Second, what the npm package actually is. The package manager table lists it alongside Flatpak, Homebrew, and Scoop as an equivalent install route, and a CLI package is not equivalent to a desktop application. Read the publish script in the manifest before you type the npx command, because knowing whether you get a window or a terminal changes everything about what happens next.

## FAQ

### What is rclone used for?

rclone is a command line program for syncing, copying, and moving files between storage providers, and for mounting remote storage as a local filesystem. It speaks S3 and compatible services, major consumer cloud drives, FTP and SFTP, and about forty more backends. This project's topics list covers S3, Backblaze B2, Dropbox, Google Drive, Google Cloud Storage, FTP, and SFTP, along with mount support.

### Is there an rclone GUI?

Yes, and this project is one. It is a Tauri desktop application that manages rclone remotes and tasks, distributed through Flatpak, Homebrew, Scoop, Chocolatey, and WinGet, with direct downloads for Windows on x64 and Arm, macOS on Apple Silicon and Intel, and Linux in AppImage, deb, and rpm for both x64 and Arm. It can also point at a remote rclone instance.

### Does npx rclone-ui install the desktop application?

Probably not. The README lists that command in the same table as Flatpak, Homebrew, and Scoop, but the package manifest's publish script publishes the cli directory, so the npm package named rclone-ui is the command line companion rather than the GUI. Read the publish script and the cli directory's own manifest before running it.

### Which platforms does rclone-ui have downloads for?

Windows on Arm and x64, macOS on Apple Silicon and Intel, and Linux in AppImage, deb, and rpm formats for both x64 and Arm. There are also Apple App Store and Google Play listings under a separate mobile application id, and the README does not explain how the mobile app relates to the desktop build.

### Can rclone-ui manage rclone on a remote server?

That is what the Docker, homelab, and server section is for. The README describes it as a way to control a server or someone else's PC by managing remote rclone instances, and links to a guide hosted on the project website rather than documenting it in the repository. Read that guide first, since the server-side requirements are what determine whether it works.

### What licence is rclone-ui released under?

The package manifest declares Apache 2.0 and there is a LICENSE file at the repository root. The README's contributing section also mentions a lifetime licence for merged pull requests, which does not correspond to a licence grant in the repository. Read the LICENSE file rather than the README line, since that is the document with legal effect.

## Sources

- [License: Apache-2.0](https://github.com/rclone/rclone-ui/blob/main/LICENSE)
- [Project website](https://rcloneui.com)
- [rclone/rclone-ui on GitHub](https://github.com/rclone/rclone-ui)
- [README](https://github.com/rclone/rclone-ui/blob/main/README.md)
- [Releases](https://github.com/rclone/rclone-ui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rclone-rclone-ui