Syncthing ranks data safety above ease of use, and its build, Docker image and upgrade signing all follow from that order

Seven goals in a fixed order, with data safety first

Syncthing states its goals as a ranked list, most important first: safe from data loss, secure against attackers, easy to use, automatic, universally available, for individuals, and everything else. The ranking is a design rule, not a slogan. Ease of use sits third, so a convenience that could risk corrupting a file or exposing it to an unauthorized party loses by definition. Automatic sits fourth, and the stated aim is that user interaction should be required only when absolutely necessary, which means some prompts survive because the first two goals demand them. The sixth goal, for individuals, also sets expectations: the project describes itself as primarily about empowering the individual user. Teams looking for central administration should read the full GOALS.md in the repository before assuming that use case is a priority.

go run build.go is the single build entry point

Building from source does not go through make or a separate installer. After extracting a release source bundle or checking out git, you run:

go run build.go

and the binaries land in ./bin. The repository also carries build.sh and build.ps1 wrappers, plus a guide on docs.syncthing.net with more detail. The go.mod file declares go 1.26.2, so an older Go toolchain is the first thing that will stop a source build. The module pulls in libraries such as quic-go v0.63.0, mattn/go-sqlite3 v1.14.52, prometheus client_golang v1.25.0 and thejerf/suture v4.0.6, and the protocol definitions sit under proto/ with buf.yaml and buf.gen.yaml for code generation. For most users the release binaries are the simpler route; building yourself is for packagers and contributors.

The official Docker image builds Syncthing with upgrades switched off

The root Dockerfile uses a two-stage build. The builder stage starts from golang:$GOVERSION, where GOVERSION defaults to latest, sets CGO_ENABLED=0, and only compiles if a prebuilt syncthing-linux-$TARGETARCH binary is not already present:

go run build.go -no-upgrade build syncthing

The -no-upgrade flag matters. The container binary does not carry the self-upgrade path that release binaries use, so you update by pulling a new image. The runtime stage is plain alpine with ca-certificates, curl, libcap, su-exec and tzdata added. Data lives in the /var/syncthing volume, with STHOMEDIR=/var/syncthing/config, and the process runs under PUID=1000 and PGID=1000 by default. If the host directories you mount belong to a different user, change those two variables, or Syncthing inside the container will not be able to write to them.

Four exposed ports and a GUI bound to every interface inside the container

The Dockerfile exposes 8384, 22000/tcp, 22000/udp and 21027/udp. It also sets STGUIADDRESS=0.0.0.0:8384, so inside the container the web GUI listens on all interfaces rather than loopback. That is convenient for reaching the GUI from the host, but it moves the exposure decision to your port mapping. If you publish 8384 on a public interface, the GUI listener is reachable from that network. The health check adds another detail: every minute it runs curl against 127.0.0.1:8384/rest/noauth/health and greps for OK, with a ten second timeout. That path is, by its name, a no-auth REST endpoint. For a home server behind a router this is unremarkable. For a VPS, map 8384 to localhost or a private network and leave only the sync ports open.

Signed releases, and an auto-upgrader that some channels remove

Release binaries are GPG signed with the key published at https://syncthing.net/security/. macOS and Windows binaries are code-signed as well. On top of that, Syncthing has a built-in automatic upgrade mechanism that checks a compiled-in ECDSA signature before applying a new binary. The catch is that this mechanism is disabled in some distribution channels, and the Docker build above is one example through -no-upgrade. The consequence for readers: whether your install keeps itself current depends on where you got it. A copy from a Linux distribution repository or a container image follows that channel's update schedule, not Syncthing's own. If you want the latest release on the day it ships, use the official binaries; if you prefer your package manager, accept that you may sit a version behind.

The core repository ships no desktop app, so tray and menu bar clients come from elsewhere

This repository produces the Syncthing program and its web GUI under gui/. It does not produce a native Windows, Mac or Linux desktop wrapper. Those are listed as several GUI implementations on the contributed software page of docs.syncthing.net, separate from the core project. For keeping Syncthing running in the background, the etc/ directory holds example service configurations rather than a single installer that sets it up for you. The practical result is that two people both saying they run Syncthing on Windows may be running quite different wrappers, with different update habits and settings screens. When you pick a wrapper, check which Syncthing version it bundles and whether it uses the built-in upgrader, since that decides how quickly you receive fixes from releases such as v2.1.7.

One repository builds the client and its supporting servers

Besides the main Dockerfile, the top level carries Dockerfile.stdiscosrv, Dockerfile.strelaysrv, Dockerfile.strelaypoolsrv, Dockerfile.stupgrades, Dockerfile.ursrv, Dockerfile.stcrashreceiver and Dockerfile.builder. The server programs behind those images live in the same tree as the client, under cmd/, and the README-Docker.md file covers running Syncthing itself in a container. For an operator this means the infrastructure services are versioned alongside the client and built from the same go.mod, so running your own copies is possible from this one checkout. The protocol between devices is specified separately as BEP v1 on docs.syncthing.net, which is the document to read if you want to know what the client and those services exchange rather than inferring it from the code.

Release candidates land days before each tagged release

The v2.1.7 cycle shows the pattern: v2.1.7-rc.3 on October 18, 2026, then v2.1.7-rc.4 and the final v2.1.7 on October 21, 2026, both on the same day. The last push to the main branch was on November 2, 2026, and the repository is not archived. Release notes are kept in a relnotes/ directory in the tree. Security problems are not handled in the public tracker: the project asks for vulnerability reports by email to [email protected], not on the forum or in GitHub issues. General questions go to forum.syncthing.net first, and the GitHub issue tracker is for problems that are clearly bugs. Code is under the MPLv2 license.

Editorial conclusion

Syncthing suits an individual who wants files kept in step across their own machines without a central service, and who is comfortable opening a few ports and reading the docs site for setup. It is a weaker fit if you want a packaged desktop app from one vendor, since GUI wrappers come from other projects, or if you expect every install channel to update itself. Before deploying, decide where port 8384 will be reachable, check whether your distribution channel keeps the built-in upgrader, and verify release binaries against the GPG key on syncthing.net/security.

Frequently asked questions

Official sources

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