# Syncthing: seven ranked goals, eight Dockerfiles and a container that listens on every interface

> Syncthing is a continuous file synchronization program in Go, and its README is short because it hands almost everything to a documentation site whose source lives in a second repository. What the file does spell out is a ranked list of seven goals, the first of which is protecting your data, and a set of details in the container build that decide how exposed the interface ends up.

**syncthing/syncthing** — Syncthing continuously synchronizes files between two or more computers over peer-to-peer connections, prioritizing protection against data loss and unauthorized access.

- Repository: https://github.com/syncthing/syncthing
- Website: https://syncthing.net/
- Stars: 89,022 · Forks: 5,498
- Language: Go
- License: MPL-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/syncthing-syncthing

## Seven goals in priority order, and the seventh is everything else

Most of the README is a numbered list. Syncthing should be safe from data loss first, secure against attackers second, easy to use third, automatic fourth, universally available fifth and for individuals sixth. Data protection is stated twice, once as avoiding corruption of files and once as refusing eavesdropping or modification by unauthorised parties, and the list says outright that it is ordered by importance.

Consequence: a ranked list is a statement about what gets sacrificed, and the seventh entry makes that explicit. Everything else is a bucket for things the project cares about that did not make the list, and the file says optimising for those is fine as long as they do not conflict with the goals above. Nothing in the list names a mechanism, so safe from data loss is a promise to be judged against rather than a feature you can check.

## The container binds the web interface to 0.0.0.0 and its health check skips TLS checks

The image ends with two environment settings and a health check:

```dockerfile
ENV STGUIADDRESS=0.0.0.0:8384
ENV STHOMEDIR=/var/syncthing/config
```

```bash
HEALTHCHECK --interval=1m --timeout=10s \
  CMD curl -fkLsS -m 2 127.0.0.1:8384/rest/noauth/health | grep -o --color=never OK || exit 1
```

It exposes 8384, 22000 over tcp, 22000 over udp and 21027 over udp, and declares /var/syncthing as a volume.

Consequence: STGUIADDRESS tells Syncthing to listen on every interface rather than on loopback, so a container with a published port hands the web interface to anything that can reach the host, and that interface is where folders are configured. The health check is the mirror image of that choice, since the -f and -k flags make it succeed against a self-signed certificate, which is convenient inside a container and the wrong default anywhere with a name on it.

## The build stage pulls the Go toolchain even when it copies a prebuilt binary

The builder stage is guarded by a shell test, and the comment above it admits the shape is awkward:

```bash
if [ ! -f syncthing-linux-$TARGETARCH ] ; then \
    go run build.go -no-upgrade build syncthing ; \
    mv syncthing syncthing-linux-$TARGETARCH ; \
  fi
```

CGO_ENABLED=0 is set for the build, and the final image is alpine with ca-certificates, curl, libcap, su-exec and tzdata added.

Consequence: the test decides whether to compile, but it runs inside a golang image that has already been pulled, so every build pays for the full Go toolchain whether or not the compile happens. When a prebuilt binary is present the builder stage is pure overhead in wall time and in layer cache, and the comment says the file cannot express a conditional section to avoid it.

## Eight Dockerfiles sit at the root and the README names none of them

The top level holds Dockerfile plus Dockerfile.builder, Dockerfile.stcrashreceiver, Dockerfile.stdiscosrv, Dockerfile.strelaypoolsrv, Dockerfile.strelaysrv, Dockerfile.stupgrades and Dockerfile.ursrv. The README does not say which one you want. Its Docker section is a single sentence pointing at README-Docker.md, and the documentation itself lives in a separate repository at github.com/syncthing/docs rather than in this one.

Consequence: running it with Docker means choosing between eight images with separate roles, among them a crash receiver, a discovery server, a relay server and an upgrade helper, and the entry point for that choice is a second README. Someone who assumes Dockerfile is the product gets a synchroniser, and someone who needs a relay needs a different image entirely, with nothing at the top level hinting that the choice exists.

## Version 2.1.6 exists as two release candidates and no final

