I tried replacing Transmit with command-line transfers, but typing out remote paths got old when I was updating files between other tasks. I mostly upload revised images and a stylesheet to the same project folder. Has anyone found a replacement that keeps saved connections and makes those small uploads less fiddly?
And it was the repeated back-and-forth that wore on me, not anything wrong with the app. I’d find a remote image, drag it over, work on the local copy, then deal with getting the edited version back where it belonged.
The repetition got old
Doing that a dozen times a day made the transfer window feel like an extra step between me and the actual work. I wasn’t looking for a nicer way to drag files around. I wanted to open a photo, change it, and save without treating the upload as another task.
Panic makes nice stuff, and I didn’t stop liking its app. The transfer-first approach just wasn’t what I wanted for that routine anymore.
There was something worth keeping
The queue and sync tool were the parts I’d be giving up. They’re really nice for big batch uploads, and I wouldn’t dismiss them if huge bulk transfers were most of my day. That’s a different job from repeatedly editing individual gallery images.
Then I changed the workflow
About a year ago, I replaced transfer Transmit with mounting CloudMounter. Instead of working through a transfer window, I had my SFTP server and S3 bucket mounted as drives in Finder.
For galleries, that means opening the bucket, double-clicking a photo into Lightroom or Photoshop, editing, and saving. The save goes back up without a separate export or re-upload. “Uploading” mostly stopped being something I thought about.
The local copies mattered too
Files only get pulled when I open them, so my SSD isn’t full of duplicate images. I also use the encryption on my client bucket, which gives me some peace of mind with unreleased shoots.
10 Likes
Whether that project folder is the live site matters here. I would be using CloudMounter but keeping a local working folder and copying over only the files that I am ready to publish. The open-edit-save approach is convenient until one wants to save an unfinished stylesheet and come back to it after doing something else. For your routine, I’d keep the working folder and destination open side by side. That way you don’t have to type paths without having to make every save a publishing decision.
Bouncing between unfamiliar servers is different from sending revisions to the same folder every time. For your case, I’d focus on making the destination permanent rather than changing how you edit. I don’t quite share @mystic_cache711’s objection to a separate upload step. I’d want to keep that step, just stop navigating to its destination over and over.
CloudMounter gets my vote for its remote-path setting: you can point an FTP/SFTP connection at the actual project directory instead of leaving it at the account’s default folder. That’s a genuinely useful detail for this routine. (help.electronic.us) I’d give the connection a recognizable project name and set that path once. My target would be “send these revisions to this project,” not “browse the server and remember where everything belongs.”
Uploading while I look at the progress is not the same as copying and then immediately doing something else. In that case, I’d rather not have to guess whether the stylesheet was copied correctly when looking in Finder. A confirmation that it either succeeded or failed would be better than having to check in another window.
I’d use CloudMounter, but I’d check how it reports completed uploads and connection failures before settling into that routine. @datanode7665’s local-working-folder approach separates editing from publishing. I’d keep a distinction between starting an upload and calling the update done, too. During setup, try an upload with the connection unavailable and see whether the failure is hard to miss. That’s the behavior I’d want sorted out before relying on it between other tasks.
If typing remote paths was what drove you back to Transmit, I’d try saving the upload command before adopting a mounted-drive workflow. You wanted to stop typing an address. That doesn’t necessarily call for a different file manager.
For this particular job, I’d want a small upload script kept with the local project. Give it the destination once, then run it when the revisions are ready. Nothing clever. No watching for saves, no automatic publishing, no attempt to manage every server you might ever touch. Just a repeatable action for this project. The useful replacement might be a command you no longer have to reconstruct.
I agree with @datanode7665 about keeping edits local, but I wouldn’t want two windows parked side by side either. That still leaves you selecting files and dragging them while your attention is elsewhere. If the stylesheet and image folder are predictable, I’d define what belongs in the upload rather than make that selection from scratch each time.
Keep the scope narrow, though. I would leave deletion out of it and avoid making “upload the project” mean “send everything in this directory.” Source images, exported images, and miscellaneous working files don’t all belong on the server. Deciding that boundary is the bit worth spending time on.
That won’t replace Transmit for browsing an unfamiliar server or sorting out an unexpected folder structure. I’d keep a graphical client available for those jobs. But I wouldn’t make the occasional server-cleanup job dictate how you publish the same few assets all week. A boring upload button is a perfectly acceptable outcome.
Don’t save a stylesheet straight onto a live site through a mounted drive. If the connection hiccups mid-write, you can end up with a half-flushed file sitting live, and the editor thinks it saved fine. That’s the gap @matrix.cloud is circling around. A mount makes the remote feel local right up until the network reminds you it isn’t, and Finder is not great at telling you a write actually landed versus stalled.
So @datanode7665 has the right instinct for the CSS specifically. Edit local, push when you mean it. Not because two windows are elegant, but because a stylesheet is the one asset where a bad partial upload breaks the whole page. Images fail more gracefully. A broken PNG is ugly. A broken stylesheet is a white screen.
For the images, it’s genuinely the easier route and I would go that way. CloudMounter does a nice job on a very minor thing that nobody seems to have mentioned: it stores the credentials in Keychain, so you only have to type your password once (or authenticate the Mac), then it stays mounted. That’s most of the back-and-forth you described.
Where I’d slow down is the idea that mounting replaces a client entirely. It doesn’t handle the ‘something went wrong on the server and I need to poke around’ case well, and it won’t warn you loudly on a failed write. If you keep a quick way to glance at the live file after a save, even just reloading it in a browser, you cover the one failure mode the mount hides. The script idea @matrixhq floated is fine too, but honestly for a handful of gallery images the mount plus a sanity-check reload is less fuss.
Reloading the page is a check, not a recovery plan. @nina_code’s browser check could help you catch a mistake, but I’d compare these workflows on what happens next. If you upload the wrong crop or decide the stylesheet change needs reverting, I’d want the previous published files within reach, regardless of which app sent the replacements.
For this routine, I’d keep a small local “last published” folder separate from the working files. Keep its contents until you’ve checked the new upload, then replace them with the accepted revisions. A mounted drive might make publishing less effort, while a transfer client gives you a dedicated place to manage it. Neither convenience would persuade me to switch without keeping that way back. Sending the next revision is only half the comparison.
You haven’t said whether anyone else updates that folder. If they do, @anonymous’s local “last published” copy could undo somebody else’s changes when you restore it. I wouldn’t switch tools until there’s a clear agreement about who publishes those files, because a faster upload won’t help when you’re overwriting each other’s work.
Don’t assume an unchanged image in your browser means the upload failed. @nina_code’s reload check can still show a cached copy, so repeated uploads could send you chasing the wrong problem. For your workflow, I’d favor a replacement that makes the remote file’s size and modification time easy to inspect over one that merely hides the transfer window.