I have been using rclone from the command line for about three years. It runs my offsite backups, syncs files between the two cloud providers I keep subscriptions with, and handles the occasional one-off move when a friend emails me a link to a folder they want backed up to my NAS. The CLI is fine. The CLI is, in fact, excellent for the things I do, because most of what I do is scripted and the scripts do not need a GUI.
What the CLI is not good at is letting someone else use it. The first time my partner asked me to “just back up this folder to Google Drive,” I wrote a one-line shell alias. The second time, I wrote a longer shell alias. The third time, I sat down and installed Rclone UI, which is a small desktop wrapper around the same rclone binary I have been running from a terminal. It does not do anything new. It does the things I was already doing, in a way that does not require remembering the order of flags.
Here is what Rclone UI is, what it does that the CLI does not, and where it falls short.
What rclone is, and why you might already need it
rclone is a command-line program for syncing files to and from cloud storage. It speaks the APIs of about seventy storage providers, including Google Drive, Dropbox, OneDrive, S3 (the API used by Amazon Web Services and many S3-compatible providers like Backblaze B2, Wasabi, MinIO, and self-hosted NAS appliances), WebDAV, SFTP, and a long list of specialty services. If you have ever wanted to copy a folder from one cloud to another without downloading it to your laptop first, rclone is the tool that does it.
The basic operations are copy, sync, move, and mount. Copy duplicates a tree from one location to another. Sync makes a destination look like a source, deleting files in the destination that are not in the source. Move is copy plus delete from the source. Mount attaches a remote as a local filesystem so you can browse it with Finder or Explorer. The flag set on each operation is large enough that muscle memory only gets you so far.
Most people who land on rclone are there because one of three things happened to them.
- They switched cloud providers and needed to move a few hundred gigabytes without re-downloading everything to their laptop.
- They set up an offsite backup and did not want to pay for a SaaS (software as a service) backup product that wraps the same APIs rclone talks to natively.
- They wanted to mount cloud storage as a local drive and discovered that the official clients from the cloud providers are slow, limited, or missing on Linux.
If you are in any of those buckets, you have probably run rclone config and stared at a setup wizard that asks questions about OAuth (open authentication, the protocol that lets you grant an app permission to act on your behalf without giving it your password) scopes and client IDs. The wizard is fine the second time. The first time it is a wall.
What Rclone UI adds
Rclone UI is a desktop application, written in TypeScript, that wraps the same rclone binary and exposes the operations through a window. You point it at an rclone config file (or let it generate one), pick a source and destination from a dropdown, and click a button. The application calls rclone for you and shows you the progress in a list of running jobs.
Adding a remote through the UI is straightforward: click the remotes editor, choose a provider, and the UI walks through OAuth and saves the config. Editing an existing remote is the case the UI is built for. The rclone config wizard requires reopening the setup and walking through it again, which is more friction than clicking a row and changing a field.
Cross-platform support covers the three desktop operating systems people actually use. There are builds for macOS, Windows, and Linux, with a package available on most of the package managers you would expect. Rclone UI also ships as an AppImage (a single-file Linux application bundle that runs without installation) for the Linux distros that prefer not to package it.
The reason this matters for a homelab audience is that you can install Rclone UI on a laptop, point it at an rclone daemon running on a different machine, and manage the remote rclone from a desktop. The rclone daemon (a long-running background process that accepts commands over a local network or remote connection) is a thing rclone has supported for a while, and pairing it with the UI gives you a setup where the heavy work runs on the server and the control panel runs on your laptop.
The features that actually matter
The Rclone UI features list is long, and most of them map directly to rclone flags. The features I use, in order of how often I click them:
- The remotes editor, which lets you add or modify a remote without editing the rclone config file by hand. The
rclone configwizard is fine, but editing an existing remote means reopening the wizard and walking through it again, which is more friction than clicking a row and changing a field. - The job scheduler, which lets you set up a recurring copy or sync on a cron schedule (a time-based scheduler common on Unix systems). The schedule runs inside the UI application, so the application has to be open for the job to fire. For jobs that need to run whether the laptop is open or not, the sensible default is
cronplus therclonebinary directly. - The mount manager, which lets you mount a remote as a local filesystem with a checkbox. The mount uses FUSE (Filesystem in Userspace, a Linux kernel feature that lets user-space programs implement a filesystem without writing kernel code) under the hood, which is what the
rclone mountcommand uses anyway. The UI adds a checkbox for “auto-mount on startup,” which is the feature I actually wanted. - The live job monitor, which shows you what every running rclone operation is doing. The progress is per-file, with throughput in megabytes per second and an ETA. It is the same information
rcloneprints to the terminal, but with a UI that does not scroll off the screen when you are doing a 200,000-file sync.
There are four smaller features that do not show up in the headline list but matter for daily use.
- Job profiles let you save a copy or sync as a named profile with the source, destination, and flags. The profile is one click away from running, which is what you want when the same sync runs weekly.
- The bandwidth limit field lets you cap the throughput of a job without going back to the rclone docs to remember the flag. The flag is
--bwlimit, and the UI takes the number in megabytes per second. - The conflict-resolution policy dropdown maps directly to
--conflict-resolve, which is the rclone flag that controls what happens when a file exists at both the source and destination with different modification times. The UI surfaces it without making you read the flag documentation. - The “open destination in Finder” button is a small thing, but it is the difference between finishing a job and then hunting for the destination folder in the file manager. After the second or third time, the button becomes the reason you keep the UI open.
The features that the UI does not have are also worth knowing. There is no equivalent of rclone cryptcheck, which is the command that verifies an encrypted remote without downloading the files. There is no built-in rclone serve (a feature that lets rclone expose a remote as an SFTP, HTTP, or WebDAV server). For those, you are back to the command line.
When the UI earns its keep
The honest case for Rclone UI is the person who needs rclone but does not want to learn the CLI well enough to be confident in it. There are a few profiles that fit:
- The partner, parent, or roommate who needs to back up a folder to the cloud, and who will not be running
rclone configand pasting OAuth tokens from a browser. The UI walks them through the setup with screenshots, which is faster than explaining the wizard over the phone. - The small team that needs to share a recurring sync, where one person sets up the remotes and the others click a button to run the job. The UI’s profile system is exactly this workflow.
- The homelab user who wants a visible dashboard for the rclone daemon running on their NAS, without leaving the rclone toolchain entirely.
The honest case against Rclone UI is the user who already knows rclone and wants to script it. The UI is a wrapper. If your workflow is “run this script at 2 AM every day,” you do not need a window, and the window will not help you.
There are also a few cases where the UI is a liability. The mount manager will let you mount a remote that requires authentication that has expired, and the resulting mount will appear to work until you try to read a file. The CLI prints the authentication error and tells you to re-run rclone config. The UI shows a blank window. The fix is the same in both cases, but the UI makes it harder to know what to fix.
Trade-offs
Rclone UI is not free in time.
Electron is the runtime, which means it uses more memory and CPU than a thin native client would. For a homelab dashboard running on a small server, this matters. For a laptop with 16 GB of RAM, it does not.
Job scheduling requires the application to stay open. The job scheduler runs inside the application, which means the application has to be open for the schedule to fire. If you want a sync that runs at 2 AM, you need to either leave your laptop open or use the system cron to call rclone directly. The UI does not run as a daemon (a background service that runs without an open window) on most platforms, and even where it does, the daemon does not include the scheduler.
Feature coverage is incomplete by design. Anything rclone can do that the UI does not expose is one CLI call away, but that CLI call breaks the “everything in one window” promise. For workflows that mix UI-managed jobs with CLI-only features, you end up using both, and the UI stops being the single source of truth.
Cost is mostly time, not money. Rclone UI is free and open source under the Apache 2.0 license. The cost is the time to set it up, the time to learn which features the UI covers and which it does not, and the ongoing cost of keeping the UI version in sync with the rclone version on the underlying system.
If you already know rclone and your workflow is mostly scripted, the UI is a thin wrapper that does not save you time. If you have ever written a shell alias to invoke an rclone command because you could not remember the flags, the UI is the version of rclone you actually wanted. The “who is this for” question is mostly about how much of rclone you want to learn.
Bottom line
Anyone running rclone from the CLI today and finding that they keep writing the same long incantations should install Rclone UI and try the profile system. The first time you click a profile instead of typing the flags, the value of the UI lands.
For users who are new to rclone and need to set up a cloud backup, Rclone UI is the easiest on-ramp available. The setup wizard walks through OAuth for the major providers, the job profiles make the recurring sync one click, and the live job monitor gives you the confidence that the thing you started is actually doing the thing.
For users who already script rclone and want to keep doing that, the UI is not a replacement. Use the CLI for the scriptable work, and install the UI only if you have someone else on your network who needs a button to press.