Syncthing: The File Sync That Never Asks a Cloud for Permission

"Dropbox's business model requires your files to sit on Dropbox's disks. Syncthing's architecture makes that impossible — there is no disk to sit on."

Every mainstream file-sync product works the same way: your files go up to someone else's server, then come back down to your other devices. That's convenient, and it means a third party necessarily holds a copy of everything you own — with the legal and security exposure that implies. Syncthing (GitHub: syncthing/syncthing) removes the middle entirely. As of September 2026 it carries roughly 88,000 stars, is licensed MPL-2.0, ships as v2.1.3, and is maintained by the Syncthing Foundation, a Swedish non-profit. Two of your devices synchronise directly, encrypted with TLS, authenticated by cryptographic certificates. There is no account, no storage quota, no subscription — because there is no server.

This is the honest breakdown: how peer-to-peer sync actually works, the folder modes that prevent you from destroying your own data, the one place where a third party does briefly appear (and how to remove it), what it costs, and the real limitations — including the Android situation.

1. What Syncthing Is (and What It Definitely Isn't)

The confusion to clear up first: Syncthing is not a cloud storage service. There's no central copy. If you sync a folder between a laptop and a desktop and both are switched off, the data exists only on those two machines — nowhere else.

That has a consequence people discover the hard way: deleting a file on one device deletes it on all of them. Sync propagates deletions by design. If you delete a folder locally and Syncthing is running, the deletion propagates. This is correct behaviour for a sync tool and catastrophic if you were treating it as a backup. (More on that in section 6 — it's the single most important thing in this article.)

What it is: a continuous, bidirectional, peer-to-peer file synchronisation program. You nominate folders, you nominate which devices share them, and Syncthing keeps them convergent in near real time. Every device is a peer. Any of them can be offline without breaking anything; changes merge when they reconnect.

The project has been running since 2013 — over twelve years of continuous development, which in self-hosting terms is ancient and reassuring.

2. How It Actually Works

Three concepts explain the whole system.

Device IDs. Every Syncthing installation generates a cryptographic identity at first run — a long string encoding a certificate fingerprint. Devices are identified by this, not by username or IP address. Two devices only talk after you explicitly exchange and approve these IDs on both sides. There's no central registry and no way to be tricked into syncing with a stranger.

Folders. A shared folder has an ID (a short label, not the path), and each device independently decides where on its own filesystem that folder lives. Your laptop can keep Projects at /home/you/Projects while your NAS keeps it at /mnt/pool/projects. The paths need not match.

The Block Exchange Protocol. When a file changes, Syncthing doesn't re-upload the whole thing. It splits files into blocks, hashes them, and transfers only the blocks that actually differ. Edit one line in a 2 GB database file and you transfer megabytes, not gigabytes. This is the same insight behind rsync and BitTorrent, and it's why Syncthing feels fast even over slow links.

Everything is transported over TLS with the device certificate providing both encryption and authentication. There's no plaintext path and no anonymous access.

3. Discovery and Relays: Where a Third Party Appears

Here's the part a purely P2P story glosses over. For your laptop to sync with your NAS, it must first find it — and both are probably behind NAT with dynamic addresses.

Syncthing solves this with global discovery: devices announce their presence to community-run discovery servers, which help peers find each other. These servers learn your device ID and IP address. They do not receive your files or folder contents.

When a direct connection isn't possible (both peers behind restrictive NAT), traffic can route through relay servers. Relays carry encrypted traffic they cannot read — TLS is end-to-end between your devices — but they do carry it, and they consume volunteer bandwidth.

Both mechanisms are optional and both are self-hostable. The project publishes discosrv and relaysrv in its own repositories. For maximum isolation:

• Set globalAnnounceEnabled: false to stop talking to public discovery servers.
• Use local discovery (works automatically on the same LAN) and/or static addresses for known peers.
• Run your own relay if you need one.

A typical home setup can be fully self-contained: LAN discovery plus Tailscale or Headscale for remote peers, public discovery and relays disabled entirely. In that configuration, no third party ever learns that your devices exist.

4. Getting It Running

On a Linux server, the official repository delivers a systemd service:

# Add the official apt repo, then:
sudo apt install syncthing
systemctl enable --now syncthing@youruser

Or via Docker, which is how most people run it on a NAS:

services:
  syncthing:
    image: syncthing/syncthing:2.1.3
    container_name: syncthing
    hostname: syncthing-host
    environment:
      - PUID=1000
      - PGID=1000
    volumes:
      - ./config:/var/syncthing/config
      - ./data:/var/syncthing/data
    ports:
      - 8384:8384   # web GUI
      - 22000:22000/tcp
      - 22000:22000/udp
      - 21027:21027/udp
    restart: unless-stopped

First-run sequence:

1. Open http://localhost:8384. It will warn that the GUI has no password — set one immediately, even for a LAN-only instance.
2. Under Actions → Show ID, copy your device ID.
3. On the second device, add the first device and paste that ID. Approve the incoming request on the first device.
4. Share a folder: pick a folder ID, set a path on each device, and select which devices to share with.

The web GUI is served on localhost by default. To reach it from another machine, either SSH-tunnel, put it behind a reverse proxy with authentication, or change the GUI listen address deliberately — don't just bind it to 0.0.0.0 and hope nobody scans your network.

5. Folder Modes: The Setting That Prevents Disasters

This is the most under-appreciated feature in Syncthing, and it's where experienced users diverge from beginners.

Send & Receive — the default. Changes flow both directions, including deletions. Right for genuine two-way sync between machines you actively use.

Send Only — this device's changes propagate out; remote changes are ignored and reported as "out of sync." This is the correct mode for a canonical source: a scanner, a photo import box, a machine where files originate. It makes accidental remote deletion of a local archive impossible.

Receive Only — this device accepts changes but never sends them. Use it for a backup target or archive. If someone edits on the archive side, Syncthing flags it rather than propagating it. Deletions made elsewhere are applied locally, which is what you want in an archive.

The pattern that saves people: laptop and desktop in Send & Receive; NAS in Receive Only. Now a misguided delete on the NAS cannot wipe your laptops. Combine that with versioning on the NAS and you have something that behaves like backup, even though it isn't technically one.

6. Sync Is Not Backup — Add Versioning

Repeat until internalised: synchronisation propagates deletion; backup preserves history. If ransomware encrypts your files, Syncthing will faithfully replicate the encrypted versions to every peer.

Syncthing's built-in answer is file versioning, configured per folder:

• Trash Can — deleted files move to .stversions for N days. Simple, predictable.
• Simple — keeps N old copies of each file.
• Staggered — keeps versions with increasing age spacing (one per hour for a day, one per day for a month, one per year thereafter). The best space-to-history ratio for most people.
• External — calls your own script, for arbitrary retention logic.

Enable Staggered versioning on at least one device, preferably the one in Receive Only mode. Note the caveat: versioning only protects files that changed or were deleted through Syncthing. Files deleted before you enabled versioning, or on a device where it isn't enabled, are simply gone.

For genuine backup, run an actual backup tool over the top — Restic, Borg, or Kopia pointed at off-site storage. Syncthing moves your data between your machines; backup protects it from your machines.

7. The Honest Limitations

The official Android app was discontinued. This surprises people. The original Syncthing Android app is no longer maintained; the community fork (syncthing-fork) is what Android users should install now. It works, but "the Android story is a community fork" is a real caveat for a tool whose main use case includes phones.

No block-level de-duplication across folders. Moving a file between two shared folders can result in a full re-transfer. Annoying with large media libraries, occasionally expensive on metered connections.

It will faithfully sync your mistakes. Already covered: deletion, ransomware, a bad find-and-replace on a code tree — all propagate at the speed of your network.

Conflict handling produces extra files. When two devices edit the same file while disconnected, Syncthing keeps both: yours stays, and the other becomes filename.sync-conflict-20260830-142310.txt. Nothing is lost, but you now have files to reconcile manually. This is the safe choice, though it confuses people who expect automatic merging. It does not merge — it's not git.

Large binaries and databases sync poorly. Block-level diffing works well for text; a 4 GB virtual machine image that changes internally will transfer substantial data every time. Exclude VM disks, container volumes, and live database files.

No built-in Selective Sync on all platforms. You can ignore patterns per folder, but fine-grained "sync only these subdirectories" is less polished than commercial clients.

Discovery and relay leak metadata by default. Device IDs and IP addresses reach community servers unless you disable them.

Setup has a learning curve. Device IDs, folder IDs, and one-sided approval are not self-evident. Budget twenty minutes for the first pair.

8. What It Costs

| Item | Cost |
|---|---|
| Syncthing license | $0 (MPL-2.0, all platforms) |
| Server/NAS you already own | $0 |
| Storage | Whatever your disks cost |
| Bandwidth | Yours, no quota |
| Total | $0 marginal |

Compare with commercial options: Dropbox Plus runs roughly $12/month for 2 TB, and every tier caps storage and charges per user. Syncthing has no cap because there's nothing to cap — your storage is your disks.

The real cost is operational attention: you're now responsible for the availability of every device in your mesh, for versioning configuration, and for genuine backups. If a two-device mesh loses one device, your redundancy is gone and you may not notice.

9. Where Your Data Lives

The sovereignty story here is about as strong as software gets.

• Your files — on your devices, in plain files on ordinary filesystems. No proprietary container, no lock-in format. Uninstall Syncthing and your files are still there, readable.
• Transfer — TLS between your devices, authenticated by certificates.
• Metadata — folder names and device IDs are exchanged between your own devices.

What leaves your network if you accept defaults:

• Device ID + IP address → public discovery servers.
• Encrypted traffic volume → public relays, only when direct connection fails.

That's it. No file contents, no filenames, no folder structure reaches any third party. Disable public discovery and use static addressing or a VPN, and the answer becomes "nothing leaves."

Worth stating plainly: this is a materially different posture from any cloud sync product, where the vendor holds a decryptable or plain copy and can be compelled to produce it.

10. Syncthing vs Nextcloud vs Resilio vs Dropbox

| | Syncthing | Nextcloud | Resilio Sync | Dropbox |
|---|---|---|---|---|
| Model | Pure P2P | Self-hosted server hub | P2P (proprietary) | Cloud |
| License | MPL-2.0 | AGPL-3.0 | Proprietary | Proprietary |
| Needs a server | No | Yes | No | Yes (theirs) |
| Web editing/docs | No | Yes | No | Yes |
| Sharing with non-users | No | Yes | Via links | Yes |
| Mobile client | Community fork | Official | Official | Official |
| Setup difficulty | Medium | High | Low | Trivial |

The distinction that decides it: Syncthing synchronises; Nextcloud is a collaboration platform. If you need calendar, contacts, document editing, and external sharing, Syncthing is the wrong tool and Nextcloud is the right one. If you need your files replicated across your own machines with nobody in the middle, Syncthing is simpler, lighter, and more private.

Resilio is the closest commercial analogue and is easier to set up, but it's closed-source and its selective sync is superior — a genuine trade-off if you value convenience over auditability.

11. Who Should Not Use Syncthing

• You need cloud backup, not sync. Use Restic/Borg to real backup storage. Syncthing is not a backup.
• You need to share files with people outside your device mesh. There's no public link sharing. Use Nextcloud.
• You need Android as a first-class platform. The fork works, but it's a fork.
• You want zero configuration. Device pairing and folder IDs require attention.
• You need one device always online as a hub. You can do it, but Nextcloud is built for that shape.

12. Getting Started Sensibly

A safe first week:

1. Install on two machines. That's enough to learn the model.
2. Set a GUI password before anything else.
3. Sync one small, non-critical folder — a notes directory, not your photo archive.
4. Test the deletion behaviour deliberately: delete a test file on one side, watch it disappear on the other. Understand this before you trust the tool.
5. Only then add your real folders — and set the NAS or archive machine to Receive Only.
6. Enable Staggered versioning on that archive machine.
7. Add devices one at a time; a large mesh is harder to debug than a pair.
8. If privacy is the goal, disable public discovery and use Tailscale or Headscale for remote peers.

Ignoring the Right Things, and Keeping It Fast

Syncthing will happily try to synchronise anything you point it at, which is how people end up syncing .git object directories, node_modules, browser caches, and VM disk images. A few minutes of ignore patterns prevents hours of pointless transfer.

Create a .stignore file at the root of each shared folder:

// Dependencies and build artefacts
node_modules
.git/objects
__pycache__
target/

// Editor and OS noise

.DS_Store

Thumbs.db

.swp

~$

// Large binary blobs that diff badly

.iso

.vmdk

.qcow2

.vdi

// Live databases and VM state

.sqlite-wal

.sqlite-shm

/.config//lock

The ordering rule matters: later patterns override earlier ones, so a ! pattern can re-include something a previous line excluded. Test with the GUI — it shows which files are ignored and why.

Performance tuning for larger meshes:

• Set folder rescan intervals rather than relying purely on filesystem watching. A 60-second or 300-second interval on a large media library is far cheaper than continuous watching, and you rarely need instant propagation for photos.
• Limit the number of devices sharing a single folder. Traffic scales roughly with peer count; a folder shared across ten devices generates ten times the index chatter.
• Give it RAM on big folders. Indexing a multi-terabyte library with millions of files is memory-hungry; a small NAS with 512 MB will struggle.
• Use --home or separate instances if you need radically different resource profiles — a lean instance for documents, a beefier one for media.
• Enable untrusted device encryption if you ever sync to a device you don't fully control (a VPS, a friend's machine). Files are encrypted at rest on the remote side, so the operator sees ciphertext. You lose the ability to browse those files there, which is the point.

13. Mobile in 2026: The Official Android App Is Gone

If you install Syncthing on a phone today expecting the app you read about in a 2021 blog post, you are in for a confusing ten minutes. The official Android application was retired, and what the community actually runs now is a set of maintained forks — the one most people land on is Catfriend1's Syncthing-Fork, which is what you will find first on both F-Droid and the Play Store.

This sounds more alarming than it is, and it is worth being precise about why.

Syncthing is a protocol plus a reference implementation. The Android app is a wrapper around the same Go core, and that core is stable, versioned, and interoperable. A fork running a slightly different build of the daemon still speaks to an upstream Syncthing on your laptop without negotiation or downgrade. What changed is who fixes Android-specific bugs — battery optimisation, scoped storage, background service restrictions — and who publishes updates.

The fork is, in practice, a better Android client than the official app ever was. It adds rules that matter on a phone: sync only on Wi-Fi, only while charging, only on specific SSIDs, only above a battery threshold, and per-folder conditions rather than one global switch. It lets you keep the camera folder in send-only mode so photos flow out to your NAS and nothing ever flows back to fill the phone.

Two things will bite you.

Device IDs do not carry over. A fork is a new Syncthing identity. Your phone shows up as an unknown device asking to connect, and you have to accept it on every other node again. This is by design — the device ID derives from a per-installation key pair — but folder shares tied to the old ID are dead, and you re-create them.

Background sync on Android is a fight with the OS, not with Syncthing. Every vendor layer — MIUI, OxygenOS, Samsung's battery manager, and increasingly stock Android — will kill a long-running background service holding a socket open. If photos stop arriving the moment you leave the house, this is almost always the cause. The fix lives in the OEM's settings, not in Syncthing: exempt the app from battery optimisation, allow unrestricted data, and in some cases lock it in the recent-apps list.

One honest consequence: if your plan depends on a phone used by a non-technical family member whose battery settings you cannot touch, mobile sync will be unreliable in a way that has nothing to do with the protocol. Treat the always-on desktop nodes as the reliable tier and the phone as a convenience.

14. Untrusted Devices: Sync to a Machine You Don't Own

This is Syncthing's most underused feature, and it deserves to be understood properly, because it turns Syncthing from "sync between my machines" into "encrypted offsite copy with no third-party service in the middle."

Mark a remote device as Untrusted for a given folder and Syncthing encrypts every file's contents and every filename on your machine before a single byte leaves it. The remote peer receives and stores opaque ciphertext. It participates in the protocol — it holds blocks, it serves them back — but it cannot read what it holds.

In practice this means you can rent the cheapest VPS you can find, or drop a small box in a relative's garage, and use it as an offsite copy of your most important folder without that provider or that person being able to read anything. The encryption key lives in your folder configuration; without it the remote copy is noise.

What it does not do, and where people misjudge it:

The remote can still delete. Encryption protects confidentiality, not integrity. If someone with access to that machine deletes the ciphertext, or if your own machine faithfully syncs a deletion because you removed a file locally, the remote copy goes away. Untrusted is not a substitute for versioning. You want both: an untrusted peer for confidentiality, staggered file versioning on your own machine for recovery.

Some metadata remains visible. The remote cannot read names or contents, but it can observe that there are N encrypted objects, roughly how large they are, and when they change. For "my hosting provider shouldn't be able to read my tax returns," this is comfortably sufficient. For anything genuinely adversarial, use a purpose-built encrypted backup tool.

Renamed files look like new files. Because names are encrypted, a rename cannot be expressed as a rename. It becomes a delete plus a create, which means re-uploading that file's blocks. If you routinely reorganise large folders, an untrusted peer moves far more data than a trusted one.

Lose the key and the copy is gone. There is no recovery path. Export your configuration, or accept that this remote is a convenience tier and your real backup lives somewhere whose keys you have documented.

Set this up once, deliberately, and it quietly solves "offsite copy without trusting anyone" better than most products that charge monthly for the privilege.

15. Performance, Large Folders, and Why It Feels Slow at First

Syncthing's reputation for being slow comes almost entirely from two moments: the first scan of a large folder, and folders containing a very large number of small files. Neither is a bug, and both are manageable once you know what is actually happening.

The first scan is CPU-bound hashing. Before Syncthing can sync a file it has to know what it has, which means reading every file and computing block hashes. On a modern desktop with a few hundred gigabytes this is a background task measured in minutes to a couple of hours, during which your fans spin up and progress can look stalled. It is not stalled — it is hashing. Later scans are incremental and cheap, because the index database records sizes and modification times and only re-hashes what actually changed.

Many small files cost far more than few large ones. Every file carries per-file overhead: an index entry, a name, metadata, at least one block. A 50 GB folder containing 400,000 source files is dramatically harder than a 50 GB folder of two dozen disk images. If you are syncing a development tree, this is where your time goes — and the single biggest win is not tuning Syncthing, it is excluding the directories that never belonged in a sync at all.

Exclude aggressively, and do it before the first sync. .stignore is Syncthing's ignore file, and ten minutes spent on it before you share a folder saves an afternoon later. node_modules, target, .venv, __pycache__, build output, caches, editor swap files, and the operating system's own detritus — .DS_Store, Thumbs.db — are pure overhead. Get the patterns wrong in the other direction and you will wonder why your config folder is 4 GB.

There is a subtle trap: ignore patterns apply to future scans, but files already indexed and shared will not simply vanish from other devices. Add an ignore rule after syncing and peers keep holding files you have locally "disappeared." Write the ignore list first, then deal with stragglers.

File pull order is a real setting and it matters on a first sync. Under a folder's advanced options you can choose the order files are fetched: random, alphabetic, smallest first, largest first, oldest first, newest first. If you are restoring onto a fresh machine and want to use the data quickly rather than wait for completion, smallest-first or newest-first gets you a working subset far sooner than the default.

Watch for inotify limits on Linux. Syncthing uses filesystem notifications to pick up changes immediately. When there are more watched directories than the kernel permits, it silently falls back to periodic scanning and changes take up to the scan interval to appear. On a machine syncing many folders, raise fs.inotify.max_user_watches rather than wondering why edits take a minute to propagate.

Put the index database on fast storage. Syncthing's database lives in its configuration directory and is written to constantly. On a Raspberry Pi with everything on a microSD card, that card is your bottleneck and eventually your failure point. Moving the config directory — or at least the database — onto an SSD is the largest single performance and reliability improvement available on low-end hardware.

16. A Troubleshooting Playbook

Most Syncthing problems are one of six things, and all six announce themselves in the web UI if you know where to look.

"Out of Sync" on a folder. Open the folder and read the error beside the affected items. The overwhelming majority are permissions — the Syncthing process runs as a user that cannot write to the target path — or a file locked by a running program. On Linux, a container started as root writing into a directory owned by your user (or the reverse) produces this instantly. Fix ownership, not Syncthing.

Stuck at some percentage and not moving. Look at the remote device's status, not the folder. If it says "via relay," you are going through a relay server and throughput is limited by someone else's bandwidth. If it says "disconnected," you have a network problem: Syncthing needs TCP and UDP 22000 for sync traffic and UDP 21027 for local discovery. Symmetric NAT on both ends is the usual cause of permanent relaying, and the fix is a port forward or putting both machines on a mesh network like the one Headscale gives you.

"Unexpected items" on a send-only folder. A file changed on the receiving side. Syncthing is telling you, correctly, that the remote has diverged and it will not silently overwrite. Either override the remote changes if your copy is authoritative, or investigate — occasionally this is the first sign that two people are editing the same tree, which is a workflow problem rather than a sync problem.

Conflict files accumulating. notes.sync-conflict-20260910-130102.txt means both sides changed the same file while disconnected. Syncthing keeps both rather than guessing. This is correct behaviour and deeply annoying if you are syncing something both machines write to on a schedule — a note app's database, a browser profile, a virtual machine image. The fix is to stop syncing live databases, not to tune conflict handling.

Sync works but files are missing. Check .stignore on both ends. Ignore patterns are per-device, which is a powerful feature and a reliable source of "why is that folder empty on the laptop."

The database is corrupted. Power loss mid-write can do it. Syncthing usually detects and rebuilds; when it will not, stopping the service and starting once with a database reset forces a full re-index. It costs a complete re-scan and no data, because the index is derived state, not your files.

Every one of these is visible under Actions → Logs, with file and folder names that actually name the culprit.

17. Three Setups That Actually Work

Abstract advice is useless for a tool like this, so here are three topologies I would set up without hesitation, and one I would refuse.

Two machines and a phone. Your desktop and a laptop share a working folder in default send-and-receive mode. Your phone shares the camera directory in send-only mode, so photos flow to the desktop and nothing flows back. The desktop runs staggered versioning. Add a fourth device — a small always-on box at home — as a receive-only peer, and you have a three-copy arrangement where the always-on box holds the durable copy. This is what most people want, and it takes twenty minutes.

Encrypted offsite to a box you don't own. A cheap VPS or a machine at a relative's house, marked untrusted for one or two folders. Your home machine encrypts before sending; the remote holds ciphertext you would be comfortable publishing. Combine with versioning on the sending side, because the remote can still delete. This replaces a cloud backup subscription for anyone whose threat model is "my hosting provider shouldn't read my files" rather than "a state actor is after me."

Config distribution for a small ops team. One authoritative source machine shares a directory of configuration in send-only mode to a handful of servers configured receive-only. Changes propagate in seconds, there is no pipeline to maintain, and nobody can accidentally edit a config on a node and have it stick. This works precisely because the write path is single-directional.

The one I would refuse: two people concurrently editing the same tree of binary files. Syncthing will not corrupt your data, but it will generate conflict copies and confusion, and the failure mode is social — nobody knows which version is current. Two people editing the same text* files with a real merge tool is fine. Two people editing the same spreadsheet is not, and no amount of sync tuning fixes that.

18. Migrating Off Dropbox or Resilio: What Actually Changes

The transition is usually framed as a feature comparison, which misses the point. What changes is who is responsible.

Dropbox gives you a namespace that exists independently of your devices. You can log into a web UI on a borrowed computer and get your files. With Syncthing, the files exist on your machines; there is no canonical copy in the sky, and if every device is off, nothing is available. For a decade of Dropbox muscle memory this is the adjustment that takes longest. If you genuinely need always-available web access from arbitrary machines, Syncthing is the wrong tool and you should be looking at Nextcloud instead.

Resilio Sync users have the reverse problem: it looks nearly identical, and the differences live in the details. Resilio's free tier is feature-limited and its selective sync is more polished; Syncthing is fully featured for free, and its ignore patterns are more expressive but need to be learned. Both are peer-to-peer. The reason most people move is licensing and trust — Syncthing's entire implementation is open and auditable, which matters the moment you are syncing anything you would not want read.

Practically, the migration that works is: run both in parallel for a week, on one folder. Pick your smallest, least critical shared folder, sync it with Syncthing, keep Dropbox running, and live with it until you have hit one conflict, one ignore-pattern mistake, and one "oh, the laptop was asleep" moment. All three will happen, all three are fixable, and you would far rather meet them on throwaway data. Then move the folder that actually matters.

What you gain at the end is not a feature. It is the absence of a company that can read, lose, or revoke access to your files — and the presence of a small maintenance obligation you now own instead.

19. The Verdict

Syncthing is one of the few pieces of software where the privacy claim isn't marketing — it's architecture. There is no server, so there is no server operator. Your files exist on hardware you control, move over encrypted connections you authenticate, and are stored in a format you can read without Syncthing's help.

Twelve years of continuous development, a non-profit foundation, MPL-2.0 licensing, and 88,000 stars make it about as safe a bet as self-hosted software gets. The block-level transfer makes it fast; the folder modes make it safe once you understand them.

The caveats are honest and manageable: sync is not backup, the Android client is a community fork, conflict handling creates files rather than merging, and large binary files are a poor fit. Learn those four things before you trust it with anything irreplaceable.

If you've ever looked at a cloud sync subscription and thought "why am I paying rent on my own files," this is the answer — and unlike most answers in this space, it costs nothing and asks nothing of you except a little attention.

Related

• Headscale: The Open-Source Tailscale Control Server That Puts Your Mesh VPN Back in Your Hands — the cleanest way to connect remote Syncthing peers without public discovery.
• Immich: The Self-Hosted Google Photos Alternative That Keeps Your Memories on Your Own Disk — pair the two: Syncthing gets photos onto your server, Immich organises them.
• RustDesk: The Open-Source Remote Desktop That Lets You Own the Relay Server — same "own the relay" philosophy, applied to remote access instead of files.