Secure File Sync Between Linux Servers with Syncthing and WireGuard (Step-by-Step)

Why Syncthing + WireGuard is a smart choice

When you need reliable file synchronization between Linux servers, it’s tempting to reach for classic tools like rsync over SSH or an NFS share. Those options still work, but they can be painful when you have multiple sites, changing IP addresses, strict firewalls, or you want near real-time updates without a central storage server. A modern approach is to combine Syncthing (continuous, peer-to-peer file sync) with WireGuard (fast, secure VPN). You get encrypted transport, stable private IPs, and a sync tool that can handle intermittent connectivity gracefully.

This tutorial shows how to set up Syncthing to sync a directory between two Linux servers over a WireGuard tunnel. The result is a private “always-on” sync link that doesn’t require exposing Syncthing to the public internet.

What you’ll build

You will configure:

Server A: 10.10.10.1 (WireGuard interface: wg0)

Server B: 10.10.10.2 (WireGuard interface: wg0)

Syncthing will bind to the WireGuard interface so sync traffic stays inside the VPN. We’ll also harden firewall rules and enable Syncthing as a system service.

Prerequisites

Before you start, make sure both servers have sudo access and can reach each other on the internet (at least one side needs a reachable UDP port for WireGuard). You should also know which folder you want to sync, for example /srv/sync. This guide assumes Ubuntu/Debian-style commands; on RHEL/Fedora you can adapt package manager commands accordingly.

Step 1: Install WireGuard on both servers

On both servers, install WireGuard:

Debian/Ubuntu: sudo apt update && sudo apt install -y wireguard

Enable IP forwarding is not required for a simple point-to-point sync tunnel, but it doesn’t hurt to keep routing simple and only use the tunnel addresses for Syncthing.

Step 2: Create WireGuard keys

On each server, generate a keypair:

umask 077
wg genkey | tee ~/wg-private.key | wg pubkey > ~/wg-public.key

Copy each server’s wg-public.key to the other side. Keep private keys private.

Step 3: Configure the WireGuard tunnel

On Server A, create /etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.10.1/24
PrivateKey = SERVER_A_PRIVATE_KEY
ListenPort = 51820

[Peer]
PublicKey = SERVER_B_PUBLIC_KEY
AllowedIPs = 10.10.10.2/32
PersistentKeepalive = 25

On Server B, create /etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.10.2/24
PrivateKey = SERVER_B_PRIVATE_KEY

[Peer]
PublicKey = SERVER_A_PUBLIC_KEY
Endpoint = SERVER_A_PUBLIC_IP:51820
AllowedIPs = 10.10.10.1/32
PersistentKeepalive = 25

Start and enable the tunnel on both servers:

sudo systemctl enable --now wg-quick@wg0

Test connectivity:

ping -c 3 10.10.10.2 (from Server A)
ping -c 3 10.10.10.1 (from Server B)

Step 4: Install Syncthing on both servers

Install Syncthing from your distro repo or the official package source. On Debian/Ubuntu, the repo version may be older, but it still works. For a straightforward setup:

sudo apt update && sudo apt install -y syncthing

Step 5: Run Syncthing as a service (recommended)

Create a dedicated user (optional but clean) and run Syncthing under it. For a fast setup using your current user, enable the user service:

systemctl --user enable --now syncthing

If you prefer a system-wide service tied to a specific account:

sudo systemctl enable --now [email protected]

Step 6: Bind Syncthing to WireGuard only

To keep sync traffic inside the VPN, open Syncthing’s Web UI locally (or via SSH port forwarding) and adjust settings:

1) In Settings > Connections, set Listen Addresses to include the WireGuard IP, for example: tcp://10.10.10.1:22000 (Server A) and tcp://10.10.10.2:22000 (Server B).

2) Optionally disable global discovery and relays for a pure VPN setup: turn off Global Discovery and Enable Relaying. This reduces external dependencies and noise.

Step 7: Pair the devices and add a synced folder

In the Syncthing Web UI on Server A, click Add Remote Device, paste Server B’s Device ID, and save. Do the same in the other direction if it doesn’t auto-accept. Then add a folder such as /srv/sync on Server A and share it with Server B. On Server B, accept the share and choose the local path where files should land.

