Nimbus turns S3, Google Drive, OneDrive, SFTP and fifty more storage services into volumes on your Mac: browse them like Finder, show them in Finder, copy and sync between them, with rclone as the engine.
Nimbus is an open-source Mac app for cloud storage. Each remote from S3, Google Drive, OneDrive, SFTP and the rest of rclone’s long list becomes a volume: a pane with its capacity, its Finder presence, its files and its transfers. It doesn’t reimplement any provider: it drives rclone and puts a native interface on top, including a Finder extension so your remotes show up where your files already are.
rclone is the most capable cloud-storage engine there is, but using it means a terminal and a config file. The usual alternative is one vendor app per cloud, each with its own sync folder and its own idea of how a Mac should behave. Nimbus keeps rclone’s reach and its open config format, and drops the command line.
What it does
A remote is a volume
Select a cloud and one pane shows how full it is, whether it is in Finder, and its Files, Transfers, Finder and Settings tabs. Active transfers sit in a drawer at the bottom and as a progress capsule in the toolbar.
Your remotes, in Finder
A File Provider extension lists your volumes in Finder. Files download when you open them, and edits go back up. Or mount a remote as a network volume; those come back after a restart.
Browse like Finder
System document icons, column headers that sort, Finder’s selection rules, type-to-select, Quick Look, an inspector, and drag between clouds to copy.
Add a remote without the config file
A guided sheet asks only the questions rclone asks for that provider, and providers that use OAuth sign in through your browser. Existing rclone configs import as they are.
How it’s built
One engine, two clients
The app and its Finder extension talk to the same local rclone process through RcloneKit, a typed Swift client for rclone’s remote-control API. The engine’s port is shared through the app group, and no provider is ever reimplemented in Swift.
The rclone contract is tested, not assumed
Listing semantics and the configuration flow are pinned by tests that run the real rclone binary. The lesson written into the project: a mock proves the client’s shape, not the server’s contract.
Finder presence has one owner
Showing or hiding a volume in Finder flips the user’s intent first, then reconciles the File Provider domain in the background, and rolls back if registration fails. The sidebar switch, the header verb and the launch-time domain sync all go through the same code.
Quota from the call already being made
The status probe each remote gets on launch is rclone’s about call, which also returns used and total bytes. The capacity bars and the gauge come from that one response; providers that report no total get no gauge rather than a guess.
Finder-grade list on AppKit
The file table is a virtualized NSTableView hosting SwiftUI rows, so a ten-thousand-item folder scrolls like Finder while the rows stay declarative.
Rules the build enforces
The build fails on hard-coded font sizes, which protects Dynamic Type, and on any remote Swift package dependency.
You seeThe Nimbus app
You seeYour remotes in FinderFile Provider extension
You seeMounted volumesA remote as a Finder volume
RcloneKitA typed Swift client for rclone’s remote-control API, shared by the app and the extension
rclone serve nfsMounted with the system’s own NFS client
rclone, running locallyOne engine for every provider. Nimbus never reimplements one.
S3, Google Drive, OneDrive, SFTP and more than fifty others
One engine, two clients. The app and its Finder extension talk to the same local rclone
through RcloneKit; mounts go through rclone’s NFS server.
On the record
License
GPL-3.0-or-later
Providers
More than 50, through rclone
Tests
About 235 test functions across the app and RcloneKit
Third-party packages
None
Nimbus is open source and before 1.0. The signed builds are free too; Beltr and OneScribe pay for the work.