Syncthing — Overview#

Identity#

Purpose#

Syncthing is a continuous, peer-to-peer file synchronization program that keeps files in sync between two or more computers in real time. It is designed primarily for individuals who want to retain full control of their own data without relying on a central cloud provider. Unlike Dropbox or similar services, Syncthing uses a custom Block Exchange Protocol (BEP) to transfer only changed blocks, communicates over TLS, and requires no third-party server to hold user files.

Significance#

Syncthing is one of the most prominent open-source Go applications outside of the cloud-native space, with over 65k GitHub stars and an active community since ~2013. It is architecturally significant as a long-lived production Go codebase that has evolved through many Go versions while maintaining backward compatibility. It demonstrates how to build a secure, distributed, protocol-centric application in Go — including a custom binary protocol with XDR serialization, QUIC transport, NAT traversal, a supervisor-tree concurrency model, and an embedded web UI — all as a single self-contained binary. The codebase is also notable for shipping infrastructure services (a global discovery server and a relay server) alongside the main application within the same repository.

Key metrics#

  • Go files: 548
  • Top-level directories: assets, cmd, etc, gui, internal, lib, man, meta, proto, relnotes, script, test
  • Direct dependencies: 46
  • Indirect dependencies: 50
  • Binary targets (cmd/): syncthing (main application), stdiscosrv (global discovery server), strelaysrv (relay server), dev (dev tooling), infra (infrastructure tooling)
  • First commit / age: Project started ~2013 (Jakob Borg / calmh); repository is actively maintained as of 2026

Notable characteristics#

  • Supervisor-tree concurrency via thejerf/suture: Syncthing adopts an Erlang-inspired actor/supervisor model for managing goroutines, giving each subsystem (scanner, model, connections, events, discovery) its own supervised service that can be individually restarted on failure — unusual and architecturally distinctive in the Go ecosystem.
  • Custom Block Exchange Protocol (BEP) over QUIC/TLS: The core sync protocol is defined in .proto files (protobuf) and transported over QUIC (via quic-go), with XDR as an older serialization format still present. This makes the networking layer a first-class architectural concern rather than an afterthought.
  • Multi-package lib/ as a reusable library: The lib/ directory contains ~30 sub-packages (fs, model, config, protocol, scanner, ignore, events, etc.) that are structured as a reusable library, not just internal application code. The cmd/syncthing binary wires these together, enabling third-party GUI wrappers and integrations.
  • Dual SQLite strategy: Both mattn/go-sqlite3 (cgo-based) and modernc.org/sqlite (pure Go) are present, giving the build flexibility for cgo-free deployments — a pragmatic choice for cross-compilation and containerized targets.
  • Infrastructure-as-code in the same repo: The discovery server (stdiscosrv) and relay server (strelaysrv) are full production services shipped alongside the main application, including their own AMQP/RabbitMQ and MaxMind GeoIP integrations. This makes the repository unusually self-contained for a client application.
Backward restic — Testing Syncthing — Structure Forward