Rclone
futomaki.rclone-browser
Sync and transfer tool for more than 70 cloud and object storage backends, with copy, sync, move and verify operations, and a browser interface served by its own remote-control daemon.
A Docker Compose file for Rclone alone, generated from the catalog and checked by the safety inspector. Sign in and use Kitchen Credits to activate it.
Uses the Medusa cart and payment-session path. This test control does not create an order or capture payment.
Rclone treats each configured backend — S3, Google Drive, Backblaze, SFTP, WebDAV among many others — as a remote that can be listed, copied from and synchronised against any other, with checksum verification, bandwidth limits and server-side copy where a provider supports it. Beyond one-off transfers it can mount a remote as a filesystem, serve one over HTTP or WebDAV, and expose a control API for scripted operation. Running the daemon with its web interface enabled gives a browser view for configuring remotes and running transfers. A first deployment mounts a persistent configuration file, adds one remote and lists its contents.
You know it worked when
- The daemon starts and its web interface loads in a browser.
- A configured remote appears in the remote list.
- Listing that remote returns its actual contents.
- A test file copies to the remote and verifies with a matching checksum.
- A dry run of a sync reports the changes it would make without making them.
Known sharp edges
- Remote credentials live in the rclone configuration file, which must be a persistent volume and treated as a secret.
- Sync is one-directional and deletes at the destination to match the source, so running it with source and destination reversed destroys data irrecoverably.
- The web interface is fetched at first start and the control API accepts unauthenticated requests unless credentials are set explicitly.
- Transfers to metered providers incur egress and per-request charges that the tool does not surface.