If you’re syncing application data, be mindful of file locks and databases. For PostgreSQL/MySQL, sync dumps or backups instead of live database files. For configs, scripts, and documents, Syncthing is a perfect fit.

Step 8: Firewall tips for a locked-down setup

At minimum, allow WireGuard UDP on the server that listens publicly (Server A in this example). With UFW:

sudo ufw allow 51820/udp

You do not need to expose Syncthing ports to the internet if it’s bound to the WireGuard IP. If you manage Syncthing’s UI remotely, use SSH port forwarding rather than opening the GUI port globally.

Troubleshooting checklist

No tunnel connection: verify public IP/port, confirm keys, and check sudo wg show for latest handshake times.

Devices don’t see each other: confirm Syncthing is listening on the WireGuard IP and that you used the correct Device IDs. Test with nc -vz 10.10.10.2 22000 across the tunnel.

Permissions problems: ensure the Syncthing service user can read/write the synced folder. Fix with ownership or ACLs.

Final notes

With Syncthing running over WireGuard, you get a clean and modern file sync stack: encrypted transport, stable addressing, and continuous synchronization without exposing extra services to the public internet. This approach scales nicely as you add more servers—just add peers to WireGuard and devices to Syncthing, then share the folders you need.

How to Build a Reliable File Sync System with Syncthing on Windows and Linux (No Cloud Required)

Why Syncthing is a Smart Alternative to Cloud Sync

If you want Dropbox-style file synchronization without handing your data to a third-party cloud, Syncthing is one of the most practical tools available today. It is open-source, uses strong encryption, and syncs files directly between your devices. That makes it ideal for IT pros, homelab users, and small teams that need fast and private file replication across Windows and Linux systems.

This tutorial walks you through a modern, stable setup: installing Syncthing on Windows and Linux, pairing devices securely, setting up reliable folder sync, and applying best-practice tweaks for performance and safety. You will end up with a “set it and forget it” file synchronization system that works on your LAN and also remotely.

What You Need Before You Start

Before configuring anything, prepare the basics. You need at least two devices (for example, a Windows 11 workstation and an Ubuntu server), a stable network connection, and permission to install software. If your devices will sync over the internet (not just on the same LAN), you should also have access to your router/firewall settings for optional port forwarding.

Syncthing does not require a central server. Each device runs the same software and participates equally. The only thing you must protect carefully is the device pairing process, because that determines which machines are trusted to access your data.

Step 1: Install Syncthing on Windows

On Windows, the cleanest approach is to use the official Syncthing for Windows package. Download it from the official site and extract it into a dedicated folder such as C:\Syncthing. Launch syncthing.exe once to initialize the configuration and open the web interface.

To make Syncthing reliable, configure it to run automatically. A common method is to install it as a background startup task using Windows Task Scheduler. Create a task that runs at user logon (or at system startup if appropriate), points to syncthing.exe, and uses the “Run whether user is logged on or not” option for always-on syncing.

Step 2: Install Syncthing on Linux (Systemd Service)

On modern Linux distributions, installing Syncthing from your package manager is straightforward. After installation, enable it as a user service so it restarts automatically after reboots. This gives you a robust “daemon-like” setup without needing a desktop session.

Once enabled, the Syncthing web UI typically binds to 127.0.0.1:8384 by default. If you are managing a headless server, use SSH port forwarding to access it securely from your workstation rather than exposing the UI publicly.

Step 3: Secure the Web Interface (Do This Early)

Open the Syncthing web interface and go to settings. Set a strong GUI username and password. Even if you only plan to use it on your LAN, credentials prevent accidental access and reduce risk if a port is ever opened incorrectly.

If you must access the GUI from another machine, avoid binding it to all interfaces unless you have a clear firewall rule and a trusted network. In many environments, SSH tunneling is the safest and simplest choice.

Step 4: Pair Your Devices (Trusted Device Setup)

Each Syncthing node has a unique Device ID. To connect two systems, add one device to the other using this ID. In the web UI, choose “Add Remote Device,” paste the Device ID, and give it a recognizable name like Win-Workstation or Ubuntu-NAS.

