Technical Docs

How to Use Syncthing: Practical Notes from Device Pairing to File Sync

A practical guide to Syncthing based on the official documentation: device IDs, folder sharing, folder types, firewall ports, ignore rules, file versioning, security boundaries, and what to watch for when syncing between NAS, Windows, and Android devices.

Syncthing Series

Syncthing is well suited for peer-to-peer file synchronization between multiple devices. It is not a traditional cloud drive, and it does not first upload all data to a central server before downloading it elsewhere. Instead, authorized devices exchange files directly.

If you are considering it for Markdown notes, photo backup, configuration files, or a home NAS directory, the first question is not just whether it can sync. You should first understand devices, folders, device IDs, sync direction, discovery, and conflict handling.

What Syncthing Solves

Syncthing is designed for one core scenario: you have two or more devices and want a directory to stay consistent across them.

Typical examples include:

  • Syncing work files between a Windows desktop and laptop.
  • Syncing photos or documents between a phone and NAS.
  • Syncing small scripts, examples, or configuration notes between Linux servers.
  • Keeping Obsidian notes, Joplin attachments, or Markdown folders available on several devices.

It is better for cases where you control the devices and the data. If you need team permissions, web previews, sharing links, or collaborative editing, a conventional cloud drive or document platform may fit better.

What Happens on First Start

The official getting started guide suggests configuring two machines side by side. In Syncthing, each machine is a device. The machine you are configuring is the local device, while the other machine is a remote device.

On first start, Syncthing creates its configuration, cryptographic keys, and device ID. It also opens the local Web GUI by default:

1

http://127.0.0.1:8384/

The Web GUI is the everyday configuration interface. Syncthing may also create a default folder, usually a Sync directory under your user profile. You can use it for testing, or remove it later and add your own folders.

Device ID Is the Basis of Pairing

Syncthing pairs devices through device IDs.

Each device creates its own key on first start. The device ID is a readable fingerprint of that device certificate. Two devices only establish a sync relationship after they have added each other’s device ID.

A typical flow is:

  1. Start Syncthing on both devices.
  2. Open the Web GUI on both sides.
  3. Add device B’s device ID on device A.
  4. Add device A’s device ID on device B.
  5. Choose which folders to share.
  6. Save and wait for the connection.

The device ID does not need to be protected like a password, but you should not publish your sync topology unnecessarily. The things that really need protection are the device private key, Web GUI access, and the synced folders themselves.

Syncthing Does Not Sync the Whole Machine

Syncthing only syncs folders that you explicitly add. It does not sync an entire device by default.

Each folder has its own path, ID, shared devices, and folder type. It is usually better to separate folders by purpose:

  • notes/: Markdown notes.
  • photos-inbox/: phone photo intake.
  • docs/: documents shared across devices.
  • scripts/: scripts and configuration examples.

Do not start by syncing huge system directories, download directories, or mixed folders. The more complex the directory, the more likely conflicts, ignore rules, permissions, and scan cost will become long-term problems.

Three Common Folder Types

The official documentation explains folder types clearly. In practice, you mainly need to understand these three.

Send & Receive

This is the default mode. The folder sends local changes and receives remote changes.

It fits:

  • Editing notes across several devices.
  • Maintaining documents on multiple devices.
  • Normal two-way synchronization.

If two devices modify the same file at the same time, Syncthing creates a conflict file instead of silently overwriting one side.

Send Only

This mode treats the local folder as the reference copy. It sends changes to other devices, but does not apply changes from them.

It fits:

  • A primary device distributing files to backup devices.
  • Cases where one machine should be authoritative.
  • Situations where remote changes should not affect the local folder.

If remote changes appear, the local device may show the folder as out of sync. The Web GUI can then offer Override Changes, which pushes the local state to the rest of the cluster. Use that button carefully.

Receive Only

This is the opposite of Send Only. The folder receives cluster changes, but local changes are not sent to other devices.

It fits:

  • Backup targets.
  • Read-only mirrors.
  • Devices where local mistakes should not pollute the main sync set.

