How to Sync Configuration Files on Linux with Syncthing

If you’ve ever spent an hour lovingly tuning your .bashrc, only to SSH into another Linux box and realize you’re back to
the default prompt like it’s 2007, you already understand the pain: your configuration files are your muscle memory.
They should follow you around like a loyal shell aliasnot vanish the moment you switch machines.

Syncthing is a great fit for syncing Linux configuration files (“dotfiles”) because it’s peer-to-peer, encrypted, and doesn’t force you
into a cloud account you’ll forget the password for. But syncing config files is not the same as syncing vacation photos:
config files can include secrets, app state, machine-specific paths, and permission-sensitive bits. So we’ll do this the “future you won’t hate you” way.

Why Syncthing Is a Good Dotfiles Sidekick

Syncthing continuously syncs folders between devices you explicitly approve. Under the hood, it uses encrypted connections, and even if traffic goes through a relay,
the relay can’t read your data. That means you get “Dropbox vibes” without the Dropbox part.

It’s also great for config syncing because you can:

• Sync only the files you choose (instead of your entire home directory chaos).
• Use versioning to keep old copies when you inevitably break something at 1:00 a.m.
• Choose folder behaviors (send/receive, send-only, receive-only) depending on how “authoritative” each machine should be.
• Ignore noisy or dangerous files (cache, sockets, secrets) with predictable patterns.

Step 0: Pick a Strategy (So Conflicts Don’t Pick One for You)

Before you create your first shared folder, decide which of these personalities you are:

• “One Source of Truth”: You mainly edit dotfiles on one machine (your “control tower”) and other machines should follow.
  This is great for avoiding conflicts.
• “I Edit Everywhere”: You want to tweak configs on any device, anytime. This can work, but you’ll need some guardrails
  (versioning, slower changes, and a healthy respect for conflict files).
• “Sync + Git”: Syncthing moves files fast; Git tracks history and helps merge changes. This combo is ridiculously effective for text configs.

For most people, the sweet spot is: use Syncthing to sync a dedicated dotfiles folder, then
symlink those files into place. That keeps the synced folder clean and predictable, and it avoids syncing random app state by accident.

Step 1: Create a Dedicated Dotfiles Folder

Create a folder whose only job is: “hold the configs I actually want to sync.”

A tidy layout could look like this:

The goal is portability: keep machine-specific stuff out of the shared files when possible, or isolate it with conditional includes.

Step 2: Add the Folder to Syncthing and Share It

1. Open the Syncthing Web UI on your first Linux device.
2. Add a folder pointing to ~/Sync/dotfiles.
3. Share it only with devices you trust (because you’re syncing your brain).
4. On other devices, accept the share and choose the same path (or a consistent path you’ll remember).

Choose the Right Folder Type

Folder type is where you can prevent a lot of headaches:

• Send & Receive: changes flow both ways (convenient, also conflict-prone if you edit the same file on two machines).
• Send Only: this device is authoritative; local changes should be pushed out, not overwritten.
• Receive Only: this device should mirror the cluster; local edits won’t be sent out (great for “don’t touch my configs” servers).

If you want a “control tower” machine, set that machine’s folder to Send Only and set the others to Receive Only.
You can still edit configs elsewhere, but you’ll need to consciously “override” or copy changes backmeaning you won’t accidentally
change your production shell prompt while half-awake.

Step 3: Start Syncthing Reliably (systemd Without Tears)

On most modern Linux distros, running Syncthing as a user service is the cleanest approach for dotfiles because
it runs with your user permissions (no root shenanigans required).

Headless servers: keep it running after logout

If this is a server and you don’t want Syncthing to stop when you log out, you may need to enable “lingering” for your user:

That tells systemd to keep your user services running even without an active login session. (Yes, it sounds like a ghost story.
No, it won’t haunt youunless you forget you enabled it.)

Security note: protect the GUI

Treat the Syncthing GUI like a house key. Make sure it’s bound to a safe interface (often localhost by default),
and set GUI authentication. If you use the API, keep the API key safe and don’t casually paste it into public gists
titled “Totally Not A Secret Key.”

Step 4: Link Synced Files Into Place

