Overview

Syncthing's strongest promise is disciplined file-state handling across authorized devices: certificate identity, flexible routes, folder policy, indexed desired state, verified blocks, conflict handling, and cautious commits work together when their conditions hold. Deployment choices must match the feared failure, from propagated edits and blocked networks to privacy leakage, lost keys, endpoint compromise, or device damage. Semantic merging, anonymity, and independent disaster recovery remain outside the promise; untrusted-device encryption is beta/testing and still exposes sizes and change patterns.

Learning outcomes

Syncthing's guarantees are conditional on configured identities, usable routes, correct folder policy, available content, and expected filesystem behavior.
It can reject uninvited certificates, verify blocks, preserve concurrent alternatives, and avoid committing half-built files, but it cannot infer human intent.
Folder modes, versioning, relays, and beta-qualified untrusted encryption address different risks; endpoint controls and independent backups remain separate responsibilities.

Keywords

SyncthingDeploymentSecurityRecoveryPrivacyBackups

What Syncthing Can Safely Promise

Syncthing can safely promise a chain of protections, not a single magical property called “sync.” This final chapter reconnects the opening question—how can independent devices change one another's files without a central owner or silent loss—to the complete path from identity and reachability to indexed state, verified blocks, conflict handling, and recovery policy. The practical judgment is a deployment test: ask who is authorized, how the peer is reached, what evidence defines the desired state, what happens when edits or failures collide, and which risks still require controls outside Syncthing.

One file change, seen as a whole system

Imagine a laptop and a home server sharing a folder. A document is edited on the laptop while the server is offline. When the server returns, a safe result depends on more than whether the two machines can open a socket.

First, the server must be the device the laptop was configured to expect. The device ID binds that expectation to a certificate fingerprint rather than to a hostname or a friendly device name. TLS protects the connection and presents the certificates that allow both sides to perform the identity check. If the certificate does not match the configured peer, Syncthing should reject the path even if discovery found a reachable address.

Second, the devices need a route. The laptop might have a static address, a local-discovery result, a global-discovery result, or a relay path. These mechanisms solve different availability problems, but they do not replace the certificate check. A relay may forward the connection when both devices are behind NAT; it still does not become the authority that decides which device is allowed to exchange the folder.

Third, the relationship must include this folder. Device authorization is broader than folder sharing. A connected server may be deliberately excluded from a private folder, or a shared folder may be paused. Once the folder relationship is accepted and running, the peers can exchange cluster and index information. Only then does the question become “which file state should this device pursue?” rather than merely “can these devices talk?”

Fourth, the model must describe the desired state. The laptop's local index announces file metadata and block evidence. The server compares the peer's view with its own view and the cluster's selected global state. If the laptop's version is a straightforward successor, the server can identify the blocks it lacks. If the laptop and server independently changed the same path, the version vectors expose that concurrency instead of hiding it behind one clock value.

Fifth, the required content must be realized safely. The server can reuse matching blocks already on disk, copy matching blocks from another local file, or request missing blocks from one or more peers. Every ordinary plaintext block is checked against the desired hash. A relay or an authenticated peer is not allowed to substitute arbitrary bytes merely because it is inside the transport trust boundary. The block evidence gives the receiver a second, content-level test.

Sixth, the filesystem must still agree with the assumptions made when the transfer began. If the user edits the server's local document while the remote version is being assembled, replacing the path immediately could destroy an unannounced local change. Syncthing rechecks the on-disk state, handles conflicts or archives according to policy, stages the candidate in a temporary file, and replaces the destination only after the candidate is complete and the relevant checks succeed.

Finally, the system needs a recovery meaning for the change. A conflict copy can preserve a competing edit. Versioning can archive an older file replaced by a remote change. A receive-only policy can prevent local edits from becoming cluster authorship. A separate backup can provide a copy outside the synchronization failure domain. These are not redundant names for the same feature; they answer different questions about what should remain recoverable after a valid change, a mistaken change, or a damaged device.

Published by DeepMox

FAQ

What protections does Syncthing provide when conditions are met?

When conditions are met, Syncthing can authenticate devices, protect transport, verify ordinary blocks, preserve concurrent alternatives, and stage safe replacements, but these are process guarantees rather than semantic judgment.

Which risks remain outside Syncthing's control?

Anonymity, stolen keys, compromised endpoints, semantic merging, whole-device failure, and independent disaster recovery remain outside Syncthing's built-in promise.

How should a Syncthing deployment match its recovery policy to risk?

Match the folder mode and versioning to who may author changes and which remote replacements should be recoverable, then add independent backups for device-wide or compromise failures.

Previous8 minSyncthing Folder Authority and Recovery

All chaptersBack to Topic