How to Manage Multiple Devices and Folders in Syncthing: Topology, Naming, and Versioning

Syncthing Series

Once Syncthing has many devices and many folders, it can quickly become messy if you do not plan ahead. The typical setup is a phone, tablet, laptop, desktop, and NAS all syncing at once, while folders contain photos, work documents, code projects, chat backups, and ebooks. Every device may modify files, every folder may be shared, and eventually it becomes hard to tell where a file came from and where it will sync next.

To keep Syncthing stable, the core is not installing more clients, but building a management model:

Use a star topology.
Standardize folder IDs and paths.
Use introducers for device relationships.
Separate backups from two-way sync by data direction.
Enable versioning on the central node.
Filter temporary files with ignore patterns.

Topology: Avoid Full Mesh, Prefer Star

Syncthing is a P2P architecture, but that does not mean every device should pair with every other device.

If 5 devices are fully connected, you need to maintain 10 device relationships. When you add a new folder, you also need to accept it, set paths, and confirm sharing across multiple devices. The more devices you have, the higher the management cost.

A star topology is usually better.

Choose one always-on, spacious, and stable device as the hub:

NAS
Synology
soft router
mini PC
a computer that stays on 24/7

All other devices pair only with the hub:

1
2
3
4


Phone ----\
Tablet ----\
Laptop ---- NAS
Desktop ---/

The phone does not directly add the laptop, and the laptop does not directly add the desktop. If the phone needs to sync photos to a computer, it syncs to the NAS first, then the NAS syncs them to the computer.

This has several benefits:

New devices only need to pair with the NAS.
Folder relationships are managed centrally on the NAS.
The NAS can handle version retention consistently.
When edge devices go offline, the NAS still acts as a buffer.

The tradeoff is that the NAS becomes more important. It should run reliably and have its own backup.

Folder ID Matters More Than the Folder Label

In Syncthing, the real identifier for a synchronized folder is the Folder ID, not the label you see in the UI.

The label is just a display name and may differ across devices. The Folder ID is what determines whether folders on different devices belong to the same sync group.

When creating a folder on the first device, specify a clean ID manually.

For example:

1
2
3
4
5
6


notes-main
work-docs
backup-pixel-photos
backup-iphone-photos
media-ebooks
code-projects

Avoid random generated IDs or long-term-unfriendly names such as test, sync, and new-folder.

A simple naming rule is enough:

Two-way sync: notes-main, work-docs
Phone backups: backup-pixel-photos, backup-iphone-photos
Media distribution: media-ebooks, media-music
Code directories: code-projects

Later, when other devices receive a shared folder, the Folder ID tells you immediately what the folder is for.

Keep Hub Paths Organized

On the NAS or central computer, create one dedicated Syncthing root directory.

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


/volume1/Syncthing/
├── Phone_Backup/
│   ├── iPhone15_DCIM/
│   └── Pixel7_DCIM/
├── Work/
│   ├── Office_Docs/
│   └── Coding_Projects/
├── Notes/
│   └── Main_Notes/
└── Media/
    └── eBooks/

Do not scatter sync folders across the system. Scattered paths may feel convenient at first, but they become difficult to maintain.

Recommended rules:

Put all Syncthing-managed folders under one root directory.
Separate phone backups, work documents, and media files into clear sections.
Let folder names reflect purpose, not temporary device state.
Do not use system directories or download caches as long-term sync folders.

If Syncthing runs in Docker, also pay attention to the mapping between host paths and container paths.

For example, the host path:

1

/volume1/Syncthing/Phone_Backup/iPhone15_DCIM

may be mounted inside the container as:

1

/var/syncthing/Phone_Backup/iPhone15_DCIM

The path entered in the Web UI is the container path, not the host path.

Introducers: Reduce Multi-device Pairing Work

Syncthing’s Introducer feature is well suited to star topologies.

The idea is to make the NAS an introducer. After that, a new device only needs to pair with the NAS. The NAS can introduce known devices and sharing relationships to the new device, reducing repeated scanning and manual adding across devices.

It works well when:

your home has multiple computers and phones;
the NAS is the long-running hub;
you often add new devices;
you want to reduce pairing work.

But do not use it casually.

Recommended practice:

Only set the NAS or main server as an introducer.
Do not set ordinary phones, tablets, or temporary computers as introducers.
After a new device joins, check which devices and folders were added automatically.
Do not bring untrusted devices into the introducer-managed network.

Introducers improve efficiency, but they also expand automatic relationships. They are best for a clear hub-based network, not a messy temporary device environment.

Separate Backups from Two-way Sync

In multi-folder management, one of the most important rules is: do not use Send & Receive for every folder.

Different folders have different data directions.

Phone Photo Backup

Phone side:

1

