rclone, honestly: what it does better than us
September 2026 · 8 min read · Mayur
We sell a hosted console for object storage. rclone is free, does much of what we do, and is genuinely one of the best pieces of open source software in existence.
Writing a comparison page about a free competitor is usually an exercise in quiet dishonesty: concede one trivial point, then pivot to a wall of things the free tool cannot do. I would rather do the opposite and start with the real list, because if you read nothing else, the honest version is more useful to you than the sales version.
What rclone does better than us
It is free, and it will stay free. Not free-tier free. Free. No account, no limits, no vendor. If your budget for this is zero, the conversation is over and rclone wins.
It supports more backends than we do. Over 70 at last count, including Google Drive, Dropbox, OneDrive, SFTP, WebDAV, Box, and a long tail of things nobody else touches. We cover the S3-compatible family and any custom S3 endpoint. If you need to sync a Google Drive folder to a Backblaze bucket, we cannot help and rclone can.
It is scriptable in ways a console never will be. rclone is a command, so it composes with everything else you have: cron, systemd, CI pipelines, shell scripts, Makefiles. If your workflow is code, rclone fits into it natively and a web UI never will.
It mounts. rclone mount presents remote storage as a local filesystem. That is genuinely useful and we do not do it.
It runs where you tell it to. On your machine, in your VPC, on a box with no internet egress charges, inside your security boundary. No third party is ever involved, which for some organisations is not a preference but a requirement.
Your credentials never leave your machine. This is the honest version of the trust argument, and it favours rclone. With rclone your keys sit in a config file on hardware you control. With us they sit encrypted in our database. We have a good answer about how that encryption works and about IAM-role connect, but "the keys never left my laptop" is a stronger answer and it would be dishonest to pretend otherwise.
It is faster at raw transfer if you tune it. With --transfers, --checkers and --fast-list set well, on a well-provisioned machine, rclone moves bytes about as fast as anything will.
It has been maintained for over a decade by a large community. We are two people who started this in 2026. On the question "will this still exist in five years," rclone has a much better answer than we do.
That is not a token concession list. That is the actual situation, and for a large number of people it ends here: use rclone.
Where it costs you something other than money
rclone is free in dollars. It is not free in attention, and the bill arrives in four places.
1. Scheduling needs a machine that stays awake
rclone sync runs when you run it. To run it nightly you need a machine that is on at night, which means a server, a VPS, a NAS, or a laptop you never close. Then you need cron or systemd, then you need the job to log somewhere, then you need to notice when it fails.
None of that is hard. All of it is a small system you now own and maintain. The question is not whether you can build it. It is whether you want another thing to maintain, and whether you will remember how it works in fourteen months.
2. Verification is your problem
rclone will tell you it finished. Whether it finished correctly, at the level of "every object arrived intact," is a check you construct yourself with rclone check, and interpreting the output on multipart objects requires knowing the ETag caveat.
The pattern I have watched people fall into repeatedly: run the sync, see no errors, assume success, discover a problem eight weeks later. rclone did nothing wrong. Nobody built the verification step, because it was not the interesting part.
3. It is one person's tool
This is the real one for teams.
Your rclone config lives on your machine. Your cron job lives on your server. Your colleague cannot see whether last night's sync ran. When you are on holiday and it fails, nobody knows, and when you leave the company the knowledge leaves with you.
Everything about rclone is designed around one competent person. That is a strength for one competent person and a liability for a team of five.
4. It moves bytes; it does not govern buckets
rclone copies, syncs, mounts, and lists. It does not tell you which of your buckets are publicly readable, whether versioning is on, what lifecycle rules exist, whether object lock is configured, or what any of it costs.
Those questions are the ones that arrive with an auditor or an invoice attached, and rclone is not the tool for them. That is not a criticism. It is a different job.
What we actually sell
Given all of the above, the honest description of what a hosted console is for:
Scheduling without a server. The sync runs whether or not any machine of yours is awake, and it says so.
Verification you did not have to build. Object counts, sizes, and completion status reported, with resume if the connection drops.
A team can see it. Your colleague opens the console and sees the same state you do. Nobody has to be online for the system to be legible.
Governance in one place. Lifecycle, versioning, CORS, object lock, bucket policy, public access, across every connected provider, with the interface adapting to what each specific bucket actually supports.
Cost visibility. What each bucket costs, what it would cost elsewhere, and an alert before the next bill surprises you.
No per-gigabyte charge for moving your data. Which matters because several tools in this category do charge, and rclone does not, so on this specific point we match rclone rather than beating it. It is worth saying plainly: we are not cheaper than free.
How to decide
Use rclone if:
- It is just you
- You are comfortable in a terminal and enjoy it
- You have a machine that stays on, or you do not need scheduling
- Your budget is zero
- You need a backend outside the S3-compatible family
- Credentials leaving your machine is unacceptable
- You want to mount storage as a filesystem
Use a hosted console if:
- More than one person needs to see what is happening
- You want scheduled jobs without maintaining a machine
- You need to answer governance questions (which buckets are public, is versioning on, what does lifecycle do)
- You want cost comparison across providers without reading five pricing pages
- You would rather spend $9.99 than an evening, which is a completely legitimate trade
Use both, which is what most technical people actually end up doing. rclone for the scripted, composable, local work. A console for the scheduled, shared, and governance work. They are not really competitors; they occupy different parts of the same job.
The honest bit
I am not going to argue that rclone is bad, because it is not, and you would not believe me.
The argument is narrower than that. rclone is a superb tool that assumes a competent operator with a machine and time. Everything it does not do is a thing you can build. The question is only whether building and maintaining those things is a good use of your particular hours.
For a lot of people it genuinely is, and those people should not pay us anything.
Questions people actually ask
Is there an official rclone GUI?
There is rclone rcd --rc-web-gui, a built-in experimental web interface. It is functional and it is not the same thing as a hosted, multi-user, scheduled service. RcloneView is a third-party desktop GUI at around $19.80 a year.
Can I use rclone and Storafleet together? Yes, and plenty do. They connect to the same buckets with the same credentials. Nothing conflicts.
Does Storafleet use rclone under the hood? No. We have our own transfer engine, which is what lets us run jobs server-side, resume them, and integrate provider-native fast paths like Cloudflare's Super Slurper.
Is rclone faster? On a well-tuned machine with good bandwidth, for a single large transfer, probably. Our advantage is not raw speed, it is that the job runs without you.
What about rclone's encryption?
rclone crypt encrypts filenames and contents client-side before upload. It is excellent and we do not offer an equivalent. If client-side encryption is a requirement, that is another point for rclone.
Why not just write a cron job? You absolutely can. Then you own a cron job. That is the entire decision, and for many people the cron job is the right answer.
If the shared, scheduled, governed version is the part you want, that is what we built, and the free tier connects real buckets so you can find out in ten minutes. Connect a bucket, free, no card.