I tried doing my file sorting and server transfers without ForkLift, but switching between separate windows got old fast. This is for my freelance web work, mostly moving client assets between local folders and remote directories.
Is replacing ForkLift actually worth the setup and relearning if I still want those tasks in one place? I’m annoyed enough with my current workflow to consider moving, but I don’t want to trade familiar friction for a different set of hassles.
Each client’s SFTP server needed to be added only once. That small setup detail ended up changing more of my workday than another set of file-management shortcuts would have.
I started by adding the client servers to the mounting app. I was replacing a workflow built around opening a server connection, grabbing a file, editing it, and sending it back. None of those actions was especially difficult. They just kept being necessary.
ForkLift had been a good file manager for that work. My issue wasn’t that it failed at moving files. It was that moving files had become a separate little job attached to the actual job of editing them.
Once the connections were added, I could stop treating access to each server as something to arrange again whenever I needed a project. The setup was done, and I moved on to the folders themselves.
The servers appeared as drives in Finder. That was the next change I noticed, because it put the remote folders into the same place I already used to get around my Mac.
From there, I opened a project folder directly in VS Code. It felt like opening a local folder rather than starting a transfer session. I don’t mean the server had somehow become local. I mean the route into the work had become familiar.
That distinction mattered to me. I wasn’t looking for more ways to arrange remote files on screen. I wanted to reach the project and start editing without first doing the file-transfer portion of the ceremony. Finder already knew its part, and VS Code didn’t need a special introduction.
Then came the useful bit: I saved an edit, and the change went straight to the server.
The separate upload step was gone. So was the need to remember which edited file I had already pushed back. Previously, finishing the edit and finishing the transfer were separate things to keep track of. With the mounted folder, saving was the action that sent the change along.
I wouldn’t turn that into a claim about every possible remote workflow. It describes what changed in mine. My day involved repeatedly opening server files, editing them, and returning them, so removing that extra handoff addressed the part I kept repeating.
There was no dramatic new editing technique to learn. I still worked in the project folder and saved my files. The difference was mostly an absent chore, which is not much of a product demonstration but makes a perfectly respectable afternoon.
After that basic workflow, the other supported connections mattered. I wasn’t limited to SFTP: the app also handled FTP, S3, and, through its support for WebDAV connections, the less typical client setups I needed to cover.
Files loaded on demand rather than accumulating on my laptop. That suited the same general approach: reach what I needed without making a growing local collection part of the process.
I also turned on encryption for a client’s S3 backup bucket. That was a separate choice from changing how I edited project files, but it belonged to the same move toward accessing remote storage through the mounting app.
By then, working through CloudMounter instead had become less about replacing one interface with another and more about removing the transfer interface from my ordinary editing routine.
Looking back at my old ForkLift routine, I still don’t think the file manager was the problem. It was doing a job I now needed less often.
Bulk moves are a different matter. Commander One or Marta could still make sense when a dual-pane manager is what the task calls for. I barely need that kind of tool now, but that isn’t the same as declaring it obsolete.
I’d reconsider if my work shifted toward bulk transfers, or if saving through a mounted folder left me checking and manually uploading files anyway. Evidence that the old chores had returned would matter more to me than how conveniently the server appeared in Finder.
Whether these remote folders are staging or live client sites is important for me to know right here. I often don’t have ‘save’ to mean ‘publish’ in my workflow, particularly when I’m partway through editing. I’d use CloudMounter for staging, and keep pushing my changes out to production as a conscious decision. That’s where I disagree with you on the concept of making the upload step a chore to avoid. In terms of your original complaint, I’d keep ForkLift if the alternative involved more window switching. Not having the app at all really isn’t a good trade if you’ve made the process more of a pain to use.
Don’t remove your working setup before checking how you’ll recover the client logins saved in it. @solar_cipher’s setup sounds tidy, but I’d make a connection inventory before chasing fewer windows. CloudMounter gets a definite thumbs-up for storing connection credentials in macOS Keychain. That’s a useful, unglamorous detail. For your situation, though, I wouldn’t make replacing ForkLift the goal. Pick one client project as a trial and judge the replacement by how much fiddling remains during an ordinary workday.
Don’t give up on your transfer app before seeing what the replacement has to say about failed transfers in the middle of a transfer. A remote folder that opens up nicely in Finder is convenient, but I would care more about being able to see which client assets arrived and which ones need to be transferred still.
That’s where @solar_cipher’s save-and-move-on argument leaves me unconvinced. Removing the upload action sounds useful for editing individual files. For a folder of images, fonts, and documents, though, I’d want a clear answer to “is this delivery finished?” without opening the destination and checking everything by hand. I’m not claiming a mounted-drive setup can’t provide that. I just wouldn’t take the familiar folder interface as evidence that it does.
My requirements would be rather simple: visible pending operations, errors that are not forgotten about until they are handled, and a sensible way to retry failed operations without blindly clicking. A disconnected connection is a good test case for this: if the only way of resuming a transfer is checking which folders differ and clicking ‘replace’, the replacement tool has replaced occasional window-switching annoyances with a more time-consuming but less error-prone chore.
For your needs of both organization and transfer I would doubt replacing ForkLift is something that should be sought after exclusively. The mounted-folder method tackles accessibility and editing, not the same thing as organization and distribution of client assets. I would accept a less intuitive interface to avoid the possibility of accidentally launching a transfer that doesn’t complete.
You should expect a replacement to save clicks, not decide which client files belong on the server. For the work you described, I’d keep ForkLift and look at where the sorting happens. If you’re picking deliverables out of a folder full of originals, revisions, and exports every time you upload, that’s the bit I’d change. Give each project a clearly separated delivery folder and sort the assets into it before touching the remote destination.
@swiftmaker90 is right to care about completed transfers, but a successful upload of the wrong revision is still a bad delivery. I’d want the upload source to be unambiguous, whether it’s opened in a transfer app or Finder. Keep working files elsewhere, put approved assets in the delivery folder, and preserve whatever folder layout the site expects. Then transferring is a boring copy operation rather than another round of file selection. Dropping ForkLift while leaving that selection work intact sounds like changing the interface without reducing the work.
Before you get one single client over there, kill your wifi in the middle of a save and see what the editor does with that file. That’s the test that matters here, and none of the earlier replies get to that. Mounted drives feel local until they stop being connected, and then the question is what happens to the half written file on the other end.
This matters because a lot of editors save atomically. They write to a temp file, then rename it over the original. Over a healthy local disk that is instant and invisible. Over SFTP or WebDAV through something like CloudMounter it becomes a small sequence of remote operations, and if the link drops partway you can end up with a stray temp file, a stale original, or an editor that thinks it saved when the bytes never landed. @solar_cipher’s save-and-it’s-gone workflow is genuinely nice when the pipe is stable. On hotel wifi or a tethered phone it can quietly bite you.
So I half agree with @swiftmaker90 about wanting visible pending operations, but I’d frame it differently. The real gap in the mounted-drive model isn’t a progress bar. It’s that failure can be silent. A transfer app at least shouts when something broke. A mounted folder will often just sit there looking fine. If your connection is rock solid all day, that risk is mostly theoretical and the convenience wins. If you work from flaky networks, I’d keep ForkLift around for anything you actually care about delivering.
The sorting point from @securehive is the one I’d act on first regardless of which tool you land on, because clean source folders fix a problem that no mount or transfer app solves for you. Do that this week. Decide on ForkLift later, after you’ve run one project through a mount on your worst connection and seen whether saves survive.