If local changes appear, the Web GUI may offer Revert Local Changes to return the folder to the cluster state.

Check Firewall and Ports First

Syncthing can use discovery, NAT traversal, and relays, but connections are more stable when the network is understood.

The important ports listed in the official firewall guide are:

1
2
3

22000/TCP
22000/UDP
21027/UDP

Where:

  • 22000/TCP is used for TCP sync traffic.
  • 22000/UDP is used for QUIC sync traffic.
  • 21027/UDP is used for local discovery.

If devices are on the same LAN but cannot discover each other, first check local firewalls, router isolation, and whether Wi-Fi and wired networks are on different segments.

Across the internet or NAT, direct connections are usually faster than relays when port forwarding is possible. Without port forwarding, relays can still help devices connect, but performance is often worse.

On Linux with ufw and the corresponding application profile installed, you can use:

1
2

sudo ufw allow syncthing
sudo ufw status verbose

The Web GUI listens on 127.0.0.1:8384 by default. If you change it to 0.0.0.0:8384, the management interface becomes reachable from outside the machine. At that point you must think about passwords, HTTPS, reverse proxies, or SSH tunnels. For home use, an SSH tunnel is usually safer.

.stignore Belongs in the Sync Root

If some files should not sync, create a .stignore file in the root of the synced folder.

Important details:

  • .stignore must be in the root of the synced folder.
  • Rules are relative to that root.
  • .stignore itself is not synced to other devices.
  • The file should use UTF-8.

A simple example:

1
2
3
4
5

