Syncthing

Continuous peer-to-peer file synchronization

File Sync & Storage ★ 88.9k stars Easy setup MPL-2.0

Syncthing is a continuous file synchronization program that syncs files between two or more devices directly, without a central server. It is ideal for individuals who want private, serverless sync across their own machines. It is distributed as a single binary and also runs well in Docker.

Syncthing setup guides & articles

Hands-on coverage of Syncthing from the blog.

Key features

  • Fully decentralized peer-to-peer sync
  • TLS-encrypted transfers
  • No cloud account required
  • Cross-platform with mobile apps

Quick deploy

A starting point for self-hosting Syncthing - check the official docs for the full set of options.

  • Image syncthing/syncthing:latest
  • Web port 8384
  • Persist /var/syncthing
Docker Compose
services:
  syncthing:
    image: syncthing/syncthing:latest
    ports:
      - "8384:8384"
      - "22000:22000/tcp"
      - "22000:22000/udp"
      - "21027:21027/udp"
    volumes:
      - ./syncthing:/var/syncthing
    restart: unless-stopped
docker run
docker run -d --name syncthing \
  -p 8384:8384 \
  -p 22000:22000/tcp \
  -p 22000:22000/udp \
  -p 21027:21027/udp \
  -v ./syncthing:/var/syncthing \
  --restart unless-stopped \
  syncthing/syncthing:latest

Watch out for

  • Never expose the port 8384 GUI to the internet - sync traffic uses 22000, not the GUI port

Pros & cons

Strengths

  • No central server needed
  • Very private by design
  • Lightweight and reliable

Trade-offs

  • No web file browsing
  • Not a sharing platform

Syncthing replaces

Last reviewed Aug 22, 2026 · 732 words

Syncthing keeps folders identical across your devices with no server, no account, and no company in the middle — machines talk directly to each other over TLS, and 87,000 GitHub stars say it does this extremely well. It is also the most commonly misunderstood tool in self-hosting: it is not Dropbox (no web interface to your files), and it is emphatically not a backup (it replicates your mistakes as faithfully as your files). Used for what it is — private, continuous replication — it is close to flawless.

Understand the model in 60 seconds

Every device generates an ID (a hash of its TLS certificate). You share folders between device IDs, each side accepts once, and from then on changes propagate within seconds over LAN or internet. Public discovery and relay servers help devices find each other and traverse NAT, but they only ever see encrypted traffic — file contents stay between your machines. No port forwarding is needed in the default setup, which is why Syncthing works from a coffee shop as well as your living room.

Pick a topology: hub-and-spoke beats mesh

Syncthing lets any device sync with any other, and a full mesh of five devices is 10 relationships to babysit. The pattern that stays manageable is hub-and-spoke: one always-on device — NAS, mini PC, the Raspberry Pi or mini PC you already run — shares every folder, and each laptop or phone syncs only with the hub. Devices that are never awake at the same time still stay current, because the hub carries changes between them. The hub is also where you point one-way flows: the phone's camera roll lands there as "send only" from the phone, then fans out read-only wherever you want it — which is the poor-man's photo pipeline until you graduate to Immich.

Versioning is the feature that saves you

Sync propagates deletions and overwrites instantly to every device — ransomware, a bad script, or a tired brain can vaporise a folder everywhere at once. Two defences, use both. First, enable file versioning on the hub (per folder, "Staggered" with 30–365 days is the sane default): when a change or delete arrives, the hub keeps the old copy in .stversions. That converts most disasters into a two-minute restore. Second, run a real backup of the hub with restic or borgbackup — versioning shares the disk with the data it protects, so it fails with the disk. The 3-2-1 rules explain why "it's synced to three machines" still counts as one copy.

The settings that separate smooth from mysterious

  • Ignore patterns before first sync: a .stignore with node_modules, build artefacts, and .DS_Store-type litter keeps sync fast and conflict-free. Adding ignores after the fact does not delete what already synced.
  • Send-only / receive-only where flow is one-way: camera uploads, music libraries, config distribution. It prevents an accidental edit on a spoke from writing back.
  • Watch for .sync-conflict files: edits to the same file on two offline devices produce conflict copies rather than data loss. Finding them months later means nobody was looking; a monthly search for sync-conflict is worthwhile hygiene.
  • Untrusted-device encryption exists for syncing through a box you don't fully trust (a friend's NAS as your off-site spoke) — it stores only encrypted blobs there.

Security: one port matters more than all others

Sync traffic (22000/tcp+udp) and local discovery (21027/udp) are safe by design. The web GUI on 8384 is the whole kingdom — anyone who reaches it controls what syncs where — and it must never be exposed to the internet. Leave it bound to localhost or the LAN, set a GUI password anyway, and reach it remotely over Tailscale if you need to. In Docker, that means mapping 22000 and 21027 but not publishing 8384 beyond 127.0.0.1.

What I'd do

Hub on the always-on box, hub-and-spoke to every other device, staggered versioning on the hub, .stignore written before the first big share, phone camera roll as send-only, restic backing up the hub nightly. Then notice, three months later, that you have not thought about file sync once — that silence is Syncthing's actual product, and no cloud subscription sells it.

Compare Syncthing

21 head-to-head comparisons.

Similar file sync & storage apps