How To Set Up A Complex Syncthing Network

Updated October 2026 for Syncthing 2.1, Debian 12, Ubuntu 24.04 and AlmaLinux 9.

What is Syncthing?

Syncthing is a decentralized file sync tool. It keeps a folder identical across several machines, the way Dropbox or Google Drive do, but your data never goes up to anyone’s public cloud. Unlike Nextcloud or ownCloud, it doesn’t need a central server either. You can still add an always-on node, and for a team spread across home connections that’s often the best change you’ll make. More on that below.

Syncthing is peer-to-peer rather than client-server. Every device on your Syncthing network keeps its own copy of each shared folder and pushes new files and changes straight to the others. It isn’t open sharing like a file-sharing app, though. Only devices you’ve explicitly authorized can connect, and all traffic between them is secured with TLS, so nobody in the middle can read your data.

My Syncthing Use Case

I have a library of almost 3TB: over 250,000 files in more than 20,000 directories, most of them between 5MB and 100MB. Four people work on the project. Each of us needs to add, remove and edit items, and every change has to reach everyone else.

Mirroring that much data between several computers isn’t trivial, and we went through a few setups before settling on one.

The original setup was a central server that we all pulled from with rsync. That kept change tracking simple, because whatever was on the server was the latest copy. Updating was the annoying part. We had to log in over FTP to push changes, even though every one of us already had a local copy. The real Achilles heel, for us, was paying for a central server big enough to hold the whole library.

We looked at Nextcloud and ownCloud, but they need a central server too. One of our home servers could have played that role, but it would have eaten that person’s bandwidth. Public cloud storage was out because of security concerns and the cost of keeping 3TB there at the time.

Why We Moved to Syncthing

Enter Syncthing, a peer-to-peer sync tool that works without a central server. It was the cheapest and simplest way for us to manage the collection. Our computers send changes to each other directly. That uses a bit more bandwidth per person than the central server did, but the load is spread evenly. We all wanted a full local copy anyway, and now we could edit files on our own machines instead of shuffling them up to a server first.

Connecting our existing folders was painless. They’d been rsynced with each other up to that point, so they already matched and there was no huge initial sync. Once Syncthing was running on every machine, it scanned the files, compared notes with the other peers and confirmed everyone had the same content. Then we were in sync and ready to go.

Does Syncthing Need a Central Server?

No. The Syncthing FAQ says it “exchanges your data across your machines as soon as they are online at the same time.” That last part is the catch.

Say one person edits files in the evening and shuts the laptop, and the next person doesn’t come online until the first one is gone again. Those changes have nowhere to go until both machines happen to be awake at once. With four people on home connections, that gets old fast.

The fix is one Syncthing node that never goes offline, on a public IP in a data center. It isn’t a central server in the Nextcloud sense. It has no special role in the protocol, peers still sync directly with each other whenever they can, and nobody logs into it to upload files. It’s simply the device that’s always there to sync with. For a library like ours it needs enough disk for a full copy plus old versions, which is the job a dedicated storage server is built for.

Setting up the always-on node

1. Install Syncthing on the server and run it as a system service under its own user. The commands are in the install section below.
2. Open 22000/tcp and 22000/udp in the server’s firewall. With a public IP and an open port, every other device can reach it directly, so relays never come into it.
3. On each member’s device, add the server as a remote device. In that device’s Advanced tab, change Addresses from dynamic to tcp://hub.example.com:22000, dynamic so members can still find it if global discovery has a bad day.
4. Share the folder with the server from each device. On the server, turn on File Versioning. Syncthing only versions changes it receives from other devices, and on the server every change comes from another device, so it collects old versions of everyone’s edits.
5. If nobody should ever edit files directly on the server, set its folder type to Receive Only. It still applies changes from the group and passes them on to other devices, but anything changed locally on the server stays local.
6. Optionally, tick Introducer for the server on each member’s device. New members then only have to be added on the server, and everyone else gets introduced to them automatically.