The three newest tags are v2.1.6-rc.3 on 2026-09-22, v2.1.6-rc.1 on 2026-09-15 and v2.1.5 on 2026-09-08. The stable line stopped three weeks ago while the 2.1.6 branch moved through candidates, and the visible list skips rc.2 entirely.

Consequence: the highest version number in the repository is not something you can install unattended, and the automatic upgrade mechanism the README describes is a separate mechanism from picking up a tag, so an operator waiting for 2.1.6 installs it by hand. A reader who sees 2.1.6-rc.3 at the top of a release list gets no signal from the tag alone that it is a candidate rather than a release.

## Security reports go to an email address and deliberately not to the tracker

The contact section is unusually specific about routing. The forum is named as the first and best point of contact, and something that is clearly a bug belongs in the GitHub issue tracker. A suspected Syncthing-related security vulnerability takes a different path: it should be emailed to security@syncthing.net, and the file says explicitly not to report it in the forum or the issue tracker.

Consequence: that is the correct call for a flaw that has no fix yet, and it has a cost for the people running the software. A private report leaves no public record, so there is no list of known unpatched issues to check a version against. The only public signal arrives when a fix ships, which means the release notes are where you have to look rather than any query you can run.

## go run build.go writes to ./bin, and the module asks for Go 1.26.2

Building from source takes one command, run after extracting a release source bundle or checking out git:

```bash
go run build.go
```

Binaries land in ./bin, with a separate guide for the details. The module file names the toolchain directly with a go 1.26.2 directive, and its dependency list includes a command line parser, a QUIC stack, LDAP bindings, GeoIP databases, LevelDB and SQLite.

Consequence: the build tool is compiled on the fly, so a first build pays for that before it produces anything, and the directive pins a specific Go release rather than a minimum. The dependency list also shows what the binary reaches for, since a synchroniser that leans on discovery services, relays over QUIC and device lookup over LDAP is a wider surface than a plain file copier.

## Conclusion

Use Syncthing when you want two or more of your own machines to converge on the same files and you are willing to read a documentation site rather than a README. Three things to check before you deploy it. The container image sets STGUIADDRESS to 0.0.0.0:8384, so publishing that port publishes the web interface to anything that can reach the host, and that interface is where folders get configured. Security reports go to an email address and explicitly not to the issue tracker, so there is no public list of unpatched issues to check your running version against. And 2.1.6 exists only as release candidates, with v2.1.5 from 2026-09-08 the newest stable, which matters if you let the built-in upgrader run without watching it.

## FAQ

### Is Syncthing discontinued?

No. The repository is not archived, the last commit to main is dated 2026-09-29, and releases were published in September 2026, including v2.1.6-rc.3 on 2026-09-22 and v2.1.5 on 2026-09-08. The most recent stable release is v2.1.5.

### Is Syncthing completely free?

The code is licensed under the MPLv2 License, and the project describes itself as open source continuous file synchronization aimed primarily at individual users. The README also states that there is no charge for the software itself, with paid channels such as the built-in upgrade mechanism being disabled in some distribution channels.

### Can I trust Syncthing?

The first two of the project's seven ranked goals are safe from data loss and secure against attackers. Release binaries are GPG signed with a key published at syncthing.net/security, the built-in automatic upgrade uses a compiled-in ECDSA signature, and the macOS and Windows binaries are also code-signed.

### What is Syncthing used for?

It is a continuous file synchronization program that keeps files the same between two or more computers. The README points to a getting started guide, ships examples for running it in the background under the etc directory, and links GUI implementations for Windows, Mac and Linux.

### How do I install Syncthing?

The README carries no install command. It points to a getting started guide for the general case, to README-Docker.md for running it in a container, and to a list of GUI implementations for Windows, Mac and Linux, with a forum named as the first point of contact for anything the file does not answer.

## Sources

- [Official documentation](https://syncthing.net/)
- [Official README](https://github.com/syncthing/syncthing#readme)
- [Project repository](https://github.com/syncthing/syncthing)
- [Release notes](https://github.com/syncthing/syncthing/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/syncthing-syncthing