How to edit remote files on a Mac in your own editor
If you want to edit remote files on a Mac in the editor you already use, there are three broad approaches: mount the server as a drive, run an editor on the server over SSH, or have a tool download the file, open it locally and upload it again each time you save. The third is the one that keeps your own editor, its settings and its extensions while asking nothing of the server beyond SFTP. This post compares the approaches, then covers the habits that stop a quick edit on a live server turning into an outage.
Three ways to edit remote files from a Mac
Mount the server as a filesystem
An SSHFS-style mount makes a remote directory appear in Finder, so any app can open files there directly. It feels natural when it works. The costs are a kernel or file-provider extension to install and keep updated, and an editor that has no idea the "disk" is a network link: indexing a project, searching across files or a background save can turn into hundreds of round trips, and a dropped connection can leave the editor hanging on a file it can no longer reach.
Edit on the server
Running vim or nano over ssh needs nothing on your Mac and is always available. It's the right tool for a one-line change on a box you rarely touch. It's a poor fit for longer sessions, because you lose your own editor's configuration, and every keystroke crosses the network, which is painful on a slow link.
Download, edit locally, upload on save
The file is copied to your Mac, opened in your usual editor, and every save is pushed back over SFTP (or FTP, or S3). Editing is local and instant; only the save touches the network. You can do this by hand with scp or the sftp command's get and put, but the manual loop is where mistakes creep in: uploading the wrong copy, forgetting to upload at all, or overwriting a newer file with a stale one.
Editing remote files in Wharf
Wharf automates the third approach. In the remote pane, right-click a file and choose Edit in Default App. Wharf downloads it to a working folder inside its own storage, opens it in whichever app macOS uses for that file type, and starts watching it. Each time you save, the new version goes straight back to the server.
A few details make this dependable rather than fragile:
- Atomic saves are handled. Many editors save by writing a temporary file and renaming it over the original. Wharf watches the containing folder rather than the file, so it keeps noticing saves after the first one, and it waits a moment for the editor to finish before uploading.
- No-op saves are skipped. If the file's size and modification time haven't changed since the last upload, nothing is sent. Editors that touch a file on focus changes don't spam the server.
- You can see what is happening. While files are open for editing, a strip in the window shows "Editing" with the file name and a running count of saves uploaded, says "Uploading changes…" while one is in flight, and shows the error if an upload fails. Stop Editing ends it.
- The file keeps its name. The working copy has the same name and extension as the remote file, so your editor picks the right syntax highlighting and the window title is recognisable.
- Opening it twice is safe. Choosing Edit in Default App on a file already being edited brings the editor forward rather than downloading over your unsaved work.
- Every save is on record. Each upload appears in the activity log as an upload to that path, so you can see later exactly when a config file changed. The audit trail post covers that log in detail.
When you disconnect, Wharf stops watching and deletes the working copies. They're scratch files; the authoritative copy is the one on the server.
To use an editor other than the default for a file type, change it the usual macOS way: select a file of that type in Finder, choose Get Info, pick the app under Open with and click Change All.
Editing live files safely
Whatever tool you use, editing on a live server carries the same risks. These habits help.
Know that the last save wins
Edit-and-upload tools, Wharf included, upload your copy over the server's. There's no merge, and no check for whether someone else changed the file after you opened it. On a file that only you edit, that's exactly what you want. On a file that a colleague or a deploy script might also be changing, either coordinate, or download a fresh copy before editing.
Validate configuration before reloading
Uploading a config file doesn't apply it; the service still has to reload it. Most daemons can check a file before you do:
sudo nginx -t
sudo apachectl configtest
sudo sshd -tRun the check, then reload. A syntax error caught by nginx -t costs nothing; the same error found by a reload can take a site down.
Be careful with files that are read continuously
Over SFTP, an upload replaces the file's contents in place: the file is truncated, then written. A process that reads the file at that exact moment can see it half-written. For a config file that's read only at reload, this doesn't matter. For something a running program re-reads constantly, edit a copy, then move it into place with mv in a terminal, which is atomic on the same filesystem.
Mind permissions
SFTP runs as the user you logged in as, and it has no equivalent of sudo. If /etc/nginx/nginx.conf belongs to root, you can open it but the save will be refused. Rather than logging in as root, give your user write access to the specific directory through a group, or edit a copy in your home directory and install it with sudo. If Wharf's upload of a save is refused, the editing strip shows the server's error, so a permissions problem doesn't go unnoticed.
Keep a way back
Before editing something important, take a copy on the server: cp nginx.conf nginx.conf.bak. If the server's configuration lives in version control, edit it there and deploy instead; editing in place is for the cases where that isn't how the box is run.
When editing in place isn't the right tool
If you're changing many files across a project, a sync is usually better than opening files one by one: edit the local copy of the whole tree, review what changed, and send it in one go. The static site deployment guide walks through that workflow, and the sync overview shows the review step.
For a quick look rather than an edit, previewing is lighter still; see previewing remote files with Quick Look.
The OpenSSH sftp manual page documents the get and put commands if you want to script the manual version. Questions about setting up the connection itself are covered on the support page.