Versioning is a safety net, not a backup. The FAQ is blunt about it: deletions and modifications propagate to every device. Keep a real backup of the server’s copy.

Versioning types, ignore patterns and folder types get their own walkthrough in our Syncthing tips and tricks post.

How Syncthing Works

You share folders on your computer with specific peers. There’s no central authority managing the files. You authorize each peer in your own client, and only then can it connect and start syncing the folder with you.

Finding peers: local and global discovery

Devices don’t need to be on the same network. On a LAN, they find each other with local discovery broadcasts on UDP port 21027. Across the internet, each device announces its current addresses to Syncthing’s public global discovery servers, keyed by its device ID. A peer that knows your device ID looks it up there and gets an address to dial.

Discovery servers only hand out addresses. Your files never pass through them. If you’d rather not rely on the public ones, you can run your own with stdiscosrv (it listens on port 8443 by default) and list it under Actions > Settings > Connections > Global Discovery Servers on each device.

Direct connections and NAT

The fastest and most private path is a direct connection, peer to peer, with no middle man touching the data. Syncthing listens on port 22000 for both TCP and QUIC (UDP). NAT traversal is on by default, so Syncthing will try UPnP or NAT-PMP to open that port on a home router by itself. If the router won’t cooperate, forward 22000 TCP and UDP manually.

If you sync between servers or other connections with static IPs, lock the firewall down so only your known peers can reach port 22000.

Relays

Sometimes a direct connection just isn’t possible: a corporate or school firewall, or carrier-grade NAT with no router you control. Syncthing still works there because it falls back to a relay. Relaying is on by default and only kicks in when two devices can’t talk directly. It usually costs you speed, but the relay can’t read your files. The connection stays encrypted end to end, though the relay operator can see your IP, your device ID and how much traffic you move.

The public relays are run for free by community volunteers. You can run a private one with the syncthing-relaysrv package from the same apt repository: set RELAYSRV_OPTS=-token=YOUR-TOKEN in /etc/default/syncthing-relaysrv and it stays out of the public pool and refuses anyone without the token. It listens on 22067/tcp and logs its ID in a URI: line at startup. Devices add it to Actions > Settings > Connections > Sync Protocol Listen Addresses, after the existing entries:

relay://relay.example.com:22067/?id=RELAY-DEVICE-ID&token=YOUR-TOKEN

My take: if you already have an always-on node with a public IP, skip the private relay. Every member can reach that node directly. A private relay earns its keep when devices stuck behind NAT need to reach each other and you don’t want their traffic on public relays. The relay server documentation covers the rest.

How To Install Syncthing

When this post was updated, the current release was Syncthing v2.1.5. For Windows and macOS desktops, grab a build from the Syncthing downloads page. On Linux servers, use the official apt repository where you can and the release tarball where you can’t.

Debian 12 and Ubuntu 24.04

Syncthing runs its own apt repository at apt.syncthing.net. Store the signing key in /etc/apt/keyrings and reference it with signed-by, so the key is trusted for this repository only:

sudo apt-get install -y curl
sudo mkdir -p /etc/apt/keyrings
sudo curl -L -o /etc/apt/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg
echo "deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable-v2" | sudo tee /etc/apt/sources.list.d/syncthing.list
sudo apt-get update
sudo apt-get install syncthing

Note the channel name: stable-v2. The older stable channel still points at 1.30.0, so a sources line copied from an old guide will quietly keep you on 1.x. The package installs /usr/bin/syncthing plus both systemd units, and apt handles upgrades, so Syncthing’s built-in auto-upgrade is disabled in these builds.

AlmaLinux 9 and Rocky Linux 9

There’s no EPEL 9 package (EPEL 10 has one), so use the official release tarball. Check it against the release’s checksum file before installing:

