Rclone: one S3 backend, dozens of 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 where each vendor's section in the S3 documentation lives.

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. 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. Many of the remaining dependencies are 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. 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 image creates an rclone user and group with RCLONE_UID and RCLONE_GID defaulting to 1009, but the Dockerfile has no USER line, so nothing in it switches the entrypoint to that account. 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 is that a non-release build's version string is the VERSION file's value plus the -beta suffix.

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.

Getting it, and the absence of a command to copy

The README links to installation pages instead of giving a command. Three 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 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. 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 source directories at the top level include backend/, fs/, fstest/, cmdtest/, lib/, librclone/ and vfs/.

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 through one tool. 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 creates a user with uid 1009. And whether you need a stable release or a development build: non-release builds get a computed -beta tag and are published separately.

Frequently asked questions

Official sources

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