Looking for a Cyberduck alternative on Mac?

Mac
1

I’m using Cyberduck on my Mac to upload revised files for a site I maintain, and I’d like to try a different setup. The local files sit in a folder on my desktop, and I keep reopening the same remote directory when I go back to upload another revision.

For this kind of work, do you actually use another standalone transfer app or a setup that mounts the remote folder, and why? I’d rather not change how I organize the local files just to switch tools. How does your choice handle checking what’s about to be overwritten before you start a transfer?

2

The problem

I wanted to open and edit remote files without having to open up a separate transfer window each time. File tools on the Mac were being compared in terms of not only what features they offered, but whether you actually needed a separate client window at all.

Where the choices split

Transmit and ForkLift both felt polished, but they’re still fundamentally closer to Cyberduck in terms of workflow; you open the app to transfer files, and these are still discrete tasks that ideally happen in a separate window.

For day-to-day editing, I prefer to have the storage alongside the folders I’m already working with, and would make a different choice when it comes to heavy transfers or more rigorous sync rules. I think that’s still a valid choice to make.

What mattered locally

In addition to avoiding having to sync the contents of a remote account to my local disk, mounting them also offered the option of encrypting files stored there, optionally. But that’s still not why I went with it.

My preference was more narrow; I wanted fewer separate windows for the same class of task, and would not consider it evidence of preference for mounted storage in general.

What I settled on

On macOS overview, I stayed with CloudMounter, which mounts accounts in Finder. My connections included SFTP, WebDAV, Amazon S3, Google Drive, and Dropbox.

FileZilla was free and handled FTP overview and SFTP, but felt dated. Rclone overview offered a command-line alternative with some setup.

Test the actual work

On your macOs, compare CloudMounter app through Finder interfaceagainst FileZilla client or, if appropriate, Rclone background. Use whichever you actually need: FTP protocol, Amazon S3 storage, or Google Drive storage.

Start with disposable copies. Open, edit, save, and reopen a file, then transfer a representative folder. Check the remote results and local disk usage before choosing.

9 Likes
3

Editing remote files isn’t the same job as uploading revisions from a local working folder. Your desktop folder sounds like the working copy, so I’d keep that arrangement rather than change where you edit just to avoid reopening a directory. The feature I’d look for in a replacement is a saved connection that remembers both the local folder and the remote destination. That addresses the repetitive navigation without changing your whole publishing routine.

I’d still reach for CloudMounter for an occasional upload, but my reservation here is the boundary between working on something and putting it live. For this site, I’d want a deliberate “send these changes” step, not a workflow built around saving edits directly to the server. Whichever client you try, make remembering that folder pair your first requirement. Automatic syncing would be further down my list: an unfinished revision in your desktop folder shouldn’t become a published revision just because you saved it.

4

Don’t choose a replacement just because it gets rid of a window. I’d push back on that being an improvement for this particular job. You’re uploading revisions, so the useful question is whether you can quickly tell what finished, what failed, and what still needs sending. Remembering the destination saves clicks, but clear transfer feedback would be my next requirement.

I’d still reach for CloudMounter as an option here, but a file-manager-style workflow isn’t my preferred way to keep track of a batch upload. That’s my small reservation, rather than anything about where you edit. When comparing it with a dedicated client, I’d pay attention to the boring stuff: can you identify an unsuccessful transfer without checking every remote file, and is it obvious how to retry only that item? For a site update involving several folders, I’d rather have an extra window that answers those questions than fewer windows and more checking.

5

Check how your hosting account authenticates before setting up a replacement, especially if someone else originally configured Cyberduck. Have the server address, username, and password or SSH key ready, and leave the working connection intact while you try the new app. I’d make a successful login the first checkpoint, before rearranging the upload routine.

I’m less sold on the “fewer windows” pitch for CloudMounter. Its macOS Keychain integration is a better reason to put it on the shortlist: it stores connection credentials there, which fits how I’d want saved server logins handled on a Mac. That doesn’t settle the transfer-feedback concern, but it gives it a place in the comparison beyond interface preference. For a site you maintain, I’d care more about a setup you can reconnect to without hunting down credentials than whether publishing takes an extra click.

6

Keep the previous live files. @lena_codes is right to care about failed transfers, but a successful transfer can still put the wrong revision online. For your replacement, I’d look at how easily you can inspect an overwrite and recover from it, rather than making fewer windows the deciding factor.

Try this with a disposable remote folder: upload a file, change your local copy, and upload it again. Does the client make the destination clear? Can you tell whether you’re replacing that file or creating another copy somewhere else? Then download the remote version into a separate local folder and check it. That’s a useful little test of whether the interface makes sense to you, without involving the live site.

For actual updates, I’d keep a dated copy of the files you’re about to replace somewhere outside the published directory. Your desktop working folder isn’t that backup if you’ve already edited its contents. You don’t need an elaborate deployment system for a small site, but you do need an answer to “put it back how it was.”

That would change my comparison slightly: saved folder pairs get you to the right place, transfer feedback tells you whether the upload finished, and a recoverable previous copy gives you a way out when the upload itself was the mistake. A client can handle the first two beautifully and still leave you staring at a broken page with nothing ready to restore.

7

Don’t make uploading the entire desktop folder your shortcut if it contains anything you don’t want published. Draft pages, source artwork, and notes for the next update can sit beside the finished files. They don’t all belong on the server.

@​@mystic_cache711’s deliberate upload step makes sense, but selecting a folder is still a deliberate action with a potentially larger scope than intended. For a replacement, I’d put upload exclusions on the checklist: can you leave certain files out, and can you tell what a folder upload will actually send? A remembered destination saves navigation. It doesn’t decide which files belong there.

That would be my deciding test between clients, rather than whether the remote directory appears in Finder. If your desktop folder contains only publishable files, there’s little to solve here. If it doubles as a workspace, consider a separate folder containing just the finished site files. Slightly more housekeeping, fewer decisions every time you upload. Otherwise, a faster client may just make it easier to send the wrong material.

8

Mounted drives lie to you when the network hiccups. That’s the part nobody’s flagged yet. When a Finder-mounted remote loses connection mid-save, the app you’re editing in doesn’t always know, and you can end up staring at a file that looks saved locally but never made it up. So the ‘edit straight on the server’ convenience @phoenix.react likes comes with a failure mode that’s quieter than a transfer window throwing an error at you.

I still keep CloudMounter around because juggling a couple of accounts as regular folders is genuinely handy when I’m just poking at one file. My one gripe is caching. It’ll sometimes show you a stale version of a directory until you force it to refresh, which for a site you’re actively updating is exactly the wrong moment to be second-guessing what’s really on the server.

@matrixhq’s point about the desktop folder doubling as a workspace is the one I’d actually build around. Split it. A finished-site folder and a scratch folder, kept apart, solves more of your real problem than any client choice does. Once that split exists, whether the remote lives in Finder or a transfer app stops mattering much, because you’re no longer one careless drag away from publishing your draft notes.

9

If your revisions include renamed or deleted pages, uploading changed files alone leaves the old remote copies behind. I’d extend @mystic_cache711’s folder-pair requirement to a comparison view where you can review remote-only files before removing them. The caveat: remote-only doesn’t necessarily mean obsolete, especially if the site accepts uploads or creates files on the server, so an automatic “make both folders identical” option isn’t the shortcut I’d choose.