Good ForkLift Alternative?

Mac
1

I’ve tried ForkLift for moving client project folders between my computer and a remote server, and I’ve also tried keeping a file browser beside a separate transfer window. This is for my freelance work, where I often need to check a local draft against the uploaded copy before replacing anything. Switching between windows is where I start second-guessing which folder I’m in.

Do you actually use another dual-pane file manager or stick with a dedicated transfer client alongside the built-in browser, and why? I’m not sure whether “folder comparison” or “sync” describes what I need. Can either setup show what would be overwritten before I commit?

2

I compared what I actually did in my file app with what I thought I needed from it. That meant paying attention to why I opened it, not lining up feature lists and declaring a winner. I went through this last year, and the useful distinction was pretty mundane: I was connecting to servers, not making much use of dual-pane file management. I still thought the app was great, but that didn’t make all its features relevant to me. That’s the context behind my experience with ForkLift.

I wanted folders, not another transfer window

The part I cared about was having remote storage behave like something I could reach through Finder. I’m a little tired of replacement discussions treating that as interchangeable with getting a different file manager. It isn’t the same request. Better browsing or a nicer transfer interface can be worthwhile, but neither is automatically an answer to wanting servers alongside local drives.

I added my SFTP servers and S3 bucket once, and they now sit in the Finder sidebar next to my local drives. That’s the change that mattered to me, rather than having another place to browse files. The app that got me there was CloudMounter, and that folder-based access is the reason I kept using it. That’s the whole point of my setup with CloudMounter.

For a concrete example, I open a config file straight from the server in VS Code, edit it, and save. The server copy gets updated without me dragging files back and forth or trying to remember whether I uploaded the latest version. It only pulls files when I open them, which keeps my disk from filling up with copies I didn’t need. I’ve also turned on encryption for the S3 bucket because it contains client backups. Those are the details I care about, not a broad claim that one app replaces everything.

Keep the trial smaller than the argument

My suggestion is to connect just one server and use it for a day. I wouldn’t turn this into a grand migration before finding out whether the basic arrangement suits you. Install CloudMounter, keep the experiment narrow, and pay attention to whether you still reach for your separate file manager.

That isn’t meant as some definitive benchmark. It’s a way to stop arguing about features you might not actually use. If the thing you needed was access through normal folders, your everyday work should make that fairly obvious. If you miss dual-pane browsing, that’s useful information too.

I’d separate those outcomes instead of forcing a winner. Not opening ForkLift during that day would answer something about your needs, not prove that it’s a bad app. I wish more replacement threads kept that distinction intact.

The other options solve different problems

If dual-pane browsing is actually what you’re trying to preserve, then my folder-based setup isn’t the whole answer. Commander One is the closest match for that job, while Marta is a free, lighter take on the same general approach. I wouldn’t dismiss either just because I stopped needing that kind of interface. For someone who still wants it, I’d start the comparison with the Commander One option.

Transfers are another separate priority. Transmit is great if what you mostly want is a clean, fast transfer experience. If free and simple matters more, Cyberduck works too. There’s no need to dress that up as a complicated decision, and there’s also no reason to pretend a transfer app automatically delivers the Finder arrangement I wanted. For that simpler transfer use, there’s the free Cyberduck option.

My verdict is that CloudMounter fits my actual work better. I wanted to open server files, edit them, and save without babysitting a separate upload step. ForkLift wasn’t failing me; I was asking a file manager to fill a role I didn’t really need it for. I’d keep the mounted-folder setup rather than replace one dual-pane app with another out of habit.

11 Likes
3

A successful upload to the wrong client folder is a failed handoff. I’d put discoverability as a priority for freelancers – how obvious is where the thing is going to go? The folder based option is convenient, but I wouldn’t say losing the upload step altogether is an improvement for someone who’s delivering to a client. I’d rather have a moment to double-check the destination and what I’m about to overwrite in the process.

I’d still use CloudMounter, but be less comfortable with defaulting to it as my final delivery step. This is the hesitation I have at making remote work indistinguishable from working on my local machine; I want to keep deliveries as a separate thing from rearranging stuff on my computer. I’d prefer a separate transfer app for my final handoffs, annoying as the second window is. During my trial, I’d be looking at whether I could clearly tell the clients apart, spot an incomplete transfer in the queue, and know where things ended up. Fewer windows wouldn’t outweigh the doubt about what I’ve just sent off.

