rclone: rsync for cloud storage

What rclone is

Rclone describes itself as "rsync for cloud storage": a command-line program to sync files and directories to and from different cloud storage providers. It is a single Go binary that speaks to a very long list of storage systems through one consistent set of commands. The README lists well over a hundred providers and variants, from Amazon S3, Google Cloud Storage, Azure Blob and Azure Files to Google Drive, Dropbox, OneDrive, Box, Backblaze B2, Cloudflare R2, Wasabi, MinIO, Ceph, SFTP, FTP, SMB, WebDAV, HDFS, Proton Drive, iCloud Drive, Internet Archive and the local filesystem.

The problem it solves is fragmentation. Every storage service has its own API, authentication flow, quirks around timestamps and hashes, and its own client tools. Rclone puts all of them behind the same syntax, so rclone copy works the same way whether the destination is an S3 bucket, a Hetzner Storage Box over SFTP or a Google Drive folder, and data can move directly between two different clouds. It is used for backups, migrations between providers, mounting remote storage as a local drive, serving files over standard protocols and scripted data movement in CI and cron jobs.

The audience is broad: sysadmins and DevOps engineers moving data between environments, developers who need object storage in scripts, homelab users backing up to cheap storage, and teams migrating from one provider to another.

How it works

Rclone is organised around remotes and subcommands. A remote is a named configuration for one storage system, stored in a config file and created interactively with rclone config. Paths are then written as remote:path/to/dir, while plain paths such as /path/to/dir refer to the local filesystem. The general syntax, from the usage docs, is rclone subcommand [options] <parameters> <parameters...>.

rclone ls remote:path # lists a remote
rclone copy /local/path remote:path # copies /local/path to the remote
rclone sync --interactive /local/path remote:path # syncs /local/path to the remote

Each storage system is implemented as a backend. On top of the storage backends sit virtual backends that wrap other remotes and change their behaviour. The README lists Alias (rename existing remotes), Archive (read archive files), Chunker (split large files), Combine (join multiple remotes into one directory tree), Compress, Crypt (encryption), Hasher (add checksums for backends that lack them), Union (join multiple remotes to work together) and Cache, which is marked as deprecated. Because these layers compose, an encrypted, chunked remote on top of an object store is just configuration.

Remotes without a config file

Remotes can also be created on the fly. The :backend:path form takes all settings from flags or environment variables, and a connection-string form puts the options inside the remote name. The docs show both:

rclone lsd --http-url https://pub.rclone.org :http:
rclone copy :sftp,host=example.com:path/to/dir /tmp/dir

The advantage of connection strings, as the docs explain, is that options apply only to that remote rather than to every remote of the same type on the command line. That matters when copying between two remotes of the same backend with different settings.

Integrity and metadata

The feature list says MD5 and SHA-1 hashes are checked at all times for file integrity and that timestamps are preserved. Which hashes and metadata are available depends on the backend; the storage providers overview page has a feature matrix per provider. Where a backend lacks a hash, the Hasher virtual backend can maintain one.

Key features

• Copy, sync, move and check. copy transfers new or changed files and skips the rest; sync makes the destination identical to the source, modifying only the destination; move transfers and removes the source; check compares files by hash.
• Bidirectional sync. bisync keeps two paths in sync in both directions, introduced in v1.58 and documented as an advanced command.
• Client-side encryption. The Crypt backend encrypts file contents (and optionally names) before upload and decrypts on download, using a scheme the docs describe as based on the XSalsa20 cipher with Poly1305 for integrity.
• FUSE mount. rclone mount exposes any remote as a filesystem on Linux, FreeBSD, macOS and Windows, with a VFS layer and optional caching.
• Serve. rclone serve can expose local or remote files over HTTP, WebDAV, FTP, SFTP and DLNA, so one cloud account can be presented to clients that only speak those protocols.
• Cloud-to-cloud transfers. Syncing between two different cloud accounts works directly, without first downloading to a local disk.
• Multi-threaded downloads to local disk, and partial syncs on a whole-file basis.
• Chunking and compression. The Chunker backend splits files that exceed a provider's size limit; the Compress backend adds transparent compression.
• Filtering. Include and exclude rules, filter files and --files-from lists control which files a command touches.
• Remote control API. Running with --rc or rclone rcd starts an HTTP API for scripting rclone from other programs.
• Web GUI. rclone gui starts an official browser-based interface bundled with rclone, with a dashboard, an explorer for local disks and remotes, and transfer management.
• Utilities. Commands such as size, about (quota information), dedupe, md5sum, sha1sum, cryptcheck, cleanup and selfupdate cover day-to-day housekeeping.

Getting started

Rclone ships as a single binary. The install docs give a script for Linux, macOS and BSD that checks the installed version first and only downloads when needed:

sudo -v ; curl https://rclone.org/install.sh | sudo bash

Precompiled binaries are available for each platform, and package managers are supported. On macOS, Homebrew works, with an important caveat from the docs: the Homebrew build does not support mount, so a precompiled binary or a source build with the relevant option is needed for mounting. On Windows, Winget, Chocolatey and Scoop are documented:

brew install rclone
winget install Rclone.Rclone

An official Docker image based on Alpine Linux is maintained as part of the release process. The :latest tag tracks the latest stable release and :beta tracks the latest build from master. The container expects the host config directory mounted at /config/rclone (the whole directory, because rclone rewrites the config file when refreshing tokens) and data at /data.

After installing, create a remote with the interactive configuration session:

rclone config