sudo dnf install -y tar
VER=v2.1.5
cd /tmp
curl -LO https://github.com/syncthing/syncthing/releases/download/$VER/syncthing-linux-amd64-$VER.tar.gz
curl -LO https://github.com/syncthing/syncthing/releases/download/$VER/sha256sum.txt.asc
sha256sum --ignore-missing -c sha256sum.txt.asc
tar xzf syncthing-linux-amd64-$VER.tar.gz
sudo install -m 0755 syncthing-linux-amd64-$VER/syncthing /usr/local/bin/syncthing
sudo cp syncthing-linux-amd64-$VER/etc/linux-systemd/system/syncthing@.service /etc/systemd/system/
sudo sed -i 's#/usr/bin/syncthing#/usr/local/bin/syncthing#' /etc/systemd/system/syncthing@.service
sudo systemctl daemon-reload

Use arm64 instead of amd64 on ARM servers. The sed line matters, because the shipped unit expects the binary at /usr/bin/syncthing. One catch: the binary is owned by root and the unit makes /usr read-only, so Syncthing can’t upgrade itself. Set Actions > Settings > General > Automatic upgrades to “No upgrades” and repeat the steps above with a new VER when a release comes out.

Run it as a service

Packages and the tarball both ship two systemd units. syncthing@.service is a system unit that runs Syncthing as the user named after the @. syncthing.service is a user unit for desktops. On a server, give Syncthing its own user and set a GUI login before the first start:

sudo useradd --create-home --shell /usr/sbin/nologin syncthing
ST=$(command -v syncthing)
sudo -u syncthing -H $ST generate --gui-user=admin --gui-password=-
sudo systemctl enable --now syncthing@syncthing.service
sudo -u syncthing -H $ST device-id

The ST line finds the binary wherever it lives, because sudo on AlmaLinux doesn’t search /usr/local/bin. The generate step reads the password from standard input, so type it and press Enter. The last command prints the server’s device ID, which you’ll paste into the other devices. Configuration lives in ~/.local/state/syncthing for whichever user runs Syncthing.

On a Linux desktop, run it as your own user instead:

systemctl --user enable --now syncthing.service
sudo loginctl enable-linger $USER

The linger line is optional. It starts your user’s services at boot without waiting for you to log in.

Open the firewall

Peers need 22000/tcp and 22000/udp. Local discovery uses 21027/udp, which only matters on a LAN. On Ubuntu with ufw, the apt package ships an application profile:

sudo ufw allow syncthing

On AlmaLinux or Rocky with firewalld:

sudo firewall-cmd --permanent --add-port=22000/tcp --add-port=22000/udp
sudo firewall-cmd --reload

Reach the web GUI

The GUI listens on http://127.0.0.1:8384/ by default. That’s plain HTTP and localhost only. (Older versions of this post said https, which was wrong for a default install.) On a remote server, don’t open 8384 to the internet. Tunnel to it over SSH:

ssh -L 8384:127.0.0.1:8384 you@hub.example.com

Then browse to http://127.0.0.1:8384/ on your own machine. If you skipped the --gui-user step, the GUI shows a “GUI Authentication: Set User and Password” notice until you set one under Actions > Settings > GUI.

You can make the GUI listen on other IPs by changing GUI Listen Address on that same tab. If you do, set a strong password and tick Use HTTPS for GUI first. The GUI listen address documentation has the details.

Upgrading From Syncthing 1.x

Syncthing 2.0 came out in August 2025, and a few things changed that will bite an older setup:

• Apt channel. Switch stable to stable-v2 in your sources line, or you’ll stay on 1.30.0.
• Database migration. The index database moved from LevelDB to SQLite. The first v2 start migrates it, and on a library with hundreds of thousands of files that can take a long time. Don’t panic and kill it.
• Command-line flags. Single-dash long options are gone, so -home has to be --home. Some options became subcommands. Check any custom unit files or scripts.
• Deleted-item records expire. Syncthing no longer remembers deletions forever. Current 2.x builds forget them after 10920 hours, about 15 months (the --db-delete-retention-interval option).
• No Default Folder. A fresh install no longer creates a “Default Folder” in ~/Sync.