Once ~/Sync/dotfiles is syncing correctly, you’ll “install” your dotfiles by symlinking them into your home directory.
The synced folder becomes the source; your home directory becomes the consumer.

Example: Bash and Git

Example: XDG config files (~/.config)

Many apps store configs under ~/.config. You can link individual app folders:

What about symlinks inside Syncthing folders?

Syncthing can sync symlinks as symlinks, but it generally does not follow them to sync the target directory.
That’s a security feature: you don’t want a “harmless” link to trick a sync tool into pulling in sensitive paths outside the shared folder.
If you need to mirror content scattered around the filesystem, consider:

• Bind mounts for directories (a clean “make this appear here” trick)
• Hardlinks for files on the same filesystem (where appropriate)
• Or… simply sync multiple folders and keep life simple

Step 5: Use Ignore Patterns to Avoid Syncing Junk (and Secrets)

Syncthing uses ignore patterns through a file named .stignore placed at the root of a synced folder.
This is perfect for dotfiles because you can aggressively exclude:

• Cache directories and history files that differ per machine
• Lock files and sockets
• Machine-local state (like session files)
• Anything containing secrets you should never sync

Important quirk: .stignore is local

By design, .stignore itself is not synced to other devices. So you have two options:

• Option A: Maintain ignore rules on each device (simple, but repetitive).
• Option B: Keep a synced ignore file (like stignore.shared) and have each device’s .stignore include it.

Here’s a practical pattern for Option B:

And here’s a starter stignore.shared you can customize:

Pro tip: if you’re unsure whether something contains secrets, assume it does until proven innocent.
Your future self will thank you. Your future attacker will not.

Step 6: Permissions and Ownership (Because Linux Cares, A Lot)

Config files sometimes rely on strict permissions (especially SSH configs and keys). A few practical rules:

• Run Syncthing as the same user who owns the config files.
• If syncing across different OSes or filesystems, consider enabling Ignore Permissions to reduce weird permission flips.
• For Linux-to-Linux syncing, keep permissions consistentbut beware mismatched user IDs on different machines.

If you ever think “I should sync /etc,” pause and sip water. You can do it, but it’s high-risk:
root ownership, distro differences, and one typo away from turning your login screen into modern art.
If you must sync system config, do it deliberately: a separate folder, a clear allowlist, and preferably a staging process.

Step 7: Turn On Versioning (A.K.A. Undo for Your Bad Ideas)

Syncthing supports file versioning per folder, per device. For dotfiles, versioning is fantastic because config mistakes are common and
your memory is… let’s say “optimized for fun facts, not safe rollbacks.”

Good versioning choices for dotfiles:

• Staggered: keeps more recent versions densely, older versions more sparsely (nice balance).
• Simple: keep the last N versions (easy mental model).

Even if you also use Git, Syncthing versioning is a great “seatbelt” for accidental overwrites and surprise conflicts.

Step 8: Avoid and Resolve Conflicts Without Panic Googling

Syncthing creates conflict copies when it detects concurrent changes to the same file on different devices.
Two important facts:

• Conflicts are about concurrency, not “Syncthing replaying old states.”
• Syncthing’s decisions aren’t based purely on timestampsso “but the file is newer!” isn’t always the winning argument.

How to reduce conflicts

• Edit your configs on one device at a time and let sync settle before editing elsewhere.
• Use Send Only / Receive Only if you want a clear authority.
• If you love living dangerously, pair dotfiles with Git and commit changes often.

What to do when a conflict file appears

1. Open the original file and the conflict copy side-by-side.
2. Merge the changes manually (for text configs, this is usually straightforward).
3. Save the final merged version in the “real” file.
4. Delete the conflict copy once you’re sure you’ve merged what you need.

The nice part: conflict copies behave like normal files and are synced too, so you usually resolve the conflict once and it propagates.

Advanced: Syncthing + Git (The “Professional Paranoia” Combo)

Syncthing is excellent at moving files quickly and securely between devices. Git is excellent at:

• Tracking history
• Reviewing diffs
• Merging changes cleanly
• Rolling back when you break your terminal prompt into hieroglyphics

A common workflow:

