Syncthing: Continuous File Synchronization Without a Cloud Account

What Syncthing solves, and for whom

Syncthing is a continuous file synchronization program. It synchronizes files between two or more computers. That sentence from the README is the whole product. There is no account, no vendor server holding your bytes, and no per-seat price. The project's stated goal list puts "Safe From Data Loss" first and "Secure Against Attackers" second, ahead of ease of use and automatic behavior. That ordering is the design brief: the maintainers would rather you read a getting started guide than have the software guess.

The audience follows from that. If you have two or more machines you own (a laptop and a home server, a desktop and a NAS, a workstation and a VPS) and you want a directory to stay identical across them, Syncthing is aimed at you. The goals document says the project is "primarily about empowering the individual user." It is not a team document collaboration system, and it does not try to be one.

How the peer-to-peer sync actually works

Each Syncthing instance is a node with a device ID, and nodes connect directly to each other rather than through a central service. The wire protocol is documented separately as BEP v1, linked from the README. Connections fall into a few categories visible in the repository: direct local network discovery on port 21027/udp, direct TCP or QUIC connections on 22000, and relay connections through volunteer relay servers when a direct path cannot be established.

The dependency list in go.mod shows the machinery behind that. The QUIC transport comes from github.com/quic-go/quic-go, NAT traversal from github.com/jackpal/go-nat-pmp and github.com/ccding/go-stun, and the encrypted transport from github.com/miscreant/miscreant.go. Configuration and index data live in a SQLite database via github.com/mattn/go-sqlite3, with a LevelDB store from github.com/syndtr/goleveldb also present. Filesystem change notification uses github.com/syncthing/notify, which is a fork of the usual fsnotify library.

The practical consequence is that a sync between two machines on the same LAN never leaves the LAN, and a sync between two machines behind different NATs will try direct hole punching first and fall back to a relay. That fallback is the part people underestimate: a relayed connection is still end-to-end encrypted, but it is slower and it depends on someone else's relay being up.

Install Syncthing and pair two devices

The README does not list package manager commands. It points to the getting started guide for users, the etc directory for examples of keeping Syncthing running in the background, and a separate Docker README for containers. Release binaries are GPG signed with a key published at syncthing.net/security, and macOS and Windows binaries are also code-signed.

If you are building from source, the README gives the build command directly. After extracting a source bundle or checking out the repository, this produces binaries in ./bin:

go run build.go

The repository also ships a Dockerfile. It exposes the web GUI on 8384, the sync protocol on 22000/tcp and 22000/udp, and local discovery on 21027/udp, and it mounts a volume at /var/syncthing. The image sets STGUIADDRESS to 0.0.0.0:8384 and STHOMEDIR to /var/syncthing/config, and the entrypoint script runs as PUID 1000 and PGID 1000 by default. A health check polls the REST endpoint 127.0.0.1:8384/rest/noauth/health and looks for OK.

EXPOSE 8384 22000/tcp 22000/udp 21027/udp
VOLUME ["/var/syncthing"]
ENV PUID=1000 PGID=1000 HOME=/var/syncthing

Once a node is running, the GUI is where the work happens. You add the other machine by its device ID, accept the incoming connection on that machine, then add a folder and share it with the device you just added. The folder path is local to each machine, so the two sides do not need matching directory layouts. After the first scan, changes propagate continuously rather than on a schedule.

Where Syncthing is the wrong tool

Syncthing assumes every participating machine is one you administer. If the other end is a colleague's laptop that you cannot install software on, or a corporate file share governed by someone else's policy, the model breaks down before you start.

The README is also explicit that the official project does not cover every platform people ask about. GUI implementations for Windows, Mac and Linux are listed as third-party contributions in the documentation, not as part of the core release. The search questions about Android, iOS and iPhone are therefore answered outside this repository's README: the README names GUI wrappers and links a contributed-wrappers page, and it says nothing about an official mobile client. If your sync plan depends on a phone being a first-class peer, verify what exists on that platform before you design around it.

There is a second limitation that is easy to miss. The repository contains a set of Dockerfiles for supporting services: Dockerfile.strelaysrv, Dockerfile.stdiscosrv, Dockerfile.strelaypoolsrv, Dockerfile.stupgrades and Dockerfile.stcrashreceiver. Those are the infrastructure components that make relay, discovery and upgrade checking work. Running Syncthing in a network that blocks all outbound traffic to those services changes the connection behavior, and the README does not document what to expect in that case.

Syncthing or a hosted sync service

The obvious alternative is a hosted file sync service, where the vendor runs the servers, stores the data, and provides the clients. The difference in approach is not the sync algorithm. It is who holds the ciphertext and who is on the hook when something goes wrong.

With a hosted service, you get a support channel, a mobile client on day one, and no port configuration. You also get a third party that can read your files if it chooses, that bills you monthly, and whose outage is your outage. Syncthing inverts every one of those. The README's first two goals are data safety and resistance to attackers, and the project achieves that partly by not having a server to compromise. The cost is that you are the operator. Device IDs must be exchanged, firewall rules must permit 22000 and 21027, and if both machines sit behind symmetric NAT the connection may end up relayed.

For a single user with two machines and a working LAN, direct sync is usually the better trade. For a team that needs shared permissions, audit logs and a phone number to call, it is not.

Licence, upgrades and the cost of staying current

All code is licensed under the MPLv2 License, and the Dockerfile labels the image with org.opencontainers.image.licenses="MPL-2.0". MPL-2.0 is a file-level copyleft licence, which is a different obligation from a permissive licence like MIT. If you embed Syncthing in a product, the modification and distribution terms apply to the covered files. That is a description of the licence text, not legal advice; get your own counsel if you are shipping it.

The README states that release binaries are GPG signed, and that there is a built-in automatic upgrade mechanism using a compiled-in ECDSA signature, disabled in some distribution channels. That last clause matters operationally. A binary from a distribution repository may not self-upgrade, so your upgrade path is the distribution's, not Syncthing's. The repository has a Dockerfile.stupgrades entry, which is the upgrade server component, and the release history shows a steady cadence: v2.1.3 on 2026-08-05, v2.1.4-rc.1 on 2026-08-19, and v2.1.4-rc.2 on 2026-08-24. The last push to the default branch was on 2026-08-24. Anyone running this should expect to track releases rather than install once.

Editorial conclusion

Adopt Syncthing if you own the machines on both ends of the sync and you are willing to configure device IDs and folder sharing once. Do not adopt it if you need a hosted service with a support contract, or if you expect a mobile client to be part of the official release set. Before committing, verify that the device ID exchange works across your network, confirm which ports 22000/tcp, 22000/udp and 21027/udp your firewall allows, and check whether your distribution ships a build with the automatic upgrade mechanism disabled.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes