You have a Mac for writing and design, a Linux laptop for coding, a NAS at home, and a remote VPS for production. The same dotfiles, the same notes, and the same in-progress repo need to be on at least three of those. The question is: do you put it in iCloud Drive, run Syncthing, or just rsync on a cron?
The answer depends entirely on what kind of files they are and which machines need to see them. Here are the three options, what they’re good at, and where I’ve watched them fail.
iCloud Drive — for the documents you’d lose sleep over
iCloud Drive is the most reliable option for “files that look and feel like documents” — Markdown notes, PDFs, photos, the contents of your ~/Documents folder. It Just Works between Macs, iPhones, iPads, and (with the iCloud client installed) Windows. End-to-end encryption is real on the iCloud side. The 50 GB plan is $0.99/month and the 200 GB is $2.99/month, which is cheap.
Where it falls over for dev work:
- It mangles dotfiles. Files starting with a dot are hidden in Finder, but worse, iCloud’s “Optimize Mac Storage” feature can evict them and replace them with a placeholder. The next time your shell tries to
source ~/.zshrc, the file isn’t actually there yet — there’s a download stub. - It does not handle
.gitdirectories well. Putting a repo in iCloud Drive is the recipe for git complaining about phantom changes, file locks, and refs that disappear mid-rebase. Don’t do it. - No Linux client. If your other machine is a Linux laptop or a remote VPS, iCloud Drive can’t help you.
- Selective sync is per-folder, not per-file. If you want a 10 GB design archive on your iMac but not your MacBook Air’s smaller SSD, you’ll have to live with the “Optimize Storage” eviction logic, which is opaque.
Use iCloud for: Markdown notes, Obsidian / Bear / Apple Notes data, design assets, PDFs, photos. Things you’d want to read on your phone.
Syncthing — for the files that need real-time mesh sync
Syncthing is open-source, peer-to-peer (no central server), runs on Mac/Linux/Windows/Android, and handles encrypted sync between an arbitrary number of devices. You install it on each box, generate a device ID, share the ID, share a folder. It just sits there in the background and keeps the folders identical.
brew install syncthing # macOS
sudo apt install syncthing # Debian / Ubuntu
syncthing --no-browser # then visit http://localhost:8384What it’s actually good at:
- Cross-platform. Mac, Linux, Windows, Android — same protocol, same UI.
- Zero cloud cost. No subscription, no ten-thousand-files-per-folder limits, no rate limiting. Your bandwidth is your bandwidth.
- Per-folder versioning. Trash, simple, staggered, or external-script versioning per folder. Finally — a “yes I deleted that, please give it back” option that doesn’t require a separate backup tool.
- Conflict handling is sane. Two devices change the same file → both versions are kept with a
sync-conflict-DATE-TIME-DEVICEIDsuffix. You merge by hand. Annoying but correct.
The pitfalls nobody talks about:
- Relay-only mode is slow. If neither end has a routable IP and the other side is behind aggressive NAT, Syncthing falls back to volunteer-run relay servers. They’re free and work, but throughput drops to a few hundred KB/s. For a 50 GB initial sync that’s painful. Set up introducer / NAT traversal correctly or run on a Tailscale tailnet to get direct LAN-speed transfers.
- Trust model is per-device. Adding your kid’s iPad means your kid’s iPad now has read/write access to everything you share with it. There’s no per-folder ACL beyond “send-only / receive-only / send-and-receive.”
- Mobile sync is a battery drain. The Android app works but keeping a phone in active sync drops battery life noticeably. iOS doesn’t have a native client at all (the protocol’s design conflicts with iOS background-app limits).
Use Syncthing for: Your dotfiles, your ~/projects directory (NOT inside .git), your password vault file, anything where you want every device to have an identical copy without going through someone else’s cloud.
rsync — for the things you don’t actually need on every machine
rsync isn’t really a “sync” tool in the modern sense — it’s a copy tool with a smart delta algorithm. You run it on a schedule (cron, or systemd timer if you read last week’s post), it pushes (or pulls) the diff to a remote target, and that’s it.
# Hourly snapshot of ~/projects to a NAS
rsync -avz --delete \
--exclude '.git' --exclude 'node_modules' --exclude 'target/' \
~/projects/ nas:/volume1/backups/projects/Why this is sometimes the right answer:
- It’s one direction. Mac → NAS, or VPS → backup-bucket. Both endpoints don’t need to know about each other; you don’t need running daemons; the work is bounded in time and bandwidth.
- It composes with everything. SSH, cron, restic, rclone, BorgBackup, Time Machine over SMB. rsync is what’s underneath most of the things people use.
- You control the diff cost.
--exclude,--max-size,--bwlimit, hard-link snapshots — there’s almost nothing you can’t tune.
Where it’s the wrong tool: bidirectional sync. The moment you want both ends to be writable and conflict-resolved, rsync is not the right shape. People build elaborate two-way wrappers around it (unison, bsync, scripts on top); they all eventually break. Use Syncthing instead.
Use rsync for: One-way snapshots, archive transfers, “everything in ~/Pictures to the NAS overnight,” “production logs to a backup VPS.” Anything where one side is the source of truth and the other is a copy.
What I actually use
- iCloud Drive for Markdown notes, paper PDFs, scanned documents, design files. Stuff I want on my phone.
- Syncthing for
~/.dotfiles, an “active projects” directory I bounce between two laptops, and a shared password vault. - rsync via a hourly systemd timer for archived projects + photo originals from the working SSD to the home NAS, then restic from the NAS to a B2 bucket once a day.
The mistake I made for years was trying to make one of them do the job of the other two. iCloud is great until you put a git repo in it. Syncthing is great until you ask it to do hourly archival snapshots. rsync is great until you forget that “two-way” is not what it does. Pick the right one per use case and the friction disappears.
Photo: MacBook with cloud-themed login screen by Zion on Pexels.