Goodbye Complex Configurations: Why Your Syncthing Relay Node Only Needs to Be Another Client

AI generated + manually edited. 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.

If you’re a loyal user of Syncthing, you must love its elegant decentralized, end-to-end encrypted synchronization approach. But you’ve definitely encountered this classic dilemma: how do you ensure smooth synchronization between your laptop at Starbucks, your desktop at home, and your phone in your pocket? They’re usually not on the same local network and are all hiding behind their respective routers (NAT).

Typically, there are three solutions:

1. Rely on public servers: This is the default option. Simple, but speed and privacy may be limited by third parties.
2. Self-build discovery and relay servers: This is the “hardcore” player’s choice. By running stdiscosrv and strelaysrv, you can have a completely private network. But this requires complex configuration, certificate management, and server maintenance.
3. The “lazy person’s” ultimate solution we’ll discuss today: Using a regular Syncthing client as a “hub node”.

As it turns out, for the vast majority of individual or small team users, the third approach is not only simpler but also more powerful. Below, I’ll explain why you should abandon the hassle of dedicated servers and embrace this elegant alternative.

The Core Problem: Discovery and Connection

To understand why “client as hub” works, we first need to understand the two core challenges Syncthing faces:

• 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.” This is cool, but for personal use, it’s often overkill.

How Does the “Client as Hub” Solution Work?

The core idea of this solution is very 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” cleverly solves both discovery and relay problems simultaneously:

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 to setting up dedicated discovery/relay servers, this “client as hub” model has overwhelming advantages.

1. Extremely Simple Configuration, No Professional Knowledge Required

	Dedicated Server Solution	Client Hub Solution
Installation	Download stdiscosrv and strelaysrv binary files	apt install syncthing or download from official site
Configuration	Complex command-line parameters, key generation, systemd service configuration	Familiar Web GUI, configure like any other client
Firewall	Need to open specific ports for discovery and relay services (like 22067, 22070)	Only need to open Syncthing default port (22000/TCP)
Maintenance	Manually update services, ensure continuous operation	One-click update through Web GUI

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.

2. More Powerful: It’s Not Just a Mediator, But Also a Backup Node

This is the most critical advantage. A pure relay server doesn’t store any of your files—it only forwards traffic.

Your “client hub” node, because it’s a full-featured Syncthing client, will completely save your shared folders. This 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.

You get a reliable, always-online remote backup and synchronization center for free.

3. Equally Secure

You might think: “Is it safe to store my files completely on a VPS? Isn’t a relay server safer because it doesn’t store files?”

This is a good question, but it’s based on a misunderstanding. Syncthing’s core security promise 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?

Solution	Security Responsibility
Public Servers	You trust the Syncthing Foundation and community operators.
Self-built Relay Server	You need to protect the strelaysrv process and the server itself from intrusion.
Client Hub Solution	You need to protect the syncthing process and the server itself from intrusion.

See? Whether it’s self-built relay or client hub, the security responsibility lies with you—the server administrator. You need to implement basic server security measures: use key-based SSH login, configure firewalls (ufw), and keep the system updated. As long as your server is secure, your data is secure. From this perspective, the security of both self-built solutions is equivalent.

4. More Cost-Effective

Let’s do some economic calculations.

• 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. Your time is very valuable.
• 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.

Every penny you spend gets multiple times the return.

Conclusion

In pursuing technical implementation, we often fall into the trap of “complexity for complexity’s sake.” Setting up dedicated discovery and relay servers is undoubtedly an excellent way to understand Syncthing’s underlying networking, but for the vast majority of users who just want to “get things done,” it’s too cumbersome.

Deploying a standard Syncthing client on an always-online device as the network’s hub node is a simpler, more practical, and more powerful solution. It not only perfectly solves the problems of device discovery and data relay but also provides you with a reliable remote backup and asynchronous synchronization center for free.

Next time when you’re troubled by NAT traversal and device discovery, don’t rush to study the complex documentation of stdiscosrv and strelaysrv. Take a step back and think: maybe what you need isn’t a dedicated relay server, but just an always-online, trustworthy “friend”—a regular Syncthing client.

Abandon unnecessary complexity and embrace this elegant pragmatism. Your synchronization network should be this simple, powerful, and completely under your control. Now, go to that dusty VPS and unleash Syncthing’s full potential!