Rclone: one S3 backend, forty provider anchors, and a VERSION file

One S3 backend carries most of the provider list

The provider list in the README is long, and its structure is the useful part. A large group of entries does not link to a page of its own, it links into the S3 documentation with an anchor: Alibaba Cloud OSS, ArvanCloud, Bizfly Cloud, Ceph, China Mobile Ecloud, Cloudflare R2, Cubbit DS3, DigitalOcean Spaces, Dreamhost, Drime, Exaba, Fastly, Hitachi HCP, Huawei OBS, IBM COS, Impossible Cloud, Intercolo, IONOS, Leviia, Liara, Linode, Magalu, MEGA S4, Minio, Outscale, OVHcloud, Petabox, Qiniu, Rabata, RackCorp and others. Those are not thirty backends, they are one S3 implementation with a vendor section each. The consequence for a reader is that the provider count overstates the code, while the anchor list tells you exactly where the per-vendor differences live: endpoint, region, signature version and path style.

go 1.26.0 and a debug flag for negative certificate serials

The module declaration is not incidental. go.mod names the module github.com/rclone/rclone, sets go 1.26.0, and carries a godebug line reading x509negativeserial=1. That flag changes how the Go runtime validates X.509 certificates, permitting negative serial numbers, which tells you the binary is built to talk to endpoints that hand out such certificates rather than by accident. The dependency list is where the platform ceiling shows. coreos/go-systemd/v22 is pinned to v22.6.0 with a comment stating that v22.7.0 fails to compile on netbsd and should not be upgraded until it is fixed upstream. So building from source has two hard floors: a Go toolchain at 1.26.0 or newer, and a NetBSD target that is knowingly held back. The rest of the module is provider SDKs, from the AWS v2 set through Azure, Dropbox, Cloudinary, HDFS and SMB.

The container runs as uid 1009 with its config on a volume

The Dockerfile is more informative about deployment than any prose. The builder is golang:alpine with CGO_ENABLED=0, so the binary is static, and the dependency install is make, bash, gawk and git, which is why a source build wants gawk rather than a busybox awk. The final image is alpine:latest with ca-certificates, fuse3 and tzdata, and it writes user_allow_other into /etc/fuse.conf, which is the setting a FUSE mount needs when the mount is requested by a different user. The account is created with RCLONE_UID and RCLONE_GID defaulting to 1009, so the container matches a host user rather than running as root. Two environment decisions follow from that: WORKDIR is /data, and XDG_CONFIG_HOME is set to /config. The consequence for an operator is that your remote definitions are not in the image, they are a volume, and a container started without one has no configuration to work from.

The version is a text file, and untagged builds go to a beta host

The Makefile reads the version rather than deriving it from a tag. VERSION is the output of cat VERSION, and the file sits at the repository root as its own entry. From that, awk computes NEXT_VERSION by incrementing the minor component and NEXT_PATCH_VERSION by incrementing the patch, which is the release tooling deciding the next name mechanically. A build that is not on a release tag gets a suffix built from the commit count and the short hash, forming a tag shaped like -beta.NNNN.CCCCCCCC, and those builds are published under branch paths at https://beta.rclone.org/. The upload target is the host beta.rclone.org. The consequence: there is always a public build of whatever is on your branch, and a version that is not in the VERSION file cannot be what you are running. When a bug report arrives, that file is the first thing worth asking for.

WebDAV, Swift and SFTP providers share a page with the vendor options

The same anchoring trick appears outside S3, and it is a fair guide to what a provider costs you. Nextcloud, ownCloud and Fastmail Files all point into the WebDAV documentation. Memset Memstore, Blomp, OpenStack Swift, Oracle Cloud Storage, OVHcloud Object Storage on Swift, and Rackspace Cloud Files point into the Swift documentation. rsync.net and Hetzner Storage Box point into the SFTP documentation. FTP, HTTP, HDFS and a Memory backend each have their own page. So a name appearing in the provider list does not mean bespoke work, it usually means a configuration section on an existing backend. Two consequences follow. Adding a provider is often a config exercise rather than a code change, and the per-provider page is where authentication details live, because no credentials or configuration example appear anywhere in the repository.

Getting it, and the absence of a command to copy

There is no install command in the README and no example invocation, which is unusual for a tool this widely used. Instead four destinations are linked. The installation page at rclone.org/install/ and the downloads page at rclone.org/downloads/ are the two a person follows, and the Docker Hub image rclone/rclone is the third, built from the Dockerfile described earlier. The fourth is the beta stream, which is a build channel rather than a download page. The consequence is that a first run is not copy and paste from this repository. You choose a source, then read the install or backend page for the actual command, and for Google Drive specifically that is the page at rclone.org/drive/ rather than anything here. If you need a self contained quick reference, MANUAL.md, MANUAL.txt, MANUAL.html and the rclone.1 man page are in the tree, which is where the invocation syntax lives.

Four manuals, two linters and two test harness directories

The top level carries MANUAL.md, MANUAL.txt, MANUAL.html and rclone.1, which is the same documentation held in four formats because the output formats differ by platform. Alongside them sit RELEASE.md, notes.txt, MAINTAINERS.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, AGENTS.md and CLAUDE.md, so release and process information is in the repository rather than only on the website. Two configuration files at the root, .golangci.yml and .markdownlint.yml, mean both the Go code and the documentation are linted. The test structure is the part that matters if you are reading the source: fs/ holds the backend implementations, fstest/ is the shared test suite run against them, and cmdtest/ sits next to it for command level tests, with backend/, lib/, librclone/ and vfs/ completing the picture. That layout is what tells you adding a provider means writing a backend and inheriting the suite, not writing tests from scratch.

Editorial conclusion

Rclone earns its place when your data lives in object storage that has no native Unix filesystem, or when one script has to reach Google Drive, Dropbox, Backblaze B2 and an S3 bucket without four sets of credentials. It is the wrong tool when both ends are local disks, where rsync already does the job with less configuration. Verify four things before you depend on it. Which backend your provider actually maps to, since much of the provider list is one S3 implementation with per-vendor anchors. Which Go version you need if you build from source, because go.mod declares 1.26.0. Where your configuration lives in a container, since the image sets XDG_CONFIG_HOME to /config and expects uid 1009. And that you can live with a beta stream, because every untagged build is published to beta.rclone.org under a computed tag.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes