Syncthing: Continuous Peer-to-Peer File Synchronization

What Syncthing is

Syncthing is a continuous file synchronization program: it keeps folders in sync between two or more computers you control, directly, without a central cloud service holding a copy of your files. Change a file on your laptop and the change appears on your desktop, your home server or your phone a few seconds later, transferred over an encrypted, authenticated connection between the devices themselves.

The project has been developed since 2013, is written in Go and licensed under the Mozilla Public License 2.0. Its README frames the project around an ordered list of goals, most important first: Syncthing should be safe from data loss, secure against attackers, easy to use, automatic, universally available, and for individuals. That ordering explains a lot of its design decisions. Features that would risk corrupting data or weakening security lose to those two goals, and the tool is pitched primarily at empowering individual users rather than at being an enterprise file-sharing platform.

Who uses it? Developers keeping dotfiles, notes or project folders aligned across machines; homelab owners replicating data to a NAS; people who want Dropbox-style convenience without handing their files to a third party; and teams that need to push a reference copy of files out to many machines. It runs on Windows, macOS, Linux and other platforms, with community-built wrappers and packages for Android, desktop GUIs and NAS systems.

How it works

Every Syncthing installation is a device with a unique, cryptographically derived device ID. The security docs explain that all device-to-device traffic is protected by TLS, and the device ID is the SHA-256 hash of the device's certificate, displayed in a human-friendly encoding. To prevent uninvited devices from joining, each connection's certificate fingerprint is checked against a preset list of acceptable devices. Two devices only connect if each has been configured with the other's ID, which is why the getting-started guide notes that device IDs do not need to be kept secret: they are essentially part of the public key.

Shared directories are called folders. Syncthing splits every file into blocks whose size depends on the file size, from 128 KiB up to 16 MiB, and computes a SHA-256 hash for each block. To update a file it compares the block list of the local version with the block list of the desired version and fetches only the blocks that differ, either by copying a matching block that already exists locally or by requesting it from another device. Every block received is hashed and checked before it is written to a temporary copy of the file; a block with the wrong hash is discarded and fetched from elsewhere.

Change detection uses two mechanisms. A filesystem watcher picks up changes as they happen, accumulating them for 10 seconds by default (deleted files are delayed a further minute) before triggering a scan. Full periodic scans also run, once an hour by default, with the actual interval randomised between three quarters and five quarters of the setting so that folders are not all rescanned at once. The docs recommend keeping full scans on even with the watcher enabled, since some changes may be missed. Each device tracks its own local version of every file, the versions announced by connected devices, and a global version, usually the most recent, which every device works towards.

Finding peers is handled by discovery. On the local network, Syncthing broadcasts and multicasts announcements every 30 seconds. Across the internet, it announces its device ID and listening ports to global discovery servers every 30 minutes, and queries them to find devices not seen locally. When a direct connection cannot be made, for example when both devices are behind restrictive NAT, traffic can flow through public relays. Relays only pass along encrypted data and cannot inspect it. Both the discovery server (stdiscosrv) and the relay server (strelaysrv) are documented, and anyone can run their own and point Syncthing installations at it.

Key features

• Peer-to-peer sync with no central copy. Files move directly between your devices; there is no server that stores your data unless you choose to run one of your own devices as one.
• Mutual device authentication. TLS on every connection, with device IDs derived from certificate hashes and an explicit allow-list on each side.
• Block-level transfers. Only changed blocks are sent, and every block is verified against its SHA-256 hash before being used.
• Folder types. Send & Receive is the default. Send Only folders keep a reference copy and ignore changes from other devices, with an Override Changes button to push the local state back out. Receive Only folders apply changes from the cluster but never distribute local edits, which suits mirrors and backup destinations, and offer a Revert Local Changes button.
• File versioning. Per-folder, per-device strategies keep old copies when files are replaced or deleted by a remote change: a trash-can mode with optional clean-out after a number of days, simple versioning that keeps a fixed number of copies, and staggered versioning that thins out old versions over time. Versions are kept in a .stversions folder by default.
• Ignore patterns. A .stignore file in the root of a synced folder excludes files with glob-style patterns. The file itself is never synced, though it can include other files that are.
• Untrusted (encrypted) devices. A folder can be shared with a password so that a device such as a cloud server stores only encrypted data, while trusted devices with the same password see plaintext. The docs mark this feature as beta.
• NAT traversal and relaying. UPnP port mapping, global discovery and public relays help devices connect across networks without manual setup.
• Web GUI and REST API. An admin interface at http://localhost:8384/, listening on localhost only by default.
• Signed releases. Release binaries are GPG-signed, the built-in automatic upgrade mechanism uses a compiled-in ECDSA signature, and macOS and Windows binaries are code-signed.

Getting started

The getting-started guide assumes two machines you want to sync. Download the latest release for your operating system from GitHub (Debian and Ubuntu users can use the project's APT repository instead), unpack it and run the binary:

syncthing

On first start Syncthing generates a configuration file and encryption keys, prints its device ID, and opens the admin GUI in your browser at http://127.0.0.1:8384/. The GUI needs cookies enabled. To connect two devices, open Actions and Show ID on one device to get its ID, then click Add Remote Device on the other device, paste the ID, and choose which folders to share. Repeat the same step in the other direction, because configuration must be mutual. The new device connects after a minute or so, and files added to a shared folder on either side start syncing.

For Docker, the repository's Docker README uses the official syncthing/syncthing image with host networking, which it strongly recommends so that local discovery works:

$ docker pull syncthing/syncthing

The container runs as UID and GID 1000 by default (changeable with PUID and PGID), stores data under the /var/syncthing volume, and exposes a health endpoint at /rest/noauth/health that the README's Compose example uses for a healthcheck. Building from source takes one command after checking out the repository or extracting a source bundle, with binaries written to ./bin:

go run build.go

If devices refuse to connect, the firewall guide lists the ports to open: 22000/TCP for the TCP sync protocol, 22000/UDP for QUIC, and 21027/UDP for local discovery broadcasts and multicasts. With UPnP enabled on both Syncthing and the router, Syncthing tries to create the port forward itself. Without port forwarding, relays may work well enough, but the docs note they perform poorly compared with a direct connection.

Use cases

• Keeping work machines in sync. A developer can share a notes folder, dotfiles or a scratch directory between a laptop and a workstation without a cloud account, with versioning as a safety net against accidental overwrites.
• Phone-to-computer photo and file transfer. Community Android builds and wrappers run the same core, so a phone can push its camera folder to a home machine automatically.
• Backup destinations and mirrors. A Receive Only folder on a NAS or home server collects changes from other devices but never sends local edits back, and staggered versioning keeps history.
• Distributing a reference copy. A Send Only folder on one machine can push configuration, media or assets to many devices, with Override Changes restoring the reference state if someone edits a copy.
• Storing data on hosts you don't fully trust. Encrypted folders let an always-on rented server relay and hold data for your devices while seeing only ciphertext, keeping in mind the feature's beta status.
• Fully private deployments. Organisations that do not want any metadata touching public infrastructure can disable global discovery and relaying, or run their own discovery and relay servers.

How it compares

The obvious comparison is with cloud sync services such as Dropbox, Google Drive or OneDrive. Those services keep an authoritative copy of your files on the provider's servers, which gives you web access, sharing links and a backup that survives losing every device. Syncthing has none of that by design: files live only on devices you control, so there is no storage fee and no third party with access to the contents, but there is also no off-site copy unless one of your devices is off-site, and two devices must be online at the same time to exchange changes, or a third always-on device must sit in between.

Compared with one-way tools like rsync run on a schedule, Syncthing is continuous and bidirectional, handles conflicts, and works across NAT without SSH access. The trade-off is a long-running daemon and a configuration model built around devices and folders rather than a single command. It is also worth being clear that synchronization is not backup: a deletion or a corrupted file propagates to every device unless file versioning is enabled on the receiving side.

Things to know before adopting

• Version 2 changes. The 2.0 release in August 2025 switched the database from LevelDB to SQLite, with a migration on first launch that can be lengthy for large setups. It also changed the logging format, stopped creating a default folder on first startup, removed old single-dash long command-line options (-home must now be --home), dropped rolling-hash detection of shifted data, made deletes a possible winner in conflict resolution, and began using three connections between v2 devices by default. Some parts of the getting-started guide still show the older default-folder behaviour.
• Deleted items are forgotten after six months. Since 2.0, records of deleted files are no longer kept forever. If you need deletes to propagate to devices that may be offline longer than that, the release notes point to the --db-delete-retention-interval option.
• Fewer prebuilt platforms. Because of SQLite cross-compilation, 2.0 stopped shipping prebuilt binaries for some platforms, including dragonfly/amd64, illumos and solaris on amd64, linux/ppc64, NetBSD, openbsd/386 and openbsd/arm, and windows/arm.
• Network defaults. Global discovery, local discovery, relaying and automatic upgrades all default to on. The security page explains what each leaks: an observer can tell a machine runs Syncthing and learn device IDs, discovery server operators can map device IDs to IP addresses, and relay operators learn the device IDs of connections they carry. Usage reporting defaults to off, though the GUI asks once about enabling it. All of these can be turned off or pointed at your own servers.
• Protect the keys. Anyone with a device's TLS keys and config file can impersonate it and read synced data. The docs advise revoking a lost device from your other devices and keeping the config folder on the same encrypted disk as the data.
• GUI exposure in Docker. Inside the Docker image the GUI listens on 0.0.0.0:8384 unless STGUIADDRESS is unset; if you make the GUI externally reachable, set up authentication and enable TLS.
• Docker networking. Docker's default bridge network hides the host's local IP addresses, which the Docker README says can break LAN connections and slow transfers unless you use host networking or configure addresses manually.
• Licence. MPL-2.0 is a file-level copyleft: modifications to Syncthing's own source files must be shared under the same licence if distributed, while running it or using it alongside other software carries no such obligation.

Project activity

As of October 2026 the repository has about 90,000 stars on GitHub and roughly 5,600 forks. It was created in November 2013, is written in Go and is licensed under MPL-2.0. The latest release at the time of writing is v2.1.7, published on 21 October 2026, and the main branch received commits in the last week. Releases are also published as an APT repository and as Docker images on Docker Hub and GitHub Container Registry. The project's support forum is the main point of contact, with the GitHub issue tracker reserved for clear bugs and security reports going to a dedicated email address.

Source code is at github.com/syncthing/syncthing, documentation at docs.syncthing.net, including the getting-started guide and security principles, and the project site at syncthing.net.