The usage docs recommend the --interactive/-i flag while learning rclone to avoid accidental data loss, and the sync reference repeats that advice because sync deletes files from the destination that are not in the source:

rclone sync --interactive SOURCE remote:DESTINATION

The --dry-run flag (-n) does a trial run with no permanent changes, which is the safest way to check a new sync command. For copying a single file, the docs recommend copy over sync: they have nearly the same effect, but copy uses much less memory.

Mounting a remote

On Linux, macOS and FreeBSD a remote is mounted onto an empty, existing directory:

rclone mount remote:path/to/files /path/to/local/mount

Mount runs in the foreground by default; --daemon forces background mode on Linux and macOS. Windows needs WinFsp installed and supports mounting to a drive letter, a path or a network share. On macOS, either macFUSE (a kernel extension) or FUSE-T is required, and the docs list limitations specific to FUSE-T.

Bidirectional sync

The bisync docs walk through a first run that establishes the baseline with --resync and checks it with --dry-run:

rclone bisync remote1:path1 remote2:path2 --create-empty-src-dirs --compare size,modtime,checksum --slow-hash-sync-only --resilient -MvP --drive-skip-gdocs --fix-case --resync --dry-run

Subsequent runs must leave off --resync, which the docs flag as important. Bisync keeps its state in a working directory under the user cache folder and uses lock files so it can run safely from concurrent cron jobs.

Use cases

• Offsite backups. Sync a server's data directory to object storage such as Backblaze B2, Cloudflare R2 or S3 from cron, optionally through a Crypt remote so the provider only ever sees encrypted data.
• Provider migrations. Copy buckets or drives directly between two clouds, for example from Google Drive to OneDrive or from one S3-compatible provider to another, then verify with check.
• Mounting storage for applications. Mount an object store or a cloud drive so tools that only understand files can read from it, such as a media server reading a library from remote storage.
• Bridging protocols. Use rclone serve to expose an S3 bucket over WebDAV or SFTP to clients that cannot talk to S3, or to serve files over HTTP.
• Encrypted removable media. The Crypt docs note that a crypt remote can point at a local path, which turns rclone into a file-encryption tool for a USB drive.
• Automation and CI. On-the-fly remotes and connection strings let scripts move artefacts without maintaining a config file, and the remote control API lets other programs drive transfers.
• Two-way folder sync. Keep a local folder and a cloud folder synchronised in both directions with bisync, after reading its limitations section.

How it compares

The tagline invites the comparison with rsync. Rsync is built around filesystems and SSH and transfers file deltas; rclone is built around storage APIs and transfers whole files, which suits object stores and cloud drives where block-level deltas are not available. Provider tools such as the AWS CLI or gsutil cover one ecosystem each; rclone trades some provider-specific depth for one interface across many. Backup programs such as restic or Kopia focus on snapshots, deduplication and retention, while rclone copies files as they are; the two are often combined, with a backup tool writing to storage that rclone can reach. These are broad characterisations, and the exact capabilities of each tool are documented in their own projects.

Things to know before adopting

• Licence. Rclone is MIT-licensed, which places few restrictions on embedding or redistributing it.
• sync deletes. sync removes destination files that are missing from the source. The docs repeatedly recommend --dry-run or --interactive before running it for real.
• Bisync needs care. The docs call bisync an advanced command and say to read the entire manual, especially the limitations section, before using it, or data loss can result.
• Config file security. The config file holds credentials for every remote. Passwords stored in it are only "obscured", which the Crypt docs say protects them from cursory inspection and is not secure unless configuration encryption is enabled. Configuration encryption adds a password that must be supplied every time rclone starts.
• Crypt is not reversible on a whim. Because the encryption key derives from the password, the password of already encrypted content cannot be changed; data has to be re-encrypted. Crypt does not hide file length (calculable to within 16 bytes) or modification time. The docs also flag that passwords generated by a specific older range of versions are not considered secure and point to an issue with a checking tool.
• The remote control API is powerful. The rc docs state that access to the API is equivalent to shell access as the user running rclone: it can run OS commands, read and write files and read back stored credentials. They advise never using --rc-no-auth on a non-loopback address and using authentication and TLS.
• Mount dependencies. Mounting needs FUSE on Linux, WinFsp on Windows and macFUSE or FUSE-T on macOS, and the Homebrew build on macOS does not support mount at all.
• Docker defaults. The container runs as root by default, so files it creates are owned by UID 0 unless --user is passed, and mounting inside a container needs extra device and capability flags.
• Backend differences. Hash support, timestamps, case sensitivity and size limits vary by provider. Some remotes treat remote:/path differently from remote:path (FTP, SFTP and Dropbox for business are called out). The overview page is the reference for what each backend supports.
• Deprecations. The Cache virtual backend is marked deprecated in the README.
• Verifying releases. The docs describe how to verify release signatures, and rclone selfupdate can update an existing install.

Project activity

As of November 2026 the repository has about 60,700 stars on GitHub. It was created in March 2014, is written in Go and is licensed under MIT. The latest release at the time of writing is v1.75.2, published in October 2026. Development is active, with commits landing in the days before this write-up, and the project publishes beta builds from master alongside stable releases.

The source is at github.com/rclone/rclone. Documentation, downloads, the changelog and the provider overview are on rclone.org, and support questions go to the rclone forum.

[![Featured on TechLogHub](https://techloghub.com/badge-neutral.svg)](https://techloghub.com/open-source/rclone?utm_source=techloghub_badge&utm_medium=referral&utm_campaign=readme)