(?d).DS_Store
node_modules
*.tmp
cache/**
!/cache/keep.txt

(?d) means Syncthing may delete those ignored files when they would otherwise prevent a directory deletion. It is useful for generated files such as .DS_Store.

The exclamation mark ! negates a rule and includes a file again. Complex negative rules can make Syncthing scan directories that would otherwise be ignored, so start with simple patterns.

File Versioning Is Not Local Undo

Syncthing supports file versioning, but its meaning is easy to misunderstand.

The official documentation emphasizes that versioning stores the old local version when a remote change replaces it. If B modifies a file and syncs it to A, A can keep the replaced version. But if A edits a file locally, Syncthing cannot preserve A’s previous version before the edit.

Common versioning strategies include:

  • Trash Can File Versioning: move replaced or deleted files into .stversions.
  • Simple File Versioning: keep a fixed number of versions.
  • Staggered File Versioning: keep dense recent versions and sparser older versions.
  • External File Versioning: hand version handling to a script.

For important documents, enable at least simple or trash-can versioning on the backup target. It is not a full backup system, but it reduces the damage from accidental deletion or overwrite.

How Conflicts Happen

Syncthing detects conflicts. If two devices change the same file differently at the same time, it may create a conflict file such as:

1

filename.sync-conflict-date-time-modifiedBy.ext

This is safer than silent overwrite, but you still need to clean up conflict files.

Common conflict sources:

  • Opening the same Markdown note on multiple devices at once.
  • Applications automatically writing the same state file.
  • Syncing device-specific files such as .obsidian/workspace.json.
  • Case-sensitive and case-insensitive filename differences across Windows, macOS, and Android.

For notes, sync the text, attachments, and templates first. Be careful with workspace state, caches, and plugin temporary files; put them in .stignore when needed.

Security Boundaries

One of Syncthing’s security goals is that unauthorized devices cannot join the sync cluster and passive observers cannot read file contents in transit.

The security documentation explains that traffic between devices is protected by TLS, and peers verify that the device certificate fingerprint is in the allowed list. In practice, devices only sync after both sides are configured with the correct device IDs.

That does not mean Syncthing usage is invisible:

  • Global discovery announces device IDs and listening addresses.
  • Local discovery broadcasts on the LAN.
  • Relay servers can see device IDs, though they cannot decrypt synced data.
  • An exposed Web GUI reveals that the machine is running Syncthing.

Practical security advice:

  • Do not expose the Web GUI to the public internet unless authentication and encryption are properly configured.
  • Only add devices you trust.
  • Use disk encryption or separate backups for important folders.
  • Disable global discovery, relays, or auto-upgrade if your environment requires it, while accepting the loss of convenience.

Untrusted Encrypted Devices

Syncthing also supports untrusted encrypted devices. This lets an untrusted device store encrypted data only.

A typical use case is a cloud server or external machine that participates in sync or backup but should not see plaintext. Trusted devices encrypt data with a folder password before sending it; other trusted devices with the same password can sync and decrypt it.

The official documentation still treats this feature as beta/testing. It is useful for specific needs, but not the simplest starting point.

Remember:

  • File data, names, timestamps, hashes, and directory structure are protected.
  • Folder ID, label, and approximate file sizes are not fully hidden.
  • The password and folder ID must be kept safely.
  • The folder type on the untrusted device should be Receive Encrypted.

For a normal home NAS, your own computers, and phones, trusted-device sync plus system login security, disk encryption, and backups is usually easier to maintain.

Practical Configuration Advice

If you plan to use Syncthing for notes or documents long term:

  1. Create separate folders by data type. Do not use one giant mixed folder.
  2. Use Send & Receive on primary computers.
  3. Consider Receive Only plus file versioning on a NAS or backup machine.
  4. On phones, sync only the directories you need.
  5. Use .stignore for caches, temporary files, and workspace state.
  6. Make sure 22000/TCP, 22000/UDP, and 21027/UDP work on the LAN.
  7. Keep the Web GUI local when possible; use SSH tunnels or VPN for remote access.
  8. Do not treat sync as the only backup for important data.

Deploy Syncthing on Synology DSM

Preparation

First, sign in to Synology over SSH and check the user ID you want Syncthing to run as:

1

id your-admin-username

Record the uid and gid from the output. In many setups, uid is around 1026 and gid is 100. These values will be used as PUID and PGID.

Then open File Station, go to the docker shared folder, and create this directory:

1

/docker/syncthing

This directory stores Syncthing’s configuration files, database, and runtime state. If you rebuild the container later, the configuration can be preserved as long as this directory remains in place.

Download the Syncthing Image

Open Container Manager, go to “Registry” on the left, and search for:

1

syncthing

Select the official image syncthing/syncthing, use the latest tag, and download it. After the download finishes, go to “Image”, select syncthing/syncthing, and click “Run”.

Create the Container

Set the container name to:

1

syncthing

It is also recommended to enable automatic restart, so Syncthing starts again automatically after the NAS reboots.

Configure Environment Variables

In the advanced settings, add or modify these environment variables:

1
2
3

PUID=1026
PGID=100
TZ=Asia/Shanghai

Replace PUID and PGID with the actual values you found earlier using id username. When Syncthing reads and writes shared folders, it will access the Synology file system as this user.

Pin the Ports

For easier access and troubleshooting, manually fix the port mappings:

Container port Local port Protocol Purpose
8384 8384 TCP Web management UI
22000 22000 TCP Sync data transfer
22000 22000 UDP QUIC data transfer
21027 21027 UDP Local network discovery

If the Synology firewall is enabled, allow these ports as well. For LAN-only use, at minimum make sure 8384 is reachable from your computer.

Configure Volume Mappings

Volume mappings fall into two groups: Syncthing’s own configuration directory, and the Synology shared folders you want to sync.

Map the configuration directory like this:

Synology host path Container mount path
/docker/syncthing /var/syncthing

Then add the data directory you want to sync. For example, if you want to sync /volume1/NasData on Synology, map it like this:

Synology host path Container mount path
/volume1/NasData /NasData

This is important: when adding a folder in the Syncthing web UI later, enter the container path, for example:

1

/NasData

Do not enter the Synology host path /volume1/NasData. Syncthing runs inside the container and can only see the paths mounted into that container.

If you want to sync multiple shared folders, add more mappings, for example:

1
2
3

/volume1/Photos  ->  /Photos
/volume1/Backup  ->  /Backup
/volume1/NasData ->  /NasData

Start and Access Syncthing

After confirming the environment variables, ports, and volume mappings, click “Done” to start the container.

Then open this address in your browser:

1

http://your-Synology-IP:8384

After entering the Syncthing management UI, the first thing to do is set a username and password for the web interface. The path is:

1

Actions -> Settings -> GUI

Do not leave the Syncthing management UI exposed on your LAN for long without a password.

Add a Sync Folder

Click “Add Folder” and enter the container path configured earlier in “Folder Path”, for example:

1

/NasData

If the permissions are configured correctly, Syncthing can read and write this shared folder. After that, add a remote device, select the folder to share, and syncing can begin.

Sync iPhone photos to a computer or NAS

Understand the Limits on iOS First

On Android, Syncthing-Fork can run for a long time through a background service, run conditions, and battery optimization exemptions. iOS does not allow third-party sync tools to run in the background without limits.

This means:

  • Do not expect it to sync 24/7 like a NAS.
  • After the app goes into the background, the sync window may be short.
  • For large photo batches, it is best to open the app manually and let it finish.
  • iCloud optimized storage may affect whether the original photo files can be read.

So on iPhone, Syncthing is better treated as a “open the app periodically to sync photos” workflow, rather than a fully invisible real-time background sync service.

Step 1: Install the Client and Grant Permissions

After installing Mobius Sync from the App Store, handle these permissions carefully the first time you open it.

Notifications

It is recommended to allow notifications. They can show sync status, connection status, and error messages.

Local Network Access

This permission is very important.

iOS separately asks whether an app may access the local network. If you deny it, the iPhone may not be able to discover your PC, NAS, or other Syncthing nodes on the LAN.

If you denied it by mistake, you can enable it again in iOS Settings.

Photo Library Access

If you want to sync photos, you must allow access to the photo library.

The recommended choice is:

1

Full Access to Photos

If you only grant limited photo access, Mobius Sync may only see the selected photos, and newly added photos may not be synced later.

Step 2: Pair the iPhone with the PC or NAS

Syncthing pairing still works by exchanging device IDs.

On the iPhone:

  1. Open Mobius Sync.
  2. Go to Settings.
  3. Open Device ID.
  4. Keep the QR code screen open.

On the PC or NAS:

  1. Open the Syncthing Web UI.
  2. Click Add Remote Device.
  3. Scan the QR code on the iPhone, or enter the device ID manually.
  4. Give the device a name, such as My-iPhone.
  5. Save.

Return to the iPhone, wait for the connection request, and tap Accept.

At this point, the iPhone and the PC/NAS trust each other, but the photo library has not been shared yet.

Step 3: Create a Photo Sync Folder on the iPhone

iOS does not let you choose a path like /DCIM/Camera directly in the same way Android does. Mobius Sync provides special support for the system photo library, so you need to choose the photo-library folder type.

In Mobius Sync:

  1. Switch to Folders.
  2. Tap + in the upper-right corner.
  3. Create a new folder.

Important fields:

  • Folder Type: choose Camera Roll.
  • Folder Label: use an easy-to-recognize name, such as iPhone_Photos.
  • Folder ID: you can keep the generated value, or use a stable English ID.
  • Folder Path: keep the default so the client can bind to the iOS photo library.

Then, in the Sharing section, select the PC or NAS you just paired.

Step 4: Set the iPhone Side to Send Only

Photo sync is usually “phone sends to NAS”, not a two-way editing workflow.

So on the iPhone side, set the folder type to:

1

Send Only

This makes the iPhone responsible for sending photos out, without accepting reverse changes from the PC or NAS.

This reduces the risk of accidental operations. For example, when organizing the backup folder on the computer, you usually do not want those changes to affect the iPhone photo library.

Still, remember that Syncthing is a sync tool, not a complete backup system. For long-term photo safety, you should also use NAS snapshots, file versioning, or an independent backup.

Step 5: Receive Photos on the PC or NAS

After saving on the iPhone, the Syncthing Web UI on the PC or NAS will show a prompt:

1

Device My-iPhone wants to share folder iPhone_Photos

Click add.

Set the storage path.

On Windows, it may look like:

1

D:\Backups\iPhone_Photos

On Linux or NAS, it may look like:

1

/volume1/photos/iphone

If Syncthing runs in Docker, enter the path inside the container. For example, if the host mount is:

1

- /volume1/photos:/var/syncthing/photos

Then in the Web UI, use:

1

/var/syncthing/photos/iphone

Set the Receiving Side to Receive Only

On the PC or NAS side, it is also recommended to set this folder type to:

1

Receive Only

This makes the receiving side accept photos from the iPhone, without syncing local changes back to the iPhone.

It is a second layer of protection:

  • iPhone side: Send Only
  • NAS side: Receive Only

Both ends are configured around one-way backup, which better matches a photo archive workflow.

The Reality of iOS Background Sync

iOS is strict about background execution. Even with correct settings, do not expect Mobius Sync to keep running silently in the background all the time.

Common behavior:

  • Sync speed is normal while the app is open.
  • It may keep syncing for a short time after going into the background.
  • After a while, the system may pause or limit it.
  • Location changes, system scheduling, or short background windows may wake it again.

The most reliable practical workflow is simple:

  1. After taking many photos, open Mobius Sync manually.
  2. Keep the phone awake, or avoid locking the screen too quickly.
  3. Wait for the new photos to finish syncing.
  4. Then close the app or lock the screen.

If you are used to doing a photo backup every few days, this approach is fairly reliable.

Avoid iCloud Optimized Storage Problems

If the iPhone has enabled:

1

Optimize iPhone Storage

iOS may keep only thumbnails locally while the original files remain in iCloud. When a third-party sync client tries to read photos, it may not be able to get the full originals, causing failed syncs, skipped items, or waits while iOS downloads the files.

The better setting for sync backup is:

1

Download and Keep Originals

The path is usually:

1

Settings -> Apple ID -> iCloud -> Photos

If the phone does not have enough storage and you must use optimized storage, you may need to open the relevant photos in the system Photos app before syncing, so the iPhone downloads the originals from iCloud first, and then start Mobius Sync.

Tips for the First Large Photo Sync

The first time you sync an iPhone photo library, there may be thousands or even tens of thousands of photos. Do not rush to finish everything in one pass.

A safer approach:

  1. Sync a small number of photos first for testing.
  2. Confirm the NAS path is correct.
  3. Confirm the folder types are Send Only / Receive Only.
  4. Confirm the receiving side will not affect the iPhone in reverse.
  5. Then start the full sync.

During the first sync, it is best to:

  • Keep the iPhone plugged in.
  • Keep Wi-Fi stable.
  • Keep Mobius Sync open in the foreground.
  • Keep the NAS or PC online.

When the photo library is large, the sync may take a long time. That is normal.

A stable iPhone photo sync setup looks like this:

  1. Install Mobius Sync on the iPhone.
  2. Allow notifications, Local Network access, and full photo library access.
  3. Exchange device IDs between the iPhone and NAS.
  4. Create a Camera Roll folder on the iPhone.
  5. Set the folder label to iPhone_Photos.
  6. Set the iPhone-side folder type to Send Only.
  7. Set the NAS receiving path to /volume1/photos/iphone.
  8. Set the NAS-side folder type to Receive Only.
  9. Enable file versioning or snapshots on the NAS.
  10. Open Mobius Sync manually every few days to complete sync.

If you rely heavily on fully automatic background photo backup, iOS will be more troublesome than Android. The system restrictions make it difficult for third-party sync tools to behave like an always-on background service.

Multi-folder governance and versioning

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.

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:

  1. Open the target folder settings.
  2. Go to file versioning.
  3. 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.

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.

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

  1. Use the NAS as the hub.
  2. Set the NAS as the introducer.
  3. Pair all devices only with the NAS.
  4. Put all sync folders under /volume1/Syncthing/.
  5. Use phone Send Only and NAS Receive Only for photo folders.
  6. Use Send & Receive for work documents and notes.
  7. Use NAS Send Only and other devices Receive Only for distribution folders.
  8. Enable versioning for important folders on the NAS.
  9. Configure ignore rules for code and cache directories.
  10. 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.

Multi-device topology and pairing

Understand Peers and the Pseudo Server First

Every Syncthing device has its own device ID. When two devices add each other’s ID and share the same folder, they can sync.

That means Syncthing itself does not require one server to hold all data. What people call a “server” is usually just an always-on device that you choose as the operational center.

For example:

  • A NAS is always on and has plenty of storage, so it works well as a central node.
  • Phones and laptops often go offline, so they are better treated as edge devices.
  • A desktop may be powerful, but it may not run 24/7, so it is usually a normal sync node.

This central node is not a protocol-level server. It is simply the device you let handle management and relay duties in your topology.

Mode 1: Pure Peer Mesh

In pure peer mode, every device pairs with every other device.

For example, suppose you have four devices:

  • NAS
  • Desktop
  • Laptop
  • Phone

Each device needs to connect to the other three. Any two online devices can then sync directly.

Advantages:

  • Transfer paths are more direct.
  • If one device is offline, other online devices can still sync with each other.
  • There is no dependency on a single central node.

Disadvantages:

  • The more devices you have, the more complex pairing becomes.
  • Adding a new device requires confirmation and setup on multiple existing devices.
  • Folder sharing relationships can become scattered.

When you only have a few devices, pure peer mode is comfortable. For one computer and one phone, or two computers syncing notes, there is no need to overthink the design.

Once you have five or six devices, maintaining a fully connected mesh by hand becomes increasingly annoying.

Mode 2: NAS-Centered Star Topology

Star topology is usually better for home and personal productivity setups.

Pick one device that stays online, has enough space, and has a stable network connection, such as:

  • NAS
  • Synology
  • Soft router
  • Mini PC
  • Home Linux server

Then pair every other device only with that center:

1
2
3

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

The phone does not need to pair directly with the laptop, and the laptop does not need to pair directly with the desktop. They all sync indirectly through the NAS.

Advantages:

  • Management is simple.
  • A new device only needs to pair with the NAS.
  • The NAS can handle versioning and backup buffering.
  • It fits 24/7 sync scenarios.

Disadvantages:

  • If the NAS is offline, other devices may not be able to keep syncing with each other.
  • If all traffic goes through the NAS, its network and disk performance affect the experience.
  • The central node’s permissions need to be managed carefully.

If you already have a NAS or an always-on mini server, star topology is the default recommendation. It keeps Syncthing’s P2P strengths while making day-to-day management feel much closer to centralized sync.

Basic Order for Multi-Device Setup

No matter which topology you choose, Syncthing setup follows this order:

  1. Pair devices first.
  2. Share folders second.
  3. Confirm the local path on the receiving side last.

Do not start by creating folders everywhere. Clarify device relationships first, and the later steps will be much less chaotic.

Step 1: Pair Devices

Assume you want to connect device A and device B.

Device A could be a phone, while device B could be a NAS or computer.

On device A:

  1. Open the Syncthing Web UI.
  2. Click Actions in the upper-right corner.
  3. Choose Show ID.
  4. Copy the device ID or display the QR code.

On device B:

  1. Open the Syncthing Web UI.
  2. Click Add Remote Device.
  3. Enter device A’s ID.
  4. Give the device a recognizable name, such as My-Phone.
  5. Save.

Then return to device A. It will usually show a prompt saying that device B wants to connect. Accept it.

At this point, the two devices have established a peer relationship, but no folders are syncing yet.

Step 2: Create and Share a Folder

On device A, click Add Folder.

Common fields:

  • Folder label: a human-readable name, such as Notes.
  • Folder ID: the cross-device identifier. Use stable English names, such as notes.
  • Folder path: the real local path on this device.

Then switch to the Sharing tab and select the device B you just paired.

After saving, device A sends a folder sharing invitation to device B.

Step 3: Accept the Share

Open device B’s Web UI and wait a few seconds. You will usually see a prompt like:

1

Device A wants to share a folder

Click add, then choose a local storage path on device B.

For example:

1

/volume1/notes

Or, in a Docker deployment, a container path such as:

1

/var/syncthing/notes

After saving, sync starts.

The paths do not have to match across devices. Syncthing identifies the sync relationship by Folder ID, not by requiring every device to use the same local path.

How to Configure Star Topology

If you use the NAS-centered model, a good setup is:

  1. Deploy Syncthing on the NAS first.
  2. Pair every phone, computer, and server only with the NAS.
  3. Create or accept the main sync folders on the NAS.
  4. Each new device only needs to add the NAS device ID.
  5. Share each folder only between the NAS and the devices that need it.

For example:

1
2
3
4
5

NAS
├── notes       -> desktop, laptop, phone
├── photos      -> phone, backup disk
├── downloads   -> desktop, NAS
└── scripts     -> desktop, laptop

This keeps the structure clear. You can treat the NAS as the control panel for sync relationships.

What Is an Introducer?

Syncthing has a useful feature called Introducer.

It is designed for multi-device setups.

Suppose you set the NAS as an introducer. Later, when a new device pairs with the NAS, the NAS can introduce the other devices it knows to the new device. It can also help propagate existing shared relationships.

This reduces repetitive clicking and repeated device pairing.

It is useful when:

  • You have several computers and phones at home.
  • The NAS is the long-running central node.
  • You add new devices often.
  • You want to reduce manual device relationship maintenance.

Be careful, though. An introducer expands the scope of automatically established relationships. Do not set an untrusted device as an introducer, and do not enable it casually before you understand the topology.

A safer rule is:

  • Only set the NAS or main server as the introducer.
  • Do not make ordinary phones or laptops introducers.
  • After adding a new device, check which devices and folders were added automatically.

Different Folders Can Use Different Topologies

Syncthing topology does not need to be site-wide or uniform. You can design it per folder.

For example:

  • notes: desktop, laptop, phone, and NAS all use Send & Receive.
  • photos: phone sends, NAS receives and keeps versions.
  • downloads: desktop and NAS sync, phone does not participate.
  • backup: main computer is Send Only, NAS is Receive Only.

Do not force every directory into one rule. In multi-device sync, the important question is data direction, not device count.

Think About Conflicts and Accidental Deletion Early

The most common multi-device sync problem is not failed setup. It is accidental deletion or conflicts after sync is already working.

Risky scenarios include:

  • Two devices edit the same file at the same time.
  • A mobile app automatically cleans a folder.
  • One device uses the wrong path, creates an empty folder, and syncs it out.
  • Cache files, temporary files, workspace state, and real files are synced together.
  • Versioning is not enabled on the NAS.

Recommendations:

  • Enable file versioning on the NAS for important folders.
  • Use .stignore to exclude caches and temporary files.
  • Before the first sync of a new folder, test with a small number of files.
  • If deletion behavior is unclear, do not set every device to Send & Receive.

If you have a NAS or always-on server, use star topology directly:

  1. Use the NAS as the central node.
  2. Pair the NAS with all devices.
  3. Ordinary devices pair only with the NAS.
  4. The NAS can be set as an introducer.
  5. Choose Send & Receive, Send Only, or Receive Only per folder.
  6. Enable file versioning on the NAS for important folders.
  7. After adding a new device, share a test folder first to confirm path and permissions.

If you only have two or three devices, and they are often online, pure peer mode is fine. It is more direct and may be faster.

Where Syncthing Fits

Syncthing is a good fit if:

  • You want data to stay mainly on your own devices.
  • You can understand device pairing, folders, and conflict handling.
  • You have a NAS, home server, or multiple personal devices.
  • You want to sync Markdown, photo intake folders, scripts, or lightweight documents.

It is not ideal if:

  • You need collaborative online editing.
  • You need web previews and sharing links.
  • You need fine-grained team permissions.
  • You do not want to deal with network, firewall, or conflict issues.

It is best understood as a reliable device-to-device sync layer, not a full cloud-drive product. Used well, it can connect a NAS, computers, and phones into a controllable personal data network. Used casually, it can become a maintenance burden through conflicts, accidental deletion, ignore rules, and network quirks.

References