Syncthing is honest about the difference between owning sync and owning backup

01The unit of trust is a device

Syncthing identifies each installation with a device ID derived from its cryptographic identity. Devices do not begin sharing all data merely because they can find one another. An operator introduces devices and chooses which folders to share with which peers. This explicit model differs from signing several clients into one storage account. Each participating device is a peer with its own local folder state and permissions.

The distinction matters during onboarding and removal. A device ID should be verified through a trusted channel before accepting a share, particularly when an unexpected introduction appears. Removing a device from configuration stops future synchronization with that peer, but it cannot erase copies already received or revoke backups outside Syncthing. Trust decisions therefore belong to both the software configuration and the human process for identifying devices, retiring hardware and responding to a lost endpoint.

02Indexes describe files, blocks move the content

For a shared folder, devices exchange information about files and their versions. File content is divided into blocks so a receiver can request the material needed to reach the agreed folder state rather than retransferring every unchanged byte. Hashes support block identification and integrity checks. A local database helps the application track the filesystem and what peers report. The protocol is designed for continuous synchronization across machines that may not always be connected.

This model explains why scanning and watching matter. Files can change outside Syncthing, and the application needs to notice them before advertising new state. Filesystem notifications can speed detection, while periodic scans cover changes that notifications miss. Very large directory trees, slow disks and many small files create different resource profiles. Operators can tune documented settings, but should first observe whether the delay is discovery, scanning, hashing, transfer, remote write speed or another device being offline.

03Discovery and relay solve reachability, not authorization

Devices need network addresses before they can connect. Syncthing supports local discovery and global discovery, plus manually configured addresses. Local discovery helps peers find one another on a local network. Global discovery can help a device publish and find reachable addresses associated with device identity. If direct connectivity is unavailable, relay infrastructure can carry encrypted traffic between peers. These mechanisms reduce router and address friction.

Discovery does not decide which device is trusted with a folder. That remains an explicit configuration choice. Relay traffic remains protected by the device connection's encryption, according to Syncthing's security documentation, but using discovery or relays still exposes some connection metadata to infrastructure involved in finding or carrying traffic. Organizations with strict network policies can review and limit these mechanisms, provide their own infrastructure or configure static addresses. Connectivity convenience and metadata policy should be assessed separately.

04Encrypted transport is one layer of security

Syncthing connections use TLS, and device identity is tied to certificates and device IDs. This protects file data in transit between accepted peers and lets devices authenticate the peer identity they expect. The security documentation is the right source for current protocol detail. It is still possible to expose data through an unlocked endpoint, an unprotected management interface, a broadly readable synchronized directory or a compromised operating-system account.

The web management interface controls shares and devices, so its listening address and authentication need deliberate configuration. A browser on a hostile network or a reverse proxy can change the trust boundary. Syncthing generally relies on the operating system for access to local files; it is not a separate encrypted vault for every folder. Full-disk encryption, user permissions, patching and screen-lock policy remain relevant. A strong connection does not make either endpoint trustworthy after compromise.

• Verify device IDs before accepting a new peer.
• Protect the management interface and avoid exposing it broadly without a reviewed proxy and authentication design.
• Apply endpoint access controls and disk protection according to the sensitivity of synchronized files.

05Folder types encode authority

A send-and-receive folder participates normally in changes from both local and remote devices. Send-only and receive-only modes adjust how a device treats divergence and are useful for particular distribution or collection patterns. They should not be treated as security boundaries. A user with local access can still manipulate files, and an administrator can change configuration. The modes primarily express synchronization behavior and which side's changes should be considered authoritative during normal operation.

Ignore patterns can exclude paths, temporary files or machine-specific material. Because ignored items are outside the synchronized set, inconsistent patterns across devices can create results that surprise users. Permission and ownership metadata also differ across operating systems and filesystem capabilities. Before synchronizing an application data directory, confirm that the application supports file-level replication and that simultaneous processes will not corrupt it. Databases and virtual-machine disks often require application-aware backup or replication rather than live folder synchronization.

06Conflicts are evidence of concurrent truth

When two devices change the same file without seeing each other's update, Syncthing cannot infer the user's semantic intent. It preserves a conflict copy according to its documented conflict-handling behavior instead of silently merging arbitrary file formats. A human or application must inspect the versions and decide which content to retain. Text-based merge tools may help, while binary documents often require manual comparison.

Frequent conflicts usually point to a workflow problem. Several people may be editing one file through a tool that has no collaboration protocol, or devices may remain disconnected for long periods. Syncthing keeps bytes aligned; it does not provide Google-Docs-style operation merging, record locking or application transactions. Shared creative and office documents need agreed editing habits. If simultaneous collaboration is the main requirement, choose an application built around collaborative semantics and use Syncthing for appropriate supporting files.

07Versioning helps, but sync is still not backup

Syncthing offers file-versioning methods that can preserve replaced or deleted files on receiving devices. The available approaches have different cleanup and retention behavior. Versioning is valuable for an accidental edit or deletion that has already propagated. It should be configured before the incident and tested so users know where versions live and how to restore them. Preserved versions consume local storage and are subject to the health and access of that same device.

A ransomware process or filesystem failure can damage the live folder and potentially the local versions available to the same account. Theft, fire or an operator mistake can remove several synchronized copies. Backup needs an independent failure boundary, retention and a restore test. An offline or immutable backup protects against scenarios where perfectly functioning synchronization spreads unwanted state. Syncthing can be one source feeding that backup, but more peers do not automatically create independent recovery.

08Operations remain pleasantly visible

The management interface and logs expose device connectivity, folder state, errors and transfer progress. A healthy operation checks for out-of-sync items, repeated scan failures, low disk space, unavailable peers and version mismatches. Devices can update on different schedules, so release notes and compatibility guidance should be reviewed before broad upgrades. Signed releases and published checks provide a stronger installation path than copying an unknown binary.

Remote or unattended devices need service supervision, startup configuration and alerting appropriate to their importance. A server in a closet can quietly stop syncing while local users continue editing. Monitoring only the process is insufficient; the folder state and last successful contact matter. Storage growth from versions, ignored permission errors and unavailable devices deserve visible ownership. Syncthing avoids a mandatory central service, which means no central provider is automatically watching these conditions for the operator.

09MPL 2.0 preserves an open file-level boundary

The syncthing/syncthing repository is licensed under Mozilla Public License 2.0. MPL applies copyleft obligations at the covered-file level when covered software is distributed, rather than automatically applying one license to every separate file in a larger work. Modifications to covered source files and required notices need proper handling. The actual license should be reviewed for any modified distribution, appliance or bundled product, with legal advice where the architecture is consequential.

For ordinary users, the more immediate decision is fit. Syncthing is strongest when trusted devices need continuous copies of working folders and users accept endpoint ownership. It is weaker for centralized governance, untrusted public sharing and application-level collaborative editing. Its design is unusually direct about peer identity and data movement. The safest adoption is equally direct about what synchronization protects, what it can propagate and which independent backup will recover the rest.