Connecting To Your First Peers on Syncthing

Adding a peer to a shared folder is straightforward. First you need their Device ID. In the web UI it’s under Actions > Show ID, in the upper right corner. On a headless server, syncthing device-id prints it. A Device ID is a long alphanumeric string that looks a lot like a product license key.

To add the peer, click “Add Remote Device” at the bottom of the device list on the right side of the web UI. The dialog has three tabs that matter:

• General. Paste the peer’s Device ID. The Device Name can be anything you like. It’s only for you, so you know who the peer is.
• Sharing. Tick Introducer if you want this peer to be able to bring other devices into your shared folders. When the peer authorizes a new device on a folder you share, that device gets introduced to you and you start syncing with it directly, with no extra steps. Tick Auto Accept if you want folders this peer shares with you to be created automatically at your default path. Then tick each folder you want to share with this peer.
• Advanced. Addresses can usually stay at dynamic, which lets Syncthing find the peer through discovery. For a server with a fixed hostname, put its address in front, like tcp://hub.example.com:22000, dynamic.

Click Save. The other side gets a prompt to add you back, and both devices have to accept each other before anything syncs. Give it a minute to connect and you should be on your way.

My Syncthing Review

Is Syncthing perfect? No, of course not.

It’s free, open source software with its share of rough edges, but it works well and development is very much alive. Version 2 shipped a new database and a pile of fixes. I still plan to use it for a long time.

The rescan interval is the first thing I tune on a big library. When I first wrote this, Syncthing found changes mainly by rescanning every folder on a timer, which hammered the disk with a library this size. Current versions have Watch for Changes turned on by default: the filesystem tells Syncthing what changed, and it usually picks changes up within about ten seconds. The full rescan still runs as a safety net, hourly by default. On a library with hundreds of thousands of files I push it way up. I use 36000 seconds (10 hours). Click Edit on the folder, open the Advanced tab and change Full Rescan Interval (s). When I want something out right away, the Rescan button on the folder starts one immediately.

On Linux, watching needs one inotify watch per directory. With more than 20,000 directories, check that fs.inotify.max_user_watches is high enough. The Syncthing FAQ suggests 204800:

echo "fs.inotify.max_user_watches=204800" | sudo tee /etc/sysctl.d/90-syncthing-inotify.conf
sudo sysctl --system

My old pet peeve was deleted files coming back. Delete a file while a peer is offline, and when it reconnects, the file reappears. Syncthing does record deletions and hands them to a peer when it reconnects, so in a healthy setup a delete sticks. The common exception is a peer that edited the file while it was offline. That’s a conflict between a modification and a deletion, and Syncthing keeps the edited content (as the file itself or as a .sync-conflict copy) rather than throw away someone’s work. In v2 there’s one more case: a device that’s been offline longer than the deletion retention period, about 15 months by default, can bring old files back. An always-on node helps a lot here, because deletes land somewhere immediately instead of waiting for the right two laptops to be awake at once.

I’ve also had trust issues with the web UI. I’ve seen it claim I was hundreds of gigabytes out of sync with my peers, apparently syncing, while barely using any bandwidth. Glitches like that dent your confidence, but my data was fine every time, and after years of use I trust it even when the UI looks odd.

Keeping a big folder identical across several machines is a hard problem, and Syncthing handles it well. I’ve watched it gain features and polish the whole time I’ve used it. If you need file sync without handing your data to a cloud provider, it deserves a serious look.

Want a box in a data center to be your always-on Syncthing node? Ask us for a quote.

Interested in more tutorials and tips? Check out the GigeNET blog.

Already have enough on your plate? Explore GigeNET’s managed services.