Tech Digest

Photos and files

Syncthing

Continuous peer-to-peer file sync between your own devices, with no server and no account

Photos and filesMPL-2.0Maturearm64 builds
Last reviewed Profile maintained against the project's own documentation
Operational load
1 / 5
Set and forget
Idle memory
60 MB
typical use ~300 MB
Moving parts
1
containers in a normal deployment
Backup shape
SQLite backup
needs a dump or a stop

Syncthing keeps folders identical across two or more devices by talking directly between them over an encrypted connection, with no central server and no account anywhere. It replaces Dropbox for the narrow job of keeping the same files on several machines you own.

Our verdict on Syncthing#

Syncthing is not backup and it is not a server product, and both mistakes cost people data. The FAQ says it outright: every change, including deletions, propagates to all your devices. Delete a folder on your laptop and it is gone from the NAS within seconds, exactly as designed. It also has no server: every device is a peer holding a full copy, so there is no central instance to point clients at and no admin console over the fleet. Version 2.0 (12 August 2025) replaced LevelDB with SQLite, which migrates on first launch and can take a long while on large setups. Two behavior changes in that release matter operationally: deleted items are now forgotten after six months instead of being kept forever (--db-delete-retention-interval), and no default folder is created on first start. The official Android app was discontinued in December 2024; Syncthing-Fork is what people actually run.

Who Syncthing is for#

Choose it if

  • Keeping one working directory identical across a laptop, a desktop and a NAS with no cloud in the path
  • Moving phone camera photos onto a home server as a one-way, receive-only folder
  • Anyone who wants sync without operating a server, a database or a certificate
  • Networks where the devices are frequently on the same LAN and can sync at full link speed

Look elsewhere if

  • You want backup: a mistake replicates instantly and versioning is a convenience, not a recovery plan
  • You need web access, sharing links, or accounts for people who are not you
  • You expect a central server to be authoritative; every peer is equal and any of them can propagate a destructive change

What running it actually looks like#

One binary or one container per device, that is the whole architecture. It listens on 22000/TCP and 22000/UDP for QUIC sync traffic, broadcasts local discovery on 21027/UDP, and serves the GUI on 127.0.0.1:8384. Devices are paired by exchanging device IDs and accepting on both sides; folders are then shared by ID. The GUI binds to localhost by default, so remote access means changing the listen address and putting real authentication in front of it. Nothing has to exist before it starts: no database, no certificate you provision, no DNS. Since 2.0 no default ~/Sync folder is created either. Upgrading from 1.x runs a one-time LevelDB to SQLite migration on first launch, which on a large index is a wait, not a blip.

Resource profile#

Memory
60 MB idle, around 300 MB in ordinary use. Memory scales with the number of files tracked, not their size; the 2.0 move to SQLite lowered resident memory for large folders. Figures are estimates from typical single-user setups, not documented minimums.
CPU and acceleration
Idles near zero between changes; scans and the initial index hash every file, so the first sync of a large folder is disk and CPU bound for a while. Rolling-hash detection of shifted data was removed in 2.0, which made scans faster.
Storage growth
Each device holds a full copy of every folder it shares, so total storage is copies times devices; file versioning and `.stversions/` add more on top and are not pruned unless you configure a versioning policy.
Operational load
1 of 5, Set and forget. One process per device, no database service, no reverse proxy required, and the config is a single XML file plus the local database. The attention it costs is not upgrades, it is understanding the conflict and deletion semantics before you trust it.

Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.

Data and backup surface#

Two separate things. Your synced folders are ordinary files on ordinary filesystems, so back them up with whatever you already use; there is no export step and no proprietary container. Syncthing's own state lives in its config directory (~/.local/state/syncthing or /var/lib/syncthing on Linux, /var/syncthing in the container): config.xml, the device certificate and key, and the SQLite index database. Keep config.xml and the key pair, because losing them changes your device ID and forces you to re-pair every peer. The index database is regenerable at the cost of a full rescan. .stversions/ inside each folder holds versioned copies and is worth excluding or pruning.

Derived backup shape

SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.

Traps and surprises#

Deletions propagate, and that is the design

Syncthing replicates deletions to every device sharing the folder. The FAQ states plainly that it is not a good backup application because all changes, modifications and deletions included, reach all your devices. A ransomware run or a mistaken rm -rf on one machine reaches the NAS before you notice. The mitigations are a receive-only folder on the archival device, file versioning with a real retention policy, and a genuine backup that Syncthing does not touch.

Conflicts create files, they do not merge

When the same file is edited on two devices between syncs, Syncthing keeps one and renames the other to filename.sync-conflict-<date>-<time>-<deviceid>.ext. Nothing merges and nothing warns you in normal use, so the conflict copies pile up silently in the folder and get synced everywhere. Grep for sync-conflict periodically. For databases, note-taking apps and anything with an open write handle, this is a corruption source rather than a merge strategy.

The 2.0 database migration is one-way

Version 2.0 (August 2025) replaced LevelDB with SQLite and migrates the index on first launch, which is lengthy for large setups. Plan for downtime on the device with the biggest folders and do not interrupt it. Prebuilt binaries also stopped being published for several platforms at the same time, including DragonFly BSD, illumos, Solaris, linux/ppc64, NetBSD and windows/arm, so check your architecture before upgrading.

Deleted items are only remembered for six months

Since 2.0, tombstones for deleted files are dropped after six months rather than kept forever, controlled by --db-delete-retention-interval. If a device has been offline longer than that and rejoins, files it still holds and the cluster deleted can reappear as new files. For devices that hibernate for long periods, either raise the interval or accept that a very stale peer may resurrect old data.

The GUI is localhost-only with one password

The GUI listens on 127.0.0.1:8384 by default and has a single local username and password, no OIDC, no accounts, no roles. Anyone who reaches it can add device IDs, change folder paths and delete folders across your cluster. If you move it off localhost, terminate TLS and authenticate at a reverse proxy. Do not port-forward 8384 to the internet as a convenience.

Specifications#

Category
Photos, files and sync
Licence
MPL-2.0 (Copyleft)
Written in
Go
First release
2014
Maturity
Mature
Datastore
SQLite since 2.0 (LevelDB before that), local to each device
Default ports
8384, 22000, 21027
Ships as
native binary, docker, deb/rpm package, homebrew, android (community builds)
arm64 builds
Yes
Identity
Local accounts only. The web GUI has a single local username and password and no identity integration; if you expose it, put an authenticating proxy in front of 8384.
Replaces
Dropbox, Resilio Sync, Google Drive desktop sync, BitTorrent Sync
Project site
syncthing.net
Source
github.com/syncthing/syncthing
Documentation
docs.syncthing.net

Alternatives to Syncthing#

Everything else in photos, files and sync, closest in operational weight first.

ToolOps loadIdle RAMLicence
File Browser1, Set and forget20 MBApache-2.0
PhotoPrism2, Light450 MBAGPL-3.0 (Community Edition); default images ship under the PhotoPrism Plus License
Immich3, Moderate900 MBAGPL-3.0
Seafile3, Moderate700 MBGPL-2.0 with an OpenSSL linking exception (server, Community Edition); Professional Edition is proprietary
Nextcloud4, Heavy600 MBAGPL-3.0-or-later

Where Syncthing comes up elsewhere#

Sources#

Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.