Syncthing for Dotfiles: Sync vs Manage | SumGuy's Ramblings<br>Skip to content

Go back<br>Syncthing for Dotfiles: Sync vs Manage<br>13 Jul, 2026<br>By SumGuy<br>11 min read |

Contents

On this page

The Reader Question That Started This

A while back I wrote about running Syncthing over untrusted VPS relays, and someone in the comments asked the entirely fair question: “Why not just use chezmoi for this?” Great question. Different tool, different job — but it’s worth actually answering instead of hand-waving it away, because the honest answer is “it depends on what problem you think you’re solving,” and most people don’t realize there are two different problems hiding under the word “dotfiles.”

So let’s settle it properly. Should you use Syncthing to sync your dotfiles? Sometimes yes. Often no. Almost always in combination with something else. Let’s get into why.

What Syncthing Actually Does (and Doesn’t)

Here’s the thing people miss: Syncthing has no idea what a dotfile is. It doesn’t know .bashrc is more important than a screenshot from three years ago. It’s a P2P, block-level, continuous file synchronization engine — full stop. You point it at a folder on Machine A, pair it with Machine B, and from that point on, whatever bytes exist in that folder on one device get replicated to the other, in near-real-time, over an encrypted transport. No commits. No apply step. No “did I remember to push?” ritual. You save the file, and a few seconds later it exists elsewhere too.

That’s genuinely magical for a lot of use cases. It is not, on its own, a dotfile management strategy — it’s a mirror. And mirrors reflect everything, including the ugly stuff.

Compare that to chezmoi, which treats your home directory as a build target. Your actual dotfiles live in a source-of-truth directory (usually ~/.local/share/chezmoi, backed by a git repo), and what ends up in ~/.bashrc is the rendered output of running templates against that source, with an explicit step to make it happen:

Terminal windowchezmoi init --apply [email protected]:yourname/dotfiles.git

One command. Pulls the repo, renders every .tmpl file for this specific machine, and writes the result into your home directory. That “render for this specific machine” part is the whole ballgame, and it’s where Syncthing structurally can’t compete — more on that in a second.

If you want the full manager-vs-manager breakdown — chezmoi vs GNU Stow vs a bare git repo — I already did that fight in a separate post. This one’s not about which manager wins. It’s about whether you should be using a manager at all, or just letting a sync daemon handle it.

The Case Against Syncthing as a Dotfile Tool

It propagates your mistakes just as fast as your good changes

This is the one that should scare you a little. Syncthing doesn’t have opinions about whether a change is good. You save a half-edited .vimrc with a dangling bracket, or you rm your .ssh/config by accident while cleaning up — Syncthing sees a changed file and does exactly what it’s designed to do: replicate it. Within seconds, your broken config (or your missing config) is now broken or missing on every other device sharing that folder too. There’s no “wait, are you sure?” There’s no review step. That’s not a bug, that’s the entire value proposition of a sync engine — continuous, unattended replication. It’s just a value proposition that cuts both ways.

Syncthing does have a safety net: file versioning. When you enable it on a shared folder, replaced or deleted files get moved into a hidden .stversions directory instead of being silently gone forever. You’ve got four strategies to choose from:

Trash Can — keeps the previous version indefinitely (or until you clean it up manually)

Simple — keeps the last N versions, first-in-first-out

Staggered — keeps more recent versions densely and older ones sparsely, auto-expiring by age

External — hands off to a script of your choosing when a file’s about to be replaced

Turn on Staggered for your synced folder and a busted .vimrc becomes recoverable — you can dig the last-good copy out of .stversions by hand. But notice what that is: a recycle bin, not source control. There’s no commit message, no diff, no branch, no “why did I change this on March 3rd.” Compare that to a dotfile manager backed by git, where git log -p -- .vimrc tells you exactly what changed and when, and git revert undoes it cleanly across every machine the next time you pull. .stversions is “I panicked and need last week’s file back.” Git history is “I can reconstruct the reasoning.” Those are not the same safety net.

No such thing as “this file, but different per machine”

Here’s the structural problem, and it’s the biggest one: your work laptop and your personal desktop are not the same computer. Work wants a different git user.email. Your desktop has a different $PATH because you installed Homebrew in a different spot, or you’re not running the corporate VPN client wrapper in your shell profile. Your ultrawide...