August 22, 2026

Syncthing: P2P Sync That Is Not a Backup

Synchronizing files between devices peer-to-peer with in-transit encryption, no cloud and no account — plus its honest limits: syncing is not a backup, and data at rest on devices is not encrypted.

The most basic homelab need is often a single answer: how to get the same files on many devices without routing them through somebody else’s cloud? Syncthing answers it: synchronization runs directly between devices, called peers, with no third-party intermediary storage. Understood from the start: this is a sync tool, not a backup.

Why Syncthing

Syncthing keeps files identical across several connected devices. It keeps my notes and a few other directories that travel with me; changes propagate while the devices are alive and connected. No fees, no quotas, no third party reading your files.

How it works: the peer-to-peer model

The most fundamental difference from cloud storage is the model. Every device runs its own copy of Syncthing, and these instances connect directly to each other to form a mesh network, which is why they are called peers.

Device identity is guaranteed by digital certificates; the device ID shown is the SHA-256 fingerprint of that certificate, and all traffic is protected by TLS 1.2/1.3. Two devices connect only when both sides approve each other’s device ID.

Transfers are block-based: only changed parts are sent. When direct connection fails, Syncthing falls back to a public relay — data stays encrypted, but the relay learns the device IDs.

Deployment with Docker Compose

services:
  syncthing:
    image: lscr.io/linuxserver/syncthing:latest
    container_name: syncthing
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Jakarta
    volumes:
      - ./config:/config
      - ./sync:/sync
    ports:
      - "8384:8384"        # Web UI
      - "22000:22000/tcp"  # Sync traffic
      - "22000:22000/udp"
      - "21027:21027/udp"  # Local discovery
    restart: unless-stopped

Save it as docker-compose.yml, then run:

docker compose up -d

The config directory holds configuration and device identity; sync is the sync-folder root. Port 8384 serves the web UI, 22000 carries sync traffic, and 21027 handles local discovery.

Initial setup

Open the web UI at http://<host-address>:8384 and set up a user account first — never leave it unauthenticated.

Next steps:

  1. Add a remote device from the Add Remote Device menu using its device ID.
  2. Create a folder to sync and share it with the target device.
  3. Approve the share on the target device to link the folder.
  4. Watch the two sides handshake and the status turn green.

Security and Operations

  • Protect the web UI with a strong password, or hide it behind an encrypted connection.
  • Do not expose these ports to the open internet without protection.
  • Guard the TLS keys and the config directory — anyone holding them can impersonate the device.
  • Update the image regularly for security fixes.

Folder types restrict sync direction: Send & Receive (default), Send Only for reference copies, Receive Only for replication — local changes stay local.

Backup & Recovery: why sync is not backup

Syncing is not backup. If a file is deleted or overwritten, that change propagates everywhere. Without file versioning, the good copy can vanish at once.

File versioning archives old versions into .stversions, using trash can, simple, staggered, or external strategies. Notes: off by default, and it only archives changes received from other devices — local deletions or overwrites are not archived.

All configuration lives in config, so moving to a new host means restarting the container with the same directory. When restoring from backup, stop syncing first — restoring into an active directory can trigger deletions or overwrites.

Cons and limitations

  • No encryption at rest. Only in transit; anyone with disk or key access can read the contents.
  • Versioning does not cover every case. Off by default, and local changes are not archived; without a strategy, no old copy exists.
  • Devices must be online. There is no central server; changes only spread when the receiving device is connected.
  • Metadata leaks to discovery and relays. Global discovery maps device IDs to IP addresses, and public relays learn the device IDs involved, even though the payload stays encrypted.
  • Conflict copies propagate. Files named <name>.sync-conflict-... are treated as regular files and get synced too.
  • Case-sensitive names. file.txt and FILE.txt can conflict on case-insensitive systems like Windows and macOS.

Troubleshooting

  • Devices cannot find each other — ensure ports 22000 and 21027 are open and not firewall-blocked.
  • Container not starting — check the logs with docker compose logs syncthing for errors.

Conclusion

Syncthing solves one problem well: files available on many devices with no cloud and no account. For a single-machine homelab with limited storage, it is light and easy to maintain from the web UI.

But it is not a backup replacement: all devices share the same failure domain. Pair it with a real, separate backup, and enable file versioning on important folders.

References

Back to all posts