Send Only

NAS side:

1

Receive Only

The phone sends photos and the NAS receives them. Cleaning phone storage or organizing the NAS folder is less likely to affect the other side.

Multi-device Documents and Notes

Computer side:

1

Send & Receive

NAS side:

1

Send & Receive

Whether the phone joins this two-way sync depends on whether you truly edit these files on the phone. If the phone only reads them, consider Receive Only.

Media Distribution

NAS side:

1

Send Only

Other devices:

1

Receive Only

This is suitable for ebooks, installers, and reference material distributed from a central folder.

Backup Directories

Primary device:

1

Send Only

Backup machine:

1

Receive Only

Then combine it with versioning or snapshots on the backup side.

Enable File Versioning on the NAS

The biggest risks in multi-device sync are accidental deletion and accidental overwrite.

For example:

A computer deletes work documents by mistake.
A phone cleanup tool removes an album directory.
Two devices edit the same note at the same time.
A sync rule is misconfigured and an empty directory is synced over.

Because of this, the central node should enable file versioning.

In the NAS Syncthing Web UI:

Open the target folder settings.
Go to file versioning.
Choose a suitable versioning strategy.

A common choice is Staggered File Versioning. It keeps historical versions by time intervals, retaining older versions more sparsely over time.

You can also use simpler strategies:

Trash Can File Versioning: similar to a recycle bin.
Simple File Versioning: keeps a fixed number of versions.
Staggered File Versioning: keeps versions by time stages.

If you are not sure which to choose, a home NAS can start with Trash Can or Staggered.

Versioning is not a full backup, but it is the undo button you want in multi-device sync.

Filter Temporary Files with Ignore Patterns

When syncing code projects, document folders, or chat backups across many devices, temporary files and caches can create noise.

Common problems include:

wasting bandwidth;
generating meaningless conflicts;
creating different cache files on different operating systems;
blocking directory deletion because ignored files remain.

Add rules in the folder’s Ignore Patterns.

Common temporary files:

1
2
3


(?d).DS_Store
(?d)Thumbs.db
(?d)*~

Node / Python / Java projects:

1
2
3
4


(?d)node_modules/
(?d)__pycache__/
(?d).pytest_cache/
(?d)target/

If a code project is already managed by Git, it is usually not recommended to sync the .git directory with Syncthing. You can ignore it:

1

(?d).git/

(?d) means that if the whole directory is going to be deleted, Syncthing may delete these locally generated ignored files as well, preventing leftover cache files from blocking the deletion.

Do not make ignore rules too complex at once. Start with obvious caches and temporary files, then adjust slowly according to real conflicts.

Multi-folder Naming Examples

You can use a fixed naming scheme.

Phone photos:

1
2
3


Folder ID: backup-pixel-photos
Label: Pixel Photos
NAS Path: /volume1/Syncthing/Phone_Backup/Pixel7_DCIM

iPhone photos:

1
2
3


Folder ID: backup-iphone-photos
Label: iPhone Photos
NAS Path: /volume1/Syncthing/Phone_Backup/iPhone15_DCIM

Main notes vault:

1
2
3


Folder ID: notes-main
Label: Main Notes
NAS Path: /volume1/Syncthing/Notes/Main_Notes

Work documents:

1
2
3


Folder ID: work-docs
Label: Work Docs
NAS Path: /volume1/Syncthing/Work/Office_Docs

Ebooks:

1
2
3


Folder ID: media-ebooks
Label: eBooks
NAS Path: /volume1/Syncthing/Media/eBooks

As long as IDs, labels, and paths follow rules, multi-device setups are much easier to control.

Recommended Overall Design

If you already run Docker Syncthing on a NAS, you can design it like this:

Use the NAS as the hub.
Set the NAS as the introducer.
Pair all devices only with the NAS.
Put all sync folders under /volume1/Syncthing/.
Use phone Send Only and NAS Receive Only for photo folders.
Use Send & Receive for work documents and notes.
Use NAS Send Only and other devices Receive Only for distribution folders.
Enable versioning for important folders on the NAS.
Configure ignore rules for code and cache directories.
Back up or snapshot the NAS itself.

Once this structure is in place, adding new devices or folders simply means putting them into the existing rules. You do not need to rethink the sync relationships every time.

Summary

Syncthing gives you a lot of freedom, but the more freedom you have, the more you need rules.

For multi-device and multi-folder setups, avoid a fully connected mesh. A steadier approach is to let a NAS or always-on computer act as the hub, then standardize Folder IDs, paths, and versioning. Use folder types to distinguish backups, two-way sync, and distribution folders.

This keeps Syncthing’s P2P capability while bringing day-to-day management back to one central device. Even with many devices and many folders, the sync system will not turn into a tangle.