Syncthing: The File Sync Project That Treats the Cloud Like an Optional Extra

A deep dive into the P2P architecture, cryptographic identity, and failure-tolerant machinery that let your devices sync directly, safely, and without a central account.

8 to 10 min read • View on GitHub • More from syncthing

Two computers sit on opposite sides of a cracked cloud icon, linked by a taut encrypted line that runs around it instead of through it. The image explains Syncthing’s core idea: the endpoints establish trust and move data directly, while the cloud is reduced to a fallback shape in the middle. — Syncthing does not route trust through the cloud. It pushes identity to the device and lets the network get out of the way.

The goal is to provide a decentralized, secure, and private alternative to proprietary sync and cloud storage services.

Jakob Borg, Creator and Maintainer · Syncthing v0.1.0

Key Takeaways

Syncthing turns a device’s public key into its identity, which fuses authentication and encryption into one trust model.
Its architecture prefers direct peer-to-peer transport, but discovery and relays exist as support rails, not as the center of the system.
When files diverge, Syncthing protects data by preserving both versions instead of guessing a merge.
The project’s real product is not sync convenience alone, but a distributed privacy stance that makes the cloud optional.

Syncthing’s most interesting trick is not sync. It is trust. The project turns each device into its own identity, so the network never has to become a trusted middleman. That one decision changes everything downstream: setup, transport, failure handling, and even how conflicts are resolved.

The Device Is the Identity

In Syncthing, you do not log into an account and hand data to a server that promises to keep it safe. You exchange device IDs, and those IDs are derived from public keys. That means the same cryptographic machinery that proves who a device is also secures the channel it uses to talk.

That is why Syncthing feels less like Dropbox with better privacy settings and more like a design argument. The identity layer is not separate from transport security. It is the same idea, expressed at two layers of the stack.

A split desk shows one clean folder tree on one side and a conflict file marked with a .sync-conflict suffix on the other. Beneath the desk, root-like supervisor branches keep the structure standing even after a drawer has fallen open, explaining both conflict preservation and process resilience. — Syncthing refuses to guess when files diverge, and it keeps the system alive even when parts fail.

How Sync Works Without a Cloud

The mechanics are more ordinary than the philosophy, which is part of the appeal. Devices announce themselves to discovery infrastructure when needed, learn each other’s locations, attempt a direct encrypted connection, and only then fall back to a relay if the path is blocked. Once connected, they exchange file blocks over the Block Exchange Protocol and update local metadata as they go.

Syncthing is decentralized at the data path, but it still uses infrastructure around the edges to help peers find each other and stay connected.

The important part is not that discovery and relays exist. It is that they are support services, not the source of truth. The network can help peers meet, but it never becomes the place where identity or file ownership lives.

// cmd/syncthing/monitor.go, simplified
func monitorMain() error {
    stopSign := make(chan os.Signal, 1)
    signal.Notify(stopSign, os.Interrupt, sigTerm)

    stdoutLastLines := newLastLines(50)
    cmd := startWorker(stdoutLastLines)

    err := cmd.Wait()
    if err != nil {
        writePanicLog(stdoutLastLines)
    }
    return err
}

The Part That Saves Your Data When Everything Goes Wrong

Syncthing’s resilience story starts outside the sync engine. The monitor process watches the worker process, captures useful crash context, and restarts the application when appropriate. Inside the app, supervisor-style management with suture keeps smaller services alive independently instead of letting one failure take down the whole machine.

That matters because real sync systems live in ugly conditions. Wi-Fi drops, USB drives disappear, laptops sleep, and routers rewrite the rules. Syncthing is built to keep going anyway.

Failure mode	Typical centralized app	Syncthing
Sync service crashes	One process failure can take the whole client down	Monitor restarts the worker and preserves crash context
One subsystem fails	The app may become unavailable until the service returns	Supervisor trees isolate the failure and restart the child
Peer unreachable	Server remains the source of truth	Peers reconnect later or use relay paths

Why Syncthing Refuses to Merge Smarter

This is one of the project’s sharpest product choices. When versions diverge, Syncthing does not try to invent the right answer. It uses version vectors to detect conflict, then preserves both versions by creating a conflict file rather than silently merging data that may not belong together.

That sounds conservative because it is. It is also the safest possible choice for a system that runs without a central authority. If the software cannot know which copy is correct, it should stop pretending that it can.

Question	Smart merge	Syncthing’s approach
Can the app infer intent?	Sometimes, but often incorrectly	No, not when divergence is ambiguous
Risk profile	Convenience first, with possible data loss	Safety first, with visible conflicts
User outcome	One combined file, maybe wrong	Two versions, both preserved

The Network Around the Network

Syncthing is peer to peer, but not anti-infrastructure. The repository is intentionally modular: the core sync engine lives in lib/, while separate binaries in cmd/ handle discovery, relaying, crash reporting, and usage reporting. That split makes the project easier to reason about and easier to operate at different scales.

In other words, the architecture is decentralized where trust matters and pragmatic where convenience matters. That is the real pattern. Not purity for its own sake, but a careful boundary between the data plane and the support plane.

What Syncthing Is Better Than, and What It Is Not

Tool	Trust model	Central server required?	Privacy posture	Setup complexity	Best fit
Syncthing	Peer-to-peer, device identity via keys	No	Strong end-to-end privacy	Moderate	Private sync between your own devices
Dropbox or Google Drive	Centralized account and server	Yes	Convenient but service-held data	Low	Simple mainstream cloud sync
Nextcloud	Self-hosted client-server	Yes, self-hosted	Good if you operate the server	High	Broader collaboration stack
Resilio Sync	Peer-to-peer proprietary	No	Private, but closed source	Moderate	P2P sync with a polished commercial path

Syncthing is not trying to replace every cloud product. It is trying to make one narrow promise exceptionally well: your files can move directly between your devices without turning a third party into a trust center. That is a smaller product surface and a stronger thesis.

Why It Has Lasted

Longevity matters in infrastructure projects because the hard part is not the launch. It is staying coherent long enough for the edge cases to accumulate. Syncthing has done that through a stable maintainer core, a real contributor base, and a design that has not drifted far from its original promise.

The result is a rare kind of open-source maturity. The project is opinionated enough to be recognizable, practical enough to be used daily, and principled enough to remain legible after years of growth.