MeshHold vs Syncthing vs Resilio Sync

The other P2P sync tools — where storing a vault beats syncing a folder, and where twelve years of Syncthing wins.

Neither Syncthing nor Resilio publishes a comparison table, so unlike the ownCloud page there is no competitor's row set to answer. These rows are ours, which is the weaker position to argue from — so where a row is a matter of design rather than capability, it says so, and the section that matters most to Syncthing users is Maturity, where MeshHold loses outright.

All three agree on the premise. No central server, no account, no vendor holding your files; devices find each other and talk directly. Everything interesting is downstream of that agreement, and almost all of it follows from one difference:

Syncthing and Resilio synchronise folders. MeshHold stores a vault. A device sharing a Syncthing folder holds every file in it that isn't excluded by an ignore pattern — the folder on disk is the state. A MeshHold vault is a set of content-addressed encrypted blocks; a device holds as much or as little of it as it wants, and the default on a phone is none of it, just the file list.

That is why MeshHold can put a vault on a VPS that cannot read it, spread one file across several disks, and show you 2 TB of files on a 128 GB phone — and also why it is a heavier, younger, more complicated thing than Syncthing, which does one job and has done it well since 2013.

Notes

1. Resilio's download page now carries an explicit warning that "Sync is for personal, non-commercial purposes only", alongside the news that the free build includes everything that used to be Sync Pro. So it became more generous and more restricted at the same time: excellent for a household, unusable at a company, where the answer is the separate Resilio Connect product with sales-quoted pricing.
2. Nodes gossip their view of the mesh over /meshhold/hello/1.0; one successful handshake returns every other node currently online, any of which can be the next bootstrap. There is no discovery service to operate or query — which also means a brand-new node needs some reachable peer to start from, where Syncthing's global discovery will find one for you.
3. Syncthing's own security documentation is candid here: a global discovery operator "can map arbitrary device addresses to IP addresses, and deduce which devices are connected to each other". Relays learn device IDs but never plaintext. Global discovery is optional and can be turned off or self-hosted.
4. Every file is encrypted with a key derived from its own plaintext, and the ciphertext is chunked into SHA-256-addressed blocks. Identical input gives identical ciphertext, so duplicate data is stored once across every file and every vault on the node — and an interrupted transfer resumes rather than restarts. See Core Concepts.
5. This is a design decision, not an omission. Syncthing's stated goal is that the folder on disk is the truth and any other program can read it with no awareness of Syncthing at all. That property is worth a great deal, and MeshHold's blocks-mode vaults do not have it — which is exactly why MeshHold also supports folder-backed vaults with a storage_path, where the plaintext directory is the source of truth and you give up dedup, pooling and cheap history in exchange.
6. A vault's usable space is the sum of its trusted nodes' free disk. Write through a full node and the blocks land on a peer that has room; the node you wrote through still lists and serves the file. A file too large for any single node is split into contiguous shards placed on different nodes. No folder-synchroniser can do this, because a folder has to exist somewhere in one piece.
7. Encryption happens on the device before anything replicates, so a peer holding your blocks without the vault key is the normal case rather than a special mode — that is what makes a €5 VPS usable as redundancy. The trade-off is real and belongs in the table: because the key comes from the plaintext, someone holding a candidate file can test whether you stored it. Syncthing's password-derived scheme has no such property. If "prove this person does not have file X" is your threat model, Syncthing's design is the safer one.
8. Syncthing's untrusted (encrypted) devices are real and well-built — XChaCha20-Poly1305 and AES-SIV keyed by scrypt over a folder password, with full paths encrypted. Two caveats keep it a partial here: the documentation still labels it "beta / testing only", and folder IDs, labels and approximate file sizes remain visible to the untrusted device.
9. A vault or chat's key can be wrapped under an Argon2id password, so until someone types it the node holds ciphertext it cannot read — and with hide when locked set, the vault is not listed at all. One password unlocks every locked vault at once. Offered only on streaming-only vaults, since a vault with a storage_path writes plaintext to disk and would defeat it.
10. Each version carries a parent_hash to the previous one, so the same file edited on two nodes at once is detected as a fork on the next gossip round rather than silently resolved. Whether old versions stay restorable is a per-node decision (keep_history), so a phone can stream, a laptop hold a plain copy, and a NAS keep the deep history — of the same vault.
11. Worth understanding before relying on it: Syncthing's versioning fires on changes received from other devices, and the .stversions archive is local to each device and never synced. Edit a file on your laptop and the laptop keeps no previous copy. It is a safety net against a bad sync, not a replicated history. MeshHold's versions are blocks like any other and replicate under the vault's replication factor — but because MeshHold versions blocks rather than files, a small edit to a large file costs one changed block, not another full copy.
12. Neither model is good here. MeshHold has named, expiring, revocable keys per node for tunnels and mesh networks, but a vault key is shared among everyone who holds it, so cutting off one holder means re-keying the vault. Syncthing is cleanly better: delete the device ID and that device is gone, with no effect on anyone else. Resilio is closer to MeshHold — the folder secret is the access, so revocation means a new secret.
13. Syncthing is twelve years old, has an enormous install base, and its sync engine is the reference other implementations are checked against. That is not a row MeshHold can win by argument, and treating it as a minor line item would be dishonest: if all you need is two folders staying identical, Syncthing is the lower-risk answer and probably the right one.

