Syncthing keeps a folder identical across several machines. Change a file on your laptop and it appears on your desktop and your server, usually within seconds. There is no account, no subscription, and no company holding a copy — the devices talk to each other directly.
Is it worth your time? If you have two or more machines you use regularly and want the same files on all of them without a third party, it is excellent, and it has been stable and boring for years — which is the highest praise for software that touches your files.
The real no case: it is not a backup and it must not be treated as one. Sync propagates deletions, and a file you delete by mistake is deleted everywhere within seconds. It also needs the devices to be online at overlapping times — two laptops that are never on together will not sync unless something always-on sits between them. And it will not share files with people who do not run Syncthing.
Installing
sudo apt install syncthing # Debian, Ubuntu
sudo dnf install syncthing # Fedora
sudo pacman -S syncthing # Arch
# run it as your own user, not root
systemctl --user enable --now syncthing.serviceRun it as the user whose files it syncs. The --user service means it starts with your session and every file it writes is owned by you. Running it as root produces files you then have to chown, and there is no benefit.
On a headless server the user service will not start until you log in, unless you enable lingering:
sudo loginctl enable-linger $USERDistribution packages are frequently behind. Syncthing releases on the first Tuesday of each month, and the version in a stable distribution can be a long way back — worth using the project’s own repository, or the release binary, on a machine you rely on.
The Android situation
This is the part that catches out anyone following a tutorial written before 2025. The official Syncthing Android app was retired. The maintainer announced it in October 2024, the last release was the December 2024 version, and the repository was archived on 3 December 2024. The reasons given were the difficulty of publishing on Google Play combined with no active maintenance. It is no longer on the Play Store.
What to use instead is Syncthing-Fork, which is now listed in Syncthing’s own documentation under community contributions and is actively maintained — its releases track upstream Syncthing versions closely. It is available on Google Play, on F-Droid, and from its GitHub releases page.
Two things follow from this. If you have an Android device still running the old official app, it is unmaintained and receiving no upstream fixes — move to the fork. And when reading any Syncthing guide, check its date: anything recommending “the official Android app” predates October 2024 and may be stale in other ways too.
Setting it up
The web interface runs on http://127.0.0.1:8384. Everything is done there.
Each device has a long device ID, which is a fingerprint of its TLS certificate. You add a device by pasting its ID, and the other machine gets a prompt to accept. That mutual confirmation is the entire authentication model — there is nothing else to configure, and no password shared between machines.
- On each machine: Actions → Show ID
- On machine A: Add Remote Device, paste B’s ID
- On machine B: accept the prompt that appears
- Add a folder on A, tick B under Sharing
- On B: accept the folder, and choose its path deliberately — the default is rarely where you want it
Set a username and password on the GUI under Settings → GUI even on a personal machine, and if you need to reach it from elsewhere, use SSH port forwarding rather than binding the interface to 0.0.0.0:
ssh -L 8384:127.0.0.1:8384 user@server # then open localhost:8384The 20% you will use
Folder types are the setting most worth understanding, because they are per-device:
| Type | Behaviour | Use on |
|---|---|---|
| Send & Receive | Two-way — the normal case | Machines you work on |
| Send Only | Pushes changes, never accepts them | The authoritative source of a folder |
| Receive Only | Accepts changes, never pushes | A mirror, or a machine you do not trust to be right |
| Receive Encrypted | Holds the data without being able to read it | An off-site device — still beta, per the project |
File versioning is the setting that turns Syncthing from alarming into comfortable. Per folder, under Advanced → File Versioning, “Staggered” keeps old copies in .stversions with decreasing granularity over time. Turn it on before you sync anything you care about — it is what saves you when a deletion propagates.
Ignore patterns live in a .stignore file at the folder root, and matter more than people expect:
# .stignore
(?d).DS_Store
(?d)Thumbs.db
node_modules
.venv
*.tmp
.gitThe (?d) prefix means the file may be deleted when the directory is otherwise being removed. Excluding node_modules and similar is not just tidiness — thousands of small files are what makes scanning slow and conflicts likely.
Conflicts
When the same file is changed on two devices before they sync, Syncthing keeps both. One keeps its name; the other is renamed to something like notes.sync-conflict-20260901-084500-ABCDEFG.md, where the trailing characters identify the device the losing copy came from.
Nothing is lost, but nothing is merged either — Syncthing does not understand file contents. You resolve it by opening both and deciding.
find ~/Sync -name '*.sync-conflict-*'Run that occasionally. Conflict files accumulate silently, and finding a two-year-old one is a bad way to discover you have been editing the wrong copy.
How devices find each other
On a local network, devices announce themselves by broadcast and connect directly. Across the internet, two optional services help, and both are worth understanding because they are the parts that involve someone else’s machine.
Global discovery means each device periodically tells a discovery server “this device ID is currently at this address”. That is all the server holds — a mapping, not your data.
Relays are for when neither device can accept an incoming connection, both being behind NAT. A public relay forwards the traffic between them. The relay learns the device IDs involved, but the data passing through is encrypted end to end and it cannot read any of it. Relayed transfers are much slower than direct ones, so a persistent “Syncing” that never finishes quickly is often a sign that you are relaying — the connection type is shown in the GUI.
Both can be turned off entirely under Settings → Connections, which is the right choice if all your devices are on a network you control — or on a VPN you have already set up.
Gotchas
| Symptom | Cause | Fix |
|---|---|---|
| Deleted a file, it vanished everywhere | Working as designed | Enable file versioning; keep real backups |
| Stuck at 99%, never completes | A file changing while being synced, or an ignored file on one side only | Check the folder’s error list; align .stignore |
| Very slow transfer between two machines | Going via a relay | Check connection type; open a port or use a VPN |
| Constant conflict files | An application rewriting files continuously | Ignore its working files; do not sync live databases |
| High CPU on a large folder | Rescanning | Longer rescan interval; enable filesystem watching |
| Permissions wrong on synced files | Running as root, or differing umasks | Run as your user; consider ignoring permissions on the folder |
| First start after upgrading to v2 took a long time | Database migrated from LevelDB to SQLite | Expected once; let it finish |
| Android app no longer updating | Official app retired in 2024 | Move to Syncthing-Fork |
Where it does not belong
- As your backup. Sync replicates mistakes. Use restic or something like it alongside, not instead.
- Live databases and virtual machine disks. Files being written continuously will sync in an inconsistent state. Sync the dump, not the data directory.
- Sharing with other people. Everyone needs Syncthing and a device on the folder. For sending a file to someone, this is the wrong tool.
- One-way archival to a server. That is rsync, run on a schedule.
- Huge media libraries between rarely-overlapping devices. It works, but a scheduled pull is simpler and predictable.
Quick reference
systemctl --user status syncthing # is it running
sudo loginctl enable-linger $USER # keep it running on a headless box
ssh -L 8384:127.0.0.1:8384 user@server # reach the GUI safely
find ~/Sync -name '*.sync-conflict-*' # find conflicts
syncthing --device-id # this machine's ID, from the shell
journalctl --user -u syncthing -f # logsFiles live under ~/.local/state/syncthing or ~/.config/syncthing depending on version; the GUI’s Actions menu tells you which.
Related reading
- restic — the backup Syncthing is not
- rsync — one-way copying, on demand
- A home file and media server — the always-on machine that makes sync reliable
- A WireGuard VPN — direct connections without relays
- Tailscale — the other way to get your devices talking directly