rclone crypt 2026: encrypt your cloud files client-side before upload

The essentials

rclone crypt is a client-side encryption overlay built into rclone, the open-source command-line tool that manages and syncs files across 70+ cloud providers. The crypt backend wraps another remote and encrypts the content of your files — and, optionally, their names — on your own machine before they upload, then decrypts them on download. The provider only ever stores ciphertext. That makes any cloud you point it at effectively zero-knowledge.

Who is it for? Anyone comfortable in a terminal who wants encryption that is scriptable and automatable: nightly encrypted backups, a headless server with no GUI, or simply adding client-side encryption on top of a provider — Google Drive, Backblaze B2, S3, OneDrive — that offers no native zero-knowledge mode. If you'd rather not touch a command line, Cryptomator covers the same goal with a graphical vault, and we compare the two below.

This guide explains exactly how rclone crypt encrypts, how to set it up step by step, the filename modes, and one honest trap most tutorials skip — the way rclone.conf stores your password.

How it encrypts (content and names)

rclone crypt does all its work locally, with documented primitives:

• File content is encrypted with XSalsa20-Poly1305, the authenticated cipher from the NaCl SecretBox construction. Authenticated means tampering is detected on download.
• The encryption key is derived from your password using scrypt (a memory-hard key-derivation function), with an optional second password — called a salt, or password2 — to harden it further.
• Filenames, in the default standard mode, are encrypted with EME (an AES-based wide-block mode), so a changed character anywhere changes the whole encrypted name.

What stays visible to the provider with full encryption on: roughly the size of each encrypted file and the number of files. Not the content, not the names. This is the same principle of moving trust to a local password that underpins all client-side encryption.

Setting up rclone crypt (config steps)

The setup is two remotes: a base remote that talks to your cloud, and a crypt remote that wraps it. You drive it all through rclone config.

1. Create the base remote. Run rclone config, choose n (new remote), name it (e.g. gdrive), and follow the provider's prompts (OAuth for Google Drive, keys for S3/B2, etc.).
2. Create the crypt remote. Run rclone config again, n for new, name it (e.g. secret), and pick the crypt backend.
3. Point it at a sub-path of the base remote, so the encrypted blobs land in a dedicated folder:

remote> gdrive:encrypted

4. Choose the filename and directory encryption modes (see the next section), then set a password and, optionally, a second password (salt). You can have rclone generate a strong random one.

Once the secret: remote exists, encrypting and uploading is a single command:

rclone copy ~/files secret:

Everything written to secret: is encrypted locally and stored under gdrive:encrypted. Reading back (rclone copy secret: ~/restore) decrypts transparently. The same pattern works for rclone sync, rclone mount, and any other rclone command.

Filename encryption modes

When you create the crypt remote, rclone asks how to handle filenames. Three modes:

Directory name encryption is a separate yes/no toggle. Turning it on hides your folder tree from the provider too. If you set both filename and directory encryption to off, only the file content is protected and the provider can see your full folder layout — useful metadata for an attacker, so prefer standard unless you have a specific reason not to.

The rclone.conf trap (obscured password)

This is the caveat most guides skip, and it matters. By default, rclone stores your crypt password in rclone.conf obscured — not strongly encrypted. Obscuring is reversible: anyone who can read the file can recover the password (rclone reveal does exactly that). A leaked rclone.conf therefore leaks your encryption key.

Two things to do:

1. Set a configuration password. In rclone config, choose Set configuration password (s). This encrypts the entire rclone.conf file, so the obscured crypt password is no longer readable without that config password.
2. Lock down the file. Restrict permissions (chmod 600 rclone.conf), keep it off shared or backed-up-in-clear locations, and treat it as a secret on any headless server.

And one rule with no workaround: if you lose the crypt password, your data is unrecoverable. There is no reset, no recovery key, no support line. Back the password up in a password manager with an encrypted offline copy.

rclone crypt vs Cryptomator (which to choose)

Both are open-source, client-side, and zero-knowledge. The difference is the interface and workflow, not the security model.

Choose rclone crypt if you automate backups, run a headless box, or want encryption on top of any of rclone's remotes from the command line. Choose Cryptomator if you want a click-to-mount vault you also open on your phone. They aren't rivals — plenty of people use rclone crypt for server backups and Cryptomator for daily desktop and mobile files. To pick a provider to put underneath either tool, see our encrypted cloud storage services overview.

Conclusion

rclone crypt turns any of 70+ cloud providers into a zero-knowledge target with battle-tested primitives — XSalsa20-Poly1305 for content, scrypt for the key, EME for names. It's the right tool when you want automatable, scriptable client-side encryption, especially on a server. The two things to get right are honest ones: pick standard filename encryption unless you have a reason not to, and protect rclone.conf with a configuration password, because the stored crypt password is only obscured, not encrypted. Do that, keep a safe backup of the password, and you have client-side encryption that survives the provider being breached or subpoenaed.

FAQ

The most common questions are covered in the structured FAQ block above (also shown in the Google rich snippet): what rclone crypt is and who it's for, the cryptography it uses, filename and folder encryption, the safety of the password inside rclone.conf, and how it compares to Cryptomator.