• Keep ~/Sync/dotfiles as a Git repo.
• Syncthing syncs it between devices.
• You commit changes whenever something meaningful changes.

If you’re feeling extra fancy, you can add a lightweight “reminder” script that nudges you to commit when files change,
but keep automation gentlenobody wants a repo with 900 commits titled “oops.”

Troubleshooting Cheatsheet

“My devices won’t connect”

• Make sure both devices are online and time isn’t wildly broken.
• Check firewall rules (Syncthing needs inbound/outbound connectivity for discovery and syncing).
• If direct connections fail, relays may helpand your data remains encrypted.

“Permissions keep changing”

• Ensure Syncthing runs as the same user who owns the files.
• Consider “Ignore Permissions” if cross-platform or if perms are unstable across filesystems.
• Don’t sync private keys; sync key configs, not the keys themselves.

“I synced too much and regret everything”

• Create a smaller, dedicated dotfiles folder and migrate only what you truly need.
• Use ignore patterns aggressively.
• Turn on versioning before you do big refactors.

Conclusion

Syncing configuration files with Syncthing is one of those quality-of-life upgrades that feels smalluntil you use a new machine and everything
“just works.” The key is to keep it intentional: a dedicated dotfiles folder, symlinks into place, smart ignore rules, and versioning for safety.
From there, you can scale up to a multi-device setup without turning your configs into a conflict-file museum.

Experiences From the Real World (500-ish Words of “What Usually Happens”)

In practice, syncing dotfiles with Syncthing tends to follow a very predictable emotional arc: excitement, confidence, one tiny mistake, mild panic,
then a mature, responsible setup that somehow makes you feel like a Linux wizard. Here are a few common “field notes” that show up when people do this.

Experience #1: The Great Over-Sync
Many folks start by sharing their entire ~ directory because it feels efficient. It’s also a trap.
Suddenly you’re syncing cache folders, application state, and machine-specific files that were never meant to travel.
The fix is always the same: roll back, create a dedicated ~/Sync/dotfiles folder, and move only the config you actually value.
The moment you switch to an allowlist mindset (“sync only these”), everything becomes calmer.

Experience #2: The First Conflict File Is a Personality Test
The first time Syncthing generates a sync-conflict copy, people often assume something is “broken.”
It’s not broken; it’s being polite. It’s saying, “Two devices changed this at the same time, and I’m not going to guess which one you meant.”
The folks who thrive are the ones who adopt one of two habits: either they edit dotfiles on one “main” machine and let others follow,
or they pair the folder with Git so merging becomes a normal, boring workflow instead of a dramatic event.

Experience #3: Permissions Are the Silent Saboteur
Dotfiles feel like plain text until you hit SSH configs and anything security-related. People learn quickly that syncing
private keys is a bad plan, and syncing key settings is the right move.
Another common lesson: if Syncthing runs under a different user than the one who uses the configs, you’ll see strange permission
or ownership behavior. Running Syncthing as your normal user and keeping the synced folder inside your home directory solves
most of these issues instantly.

Experience #4: Servers Want Boundaries
On laptops and desktops, “send & receive” feels great. On servers, especially headless ones, people often realize they want stricter rules.
A popular pattern is “control tower” laptop/workstation set to Send Only, and servers set to Receive Only.
That way, a server won’t accidentally push changes back to your other machinesbecause nothing says “bad day” like a server-generated config tweak
quietly reshaping your whole setup.

Experience #5: The Setup Becomes a Ritual (In a Good Way)
Once the system is in place, onboarding a new Linux machine becomes almost ceremonial:
install Syncthing, add the device, share the dotfiles folder, wait for sync, run a small “link everything” script,
andboomyour prompt, editor, aliases, and tools feel familiar. People often end up keeping a tiny checklist:
“sync dotfiles, verify ignores, confirm versioning, link configs, test shell + editor.” It’s not glamorous, but it’s the kind of boring
that saves hours over the life of your machines.

The biggest takeaway from these experiences is simple: Syncthing is incredibly reliable, but dotfiles are surprisingly personal.
The best setup respects that personalityby syncing only what should be shared, keeping safety nets (versioning + Git), and choosing folder modes
that match how you actually work.