Syncthing Relay Node: A Regular Client Is Enough

The main purpose of this article is to introduce the idea of “using an intermediary instead of self-built discovery and relay servers”, and does not include specific setup methods.

When using Syncthing across multiple devices, the hard part is usually not installation. It is how devices find each other. Your laptop, desktop, and phone are often on different networks, hidden behind NAT, and direct connections can be unreliable.

There are usually three options:

1. Rely on public servers: This is the default option. Simple, but speed and privacy may be limited by third parties.
2. Self-host discovery and relay servers: Run stdiscosrv and strelaysrv for a private setup. It adds configuration, certificate management, and server maintenance.
3. Regular client hub: Use a normal Syncthing client as the hub node.

For most individuals or small teams, the third option is easier to run and fits daily use better.

The Core Problem: Discovery and Connection

To understand why “client as hub” works, start with two problems Syncthing needs to solve:

• Device Discovery: How does device A know device B’s IP address? In a local network, they can find each other through local broadcast. On the internet, they need a “discovery server” like a phone book to exchange address information.
• NAT Traversal and Relaying: Even if A and B know each other’s addresses, they may not be able to establish direct connections because they’re behind routers (NAT). This requires a public “relay server” to forward their traffic.

Self-building stdiscosrv and strelaysrv privatizes the “phone book” and “relay station.” It works, but it is often overkill for personal use.

How Does the “Client as Hub” Solution Work?

The idea is simple:

Install a standard Syncthing client on a device with a public IP that’s online 24/7 (like a cheap VPS, a Raspberry Pi at home, or a NAS), and have all your other devices connect to it.

This hub node handles both discovery and data transfer:

1. As an “Introducer,” solving the discovery problem:

   • Your laptop (A) and phone (C) both add the hub node’s (B) device ID.
   • When both A and C connect to B, B tells A: “Hey, I know C, its address is xxx.” At the same time, it tells C: “Hey, I know A, its address is yyy.”
   • This way, A and C get to know each other through their mutual friend B. Syncthing’s “Introducer” feature allows devices to discover other connected devices. Your hub node is the super introducer for all your devices.

2. As a “data warehouse,” solving the relay problem:

   • If A and C fail to connect directly (NAT traversal fails), their data synchronization won’t be interrupted.
   • Because A will synchronize file changes to hub node B.
   • Subsequently, C will pull these changes from hub node B.
   • The data flow path changes from A <--> C to A --> B --> C. While this isn’t strictly a “relay” because it stores data on B, it perfectly achieves the ultimate goal of data transfer between different devices.

Why Is This Solution Superior?

Compared with dedicated discovery/relay servers, the client hub model is easier for personal use.

I. Simpler configuration

You don’t need to learn any new command-line tools or configuration file syntax. You just need to click a few times in the familiar Syncthing Web interface.

II. It is also a backup node

A pure relay server does not store your files. It only forwards traffic.

Your client hub is a full Syncthing client, so it keeps full copies of shared folders. That means:

• Natural data redundancy: Your files now have at least three copies (e.g., desktop, laptop, VPS). If any device goes offline or gets damaged, data won’t be lost.
• Asynchronous synchronization: Your laptop modifies files in a café and syncs to the VPS, then can be shut down. When you get home and turn on your desktop at night, it will automatically pull the latest version from the VPS without needing the laptop to stay online.

The hub also becomes an always-online remote backup point.

III. Equally Secure

Storing full copies on a VPS needs a separate security check. A relay server does not store files, so it looks safer at first.

Syncthing’s core security design is end-to-end encryption (E2EE).

• Data is always encrypted during transmission: Data transmitted between any two Syncthing nodes is encrypted with TLS. Whether it’s your laptop connecting to a VPS or your laptop trying to directly connect to your phone, the channel is encrypted.
• Your VPS is a trusted node: When using the “client hub” solution, you’re not exposing data to an untrusted third party. On the contrary, you explicitly add this VPS as one of your trusted devices. Data is stored decrypted on the VPS, just like data on your own desktop or laptop.

The real security question is: How much control do you have over this VPS?

Whether you self-host a relay or use a client hub, the server administrator owns the security responsibility. Basic measures still matter: key-based SSH login, firewall rules (ufw), and system updates. From this perspective, the two self-hosted options have similar security responsibility.

IV. More Cost-Effective

Now look at cost.

• Hardware costs: Running a dedicated discovery/relay server versus running a standard Syncthing client has almost no difference in server resource requirements (CPU, memory). A $5/month entry-level VPS is more than sufficient, and you can even use Oracle Cloud’s free tier for zero cost.
• Time costs: This is where the biggest difference lies. Configuring and maintaining dedicated servers requires more time and effort to learn and troubleshoot. The “client hub” solution’s configuration time is almost zero because it’s just the standard client you’re already familiar with. Time is also a cost.
• Added value: This is where the “client hub” solution completely wins. For the same money (or even less time), you get not just a synchronization mediator, but also:
  • An always-online remote backup node.
  • A data warehouse that enables asynchronous synchronization.
  • A full-featured Linux server that can host personal blogs, Git repositories, VPN, or other small projects.