When the second device receives the pairing request, accept it. At this point, the devices can communicate securely. Syncthing uses encrypted transport and validates identities using those Device IDs, which is why you should only exchange IDs over a trusted channel (not in public chat logs).

Step 5: Create and Share a Sync Folder

Now create a folder on the first device. Click “Add Folder,” set a clear folder label (for example, Projects), and select a folder path such as D:\Projects on Windows or /srv/sync/projects on Linux.

When adding the folder, choose which remote device(s) should receive it. On the receiving device, Syncthing will prompt you to accept the shared folder and choose a local path. Be careful here: selecting the wrong directory can cause files to sync into an unexpected location and create confusion later.

Step 6: Choose the Right Folder Type (Send/Receive vs One-Way)

Syncthing offers multiple folder types. For most two-way collaboration, use Send & Receive. If you want a one-way replica (for example, a workstation pushing data to a Linux backup box), configure the source as Send Only and the target as Receive Only. This prevents accidental deletions or edits on the backup side from syncing back and damaging your primary copy.

For important data, one-way replication is often safer. It behaves like a continuous mirroring job, but still gives you Syncthing’s speed, versioning options, and cross-platform support.

Step 7: Improve Reliability with Versioning and Ignore Rules

If you want protection against accidental deletion or ransomware-like mass changes, enable File Versioning in the folder settings. A common choice is “Staggered File Versioning,” which keeps older versions for longer periods. This is not a full backup solution, but it can save you when a file is overwritten or removed by mistake.

Also consider ignore patterns. You can exclude temporary files, caches, and build outputs that don’t belong in a sync workflow. Ignoring unnecessary files reduces CPU load, database size, and sync churn.

Step 8: Network and Firewall Tips (LAN and Remote Sync)

On a typical LAN, Syncthing works with no firewall changes because it can discover peers automatically. For remote syncing, it can still work using Syncthing’s relay system, but performance is usually better with direct connections.

If you control both ends and want consistent direct connectivity, you can forward Syncthing’s default listening port 22000/TCP to the internal device. Keep security in mind: only forward what you must, and ensure the GUI port is not exposed. In business environments, a VPN is often the cleaner solution for remote syncing.

Quick Troubleshooting Checklist

If syncing is not happening, start with simple checks. Confirm both devices show “Connected” in the web UI, verify you accepted the folder share on the target device, and make sure the folder paths actually exist and have correct permissions. On Linux, permission issues are a frequent cause of “out of sync” behavior.

If devices are “Disconnected,” check local firewalls, confirm both systems have correct time settings, and try disabling and re-enabling the connection. You can also review Syncthing logs in the web UI to identify port conflicts, rejected connections, or permission errors.

Final Notes: Sync is Not a Backup

Syncthing is excellent for real-time file replication, but it is not a complete backup strategy by itself. If you need disaster recovery, pair this setup with periodic offline backups or immutable snapshots. A strong combo is Syncthing for fast syncing plus a separate backup tool for long-term retention.

With the steps above, you now have a secure, cloud-free synchronization system that runs on Windows and Linux, survives reboots, and can be tuned for two-way collaboration or one-way protected replication.

3.

Popular Posts

Install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Install Ollama + Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Install a Local AI Chatbot on Ubuntu 24.04 with Ollama and Open WebUI (Step-by-Step)

Trending Now

Recovering from Btrfs Boot Failures Using GUI Tools on Fedora

By the end of this guide the reader will be able to identify a Btrfs‑based Fedora installation, boot from a live USB, list and restore snapshots using the graphical utilities btrfs‑assistant and snapper, and verify that the system returns to a functional state without resorting to the command line. Understanding the Btrfs Layout Used by Fedora Fedora Workstation and Fedora KDE install the root filesystem as a single Btrfs partition that contains two default sub‑volumes. One sub‑volume holds the traditional “/” hierarchy, while the second is dedicated to /var/lib/machines . The latter exists to keep container images out of snapshot operations; it remains empty on systems that do not run virtual machines. Because Btrfs stores data in sub‑volumes rather than separate partitions, a snapshot captures the state of an entire sub‑volume at a point in time. The installer (Anaconda) automatically registers these sub‑volumes with the snapper service. Snapper maintains a series of read‑only ...