14. The official Syncthing Android app was discontinued at the end of 2024; Syncthing-Fork is the actively-maintained community continuation on F-Droid and Play. On iOS the only maintained client is Möbius Sync, a paid third-party app. Both work well — they just are not the project's own.

    MeshHold's own platform coverage is narrower than either. It ships a first-party Android app, and no macOS build at all — not an app, not a daemon, not a tarball. The tree carries darwin build-tagged files for the tray, keystore and autostart, so the source would compile, but nothing is built or published for it and the updater has no macOS artifacts to offer. There is no iOS client either. If your household runs on Macs and iPhones, Syncthing and Resilio both work today and MeshHold does not.

15. This is about the node's own state, not the shared blocks: the metadata store, the libp2p identity, and the swarm key. MeshHold wraps them with a key held by the OS (DPAPI, Keychain, Secret Service, Android Keystore) or by a secret you manage, and a node created today does it without being asked. Syncthing and Resilio keep the equivalent -- device keys, folder keys, config -- as ordinary files, so anything that can read the config directory can read them. It matters most on a shared or backed-up machine, and it is orthogonal to how the synced files are protected.

16. A view of a vault rather than a separate application. It reads each picture's own EXIF on the node holding it and groups by the day the shutter fired, not by the file's modification time -- which for a photograph is usually the day it was copied off a phone, and would file a whole holiday under today. Not a comparison Syncthing or Resilio would accept as fair: neither is trying to be a photo application, and a folder they sync opens in whatever the operating system already has. It is on the table because "the pictures are already synced, now what looks at them" is a question those two answer with "something else, that you also install". HEIC and raw files show as icons -- no decoder ships in a cgo-free build -- and there is no grouping by place, because that would mean sending the coordinates somewhere.

Which one to pick

Syncthing if you want two or more folders to stay identical and nothing else. It is smaller, older, better understood, and its folders are ordinary directories that every other program on the machine can read without knowing Syncthing exists. Reach for it first, and only leave it when you hit something it structurally cannot do.

Resilio Sync if you want that plus placeholder-based selective sync, first-party iOS, and packages in your NAS vendor's app store — and your use is personal. Read note 1 before deploying it at work.

MeshHold when the folder model itself is the constraint: when your phone should browse a library bigger than its disk, when a rented VPS should hold redundancy it cannot read, when one file is larger than any disk you own, when history has to survive the device that made it, or when you would rather the sync, the VPN, the S3 endpoint, the chat and the media player were one daemon than five. It is younger and more complex than Syncthing, and the table above is meant to make it obvious when that complexity is buying you nothing.

Start with The Personal Cloud, or Core Concepts for the vocabulary.