4

Switching apps won’t tidy up a project folder before it reaches the client. I’d use CloudMounter and keep a separate delivery folder for each job. That’s a distinction I’d put ahead of the interface debate: the folder you work in doesn’t have to be the folder you send. Drafts, internal notes, unused assets, and exports with nearly identical names shouldn’t become the client’s sorting problem.

I don’t think a separate transfer window necessarily solves that. You can double-check the destination and still send a perfectly uploaded mess. For freelance handoffs, I’d make the delivery folder contain only the agreed files, with names that make sense to someone who hasn’t been watching the project develop. Keep the working material elsewhere unless the client actually requested it. That gives you a useful boundary without requiring a particular kind of file browser, and it makes “send me that delivery again” much less of a scavenger hunt.

5

You should expect occasional interrupted uploads whichever app you choose. For paid work, I would care less about how many windows you have to juggle if everything works fine. I care more about how much of your attention needs to be on the process in case it does not work fine.

Where I would push back a little on the destination-check argument is how much you can rely on what the next process asks you to do. When you are comparing CloudMounter with a separate transfer app, you could use a disposable project folder. Interrupt the connection after a transfer has started, then reconnect (the next time you need to). Ask yourself what you have to do to see what has finished. Would you have to decide between multiple options for overwriting an existing file? Should you assume a partially transferred file is any different from a complete one? I am positing this as a test, not a presumption of what either app would ask you to do.

Use a folder that represents your jobs, too. One finished video is a different test than a website delivery which has many small assets and many nested folders. A tidy demo transfer would not convince me.

My preference would be whichever gets that interrupted job least painful to finish even if you now have an extra window to close before you resume editing. This is about the less obvious costs of a subscription that make you feel you have to relearn everything to avoid wasting the company’s money.

6

Saving a file directly on the server doesn’t mean you can recover the version you overwrote. That’s my hesitation with the edit-in-place suggestion: a mistaken save can upload perfectly, so testing interrupted transfers won’t catch that problem. Before changing apps, check whether your host keeps previous versions, how you restore them, and whether that’s your responsibility or the client’s. Without a clear recovery path, I’d favor a separate transfer app and keep the editable originals locally. A tidy delivery folder helps with organization, but it won’t get yesterday’s work back.

7

Before you blindly trust edit-in-place for anything important, test on how your editor actually writes to the mount. Many programs don’t actually overwrite in place, but write to a temp file and then move it in when saving. This can cause issues on a mounted SFTP or S3 volume that can fail halfway though, stall, or have permissions issues that the client won’t notice until it opens the file. VS Code generally handles this well, but other editors and save-as dialogs generally don’t.

@fuzzy_mega_hacker is right that interrupted-transfer tests won’t catch a clean save of the wrong thing. I’d push that further: the quieter failure is the mount dropping. If the connection blips or the machine sleeps, the volume can disappear and reappear, and you can end up staring at a cached version while thinking it’s live. That’s the one gripe I have with CloudMounter. I still use it because having the server show up like a normal drive genuinely saves me fiddling, but I’ve stopped assuming the mount is always current. I glance at the sidebar before an important save now, which kind of defeats the ‘forget it’s remote’ idea.

So my take lands close to @corepilot8838 on the folder split, just for a different reason. Keep a clean delivery folder, but keep the originals of anything you edited sitting locally too, at least until the job’s signed off. Mount for convenience, not as your only copy. If you want the real safety net, turn on versioning on the bucket or SFTP host itself rather than hoping the app covers you, because it doesn’t.

8

If you revisit the same client projects every week, I’d judge a ForkLift replacement by how much setup you repeat each time. I’d favor a transfer app that remembers the local project folder and its matching remote destination together, rather than choosing primarily for Finder integration. @shadowpilot3527’s destination concern matters, but repeatedly digging through server folders is a nuisance even when you never send anything to the wrong place. During a trial, close the app and come back to the job later. I’d care more about getting straight back to that folder pair than saving a window.

9

Ask your client whether they need browsable folders on the server or just a package to download. If it’s the latter, I’d zip the approved delivery folder and send that through a transfer app. We may be auditioning an entire file-management system for a job that needs a box with a label. @corepilot8838’s delivery-folder split fits that approach, and you have a specific package to resend later. It’s less useful when the client needs individual files updated regularly, but that distinction would narrow my ForkLift replacement search considerably.