Syncthing on FreeBSD: Decentralized File Sync Review

Syncthing is a peer-to-peer file synchronization tool that works without a central server. Files stay on your machines. There is no cloud account, no subscription, and no third party handling your data. On FreeBSD, Syncthing runs as a daemon, synchronizes folders between devices over TLS, and handles conflict resolution automatically. This review covers installation, configuration, networking, performance, and how it compares to rsync and Nextcloud for FreeBSD sysadmins.

If you are considering Nextcloud instead, see our Nextcloud FreeBSD setup guide.

The Case for Syncthing

Most file sync solutions depend on a central server: Nextcloud, Seafile, ownCloud, or a commercial cloud provider. Syncthing eliminates that dependency. Devices connect directly, negotiate which files need syncing, and transfer data over encrypted connections.

This matters for sysadmins who:

Need to sync configuration files, scripts, or documentation between servers
Want encrypted sync between offices without routing through the cloud
Need to replicate data directories between FreeBSD hosts
Want a Dropbox replacement that runs entirely on infrastructure they control

Syncthing is written in Go, cross-platform (FreeBSD, Linux, macOS, Windows, Android), and has been in active development since 2013.

Installation

Binary Package

sh
pkg install syncthing

This installs the syncthing binary and the rc.d script.

Ports

sh
cd /usr/ports/net/syncthing
make install clean

Service Configuration

Enable Syncthing for a specific user. Running as root is not recommended:

sh
sysrc syncthing_enable="YES"
sysrc syncthing_home="/home/syncuser/.config/syncthing"
sysrc syncthing_user="syncuser"
sysrc syncthing_group="syncuser"

Start the service:

sh
service syncthing start

Web GUI Access

By default, Syncthing listens on 127.0.0.1:8384. To access it remotely during initial setup:

sh
# SSH tunnel from your workstation
ssh -L 8384:127.0.0.1:8384 syncuser@freebsd-host

Then open http://localhost:8384 in your browser. Set a GUI password immediately.

To allow direct remote access (after securing with authentication):

Edit ~/.config/syncthing/config.xml and change the GUI listen address:

xml
<gui enabled="true" tls="true" debugging="false">
    <address>0.0.0.0:8384</address>
    <user>admin</user>
    <password>$2a$10$...</password>
</gui>

Or use the CLI:

sh
syncthing cli config gui address set 0.0.0.0:8384

Core Concepts

Devices

Each Syncthing instance has a unique device ID derived from its TLS certificate. Device IDs look like MFZWI3D-BONSGYC-YLTMRWG-C43ENR5-QXGZDMM-FZWI3DP-BONSGYC-YLTMRWA. You exchange device IDs to establish trust between machines.

Folders

Folders are the unit of synchronization. Each folder has a unique ID, a local path, and a list of devices it is shared with. A folder can be:

Send & Receive: Full bidirectional sync (default)
Send Only: This device pushes changes but ignores remote changes
Receive Only: This device pulls changes but does not push local changes

Device Pairing

To connect two FreeBSD hosts:

On host A, get the device ID:

sh
syncthing cli show system | grep myID

On host B, add host A as a device via the web GUI or CLI:

sh
syncthing cli config devices add --device-id "MFZWI3D-..."

On host A, accept the connection request (appears in the web GUI) or pre-add host B's device ID.

Create a shared folder on both devices with the same folder ID.

Adding a Shared Folder via CLI

sh
# Create the folder
mkdir -p /data/shared

# Add it to Syncthing
syncthing cli config folders add --id "shared-data" --path "/data/shared"

# Share with a remote device
syncthing cli config folders "shared-data" devices add --device-id "MFZWI3D-..."

Configuration Deep Dive

Syncthing's configuration lives in ~/.config/syncthing/config.xml (or wherever syncthing_home points). Key settings:

Listen Addresses

xml
<listenAddress>tcp://0.0.0.0:22000</listenAddress>
<listenAddress>quic://0.0.0.0:22000</listenAddress>

Syncthing uses TCP and QUIC on port 22000 by default. QUIC provides better performance on lossy connections.

Connection Limits

xml
<maxSendKbps>0</maxSendKbps>
<maxRecvKbps>0</maxRecvKbps>

Set bandwidth limits if Syncthing should not saturate the network link. Values are in kilobytes per second. Zero means unlimited.

Ignore Patterns

Create a .stignore file in any synced folder:

shell
// Ignore temporary files
*.tmp
*.swp
~*

// Ignore OS metadata
.DS_Store
Thumbs.db

// Ignore specific directories
/backup
/cache

File Versioning

Syncthing can keep old versions of modified or deleted files:

xml
<versioning type="staggered">
    <cleanupIntervalS>3600</cleanupIntervalS>
    <param key="maxAge" val="2592000"></param>
    <param key="cleanInterval" val="3600"></param>
    <param key="versionsPath" val="/data/syncthing-versions"></param>
</versioning>

Staggered versioning keeps versions at increasing intervals: one per hour for the first day, one per day for the first month, one per week for the first year.

Other versioning types: simple (keep N copies), trashcan (move to .stversions), and external (call a script).

Networking

Direct Connections

Syncthing discovers peers via:

Local discovery: UDP broadcast on port 21027 on the local network
Global discovery: Queries Syncthing's discovery servers to find device addresses
Static addresses: Manually configured in device settings

For servers with known addresses, disable discovery and configure static addresses:

xml
<device id="MFZWI3D-..." name="server-b">
    <address>tcp://10.0.0.2:22000</address>
</device>

Relay Servers

When direct connections fail (NAT, firewalls), Syncthing falls back to relay servers. Data is encrypted end-to-end, but relays add latency and throughput limitations.

For internal networks, disable relays:

sh
syncthing cli config options relays-enabled set false

Firewall Rules

If using PF:

sh
# /etc/pf.conf
pass in on em0 proto tcp to port 22000
pass in on em0 proto udp to port {21027, 22000}
pass in on em0 proto tcp to port 8384  # Web GUI (restrict source)

Running Your Own Relay

For organizations that need relay capability without using public relays:

sh
pkg install syncthing-relaysrv

sysrc syncthing_relaysrv_enable="YES"
service syncthing-relaysrv start

Configure clients to use your relay by setting the relays option in config.xml.

Performance Characteristics

Throughput

Syncthing is not the fastest file transfer tool. On a direct gigabit LAN between two FreeBSD hosts:

Small files (10,000 files, 1 KB each): ~5-10 minutes for initial sync
Large files (10 files, 1 GB each): ~2-3 minutes for initial sync
Typical mixed workload: 200-400 Mbps sustained transfer

The overhead comes from hashing, metadata exchange, and the block-based transfer protocol. For bulk one-time transfers, rsync is faster. Syncthing's value is in continuous synchronization.

CPU and Memory

Syncthing's resource usage scales with the number and size of synced files:

10,000 files: ~50 MB RSS, minimal CPU when idle
100,000 files: ~200 MB RSS, noticeable CPU during rescans
1,000,000+ files: ~1 GB+ RSS, significant rescan overhead

Tuning for Large Datasets

Edit config.xml or use the CLI:

sh
# Increase rescan interval (seconds) for large folders
syncthing cli config folders "shared-data" rescan-interval-s set 3600

# Enable filesystem watching (inotify equivalent on FreeBSD uses kqueue)
syncthing cli config folders "shared-data" fs-watcher-enabled set true

FreeBSD uses kqueue for filesystem events. This works well but has limits on the number of watched files. For very large directories, increase kern.maxfiles:

sh
sysctl kern.maxfiles=200000

ZFS Considerations

Syncthing works well on ZFS, but be aware of:

Atime: Disable atime on synced datasets (zfs set atime=off pool/data). Syncthing triggers many reads that update atime needlessly.
Snapshots: Syncthing's .stversions directory and ZFS snapshots are redundant. Choose one versioning strategy.
Compression: Enable LZ4 compression on datasets. Syncthing stores files as-is, and ZFS compression reduces actual disk usage.
Deduplication: Do not enable ZFS dedup for Syncthing folders. The dedup table memory overhead is not justified.

sh
zfs create -o compression=lz4 -o atime=off zpool/syncthing

Comparison with Alternatives

Syncthing vs rsync

rsync is a one-way synchronization tool. You push or pull files between hosts. There is no continuous sync, no conflict resolution, and no web interface. rsync is better for backups and batch transfers. Syncthing is better for continuous bidirectional sync.

| Feature | Syncthing | rsync |

|---------|-----------|-------|

| Direction | Bidirectional | Unidirectional |

| Continuous | Yes | No (cron) |

| Encryption | TLS built-in | SSH tunnel |

| Conflict resolution | Yes | No |

| GUI | Web UI | None |

| Speed (bulk) | Moderate | Fast |

| Complexity | Low | Low |

Syncthing vs Nextcloud

Nextcloud is a full collaboration platform with file sync, calendar, contacts, and apps. It requires a web server, database, and PHP. Syncthing is purely file sync with zero server infrastructure.

| Feature | Syncthing | Nextcloud |

|---------|-----------|-----------|

| Architecture | Peer-to-peer | Client-server |

| Infrastructure | None | Web server + DB |

| File sync | Yes | Yes |

| Calendar/contacts | No | Yes |

| Web file access | No | Yes |

| Mobile apps | Android | iOS + Android |

| Maintenance | Minimal | Significant |

Choose Syncthing when you only need file sync and want zero infrastructure. Choose Nextcloud when you need a collaboration platform.

Security

Encryption

All connections between Syncthing devices use TLS 1.3. Device IDs are derived from TLS certificates, providing mutual authentication. The protocol is well-audited and there have been no major security vulnerabilities in the transport layer.

Untrusted Devices

Syncthing supports encrypting folder data before sending it to a device. This lets you use an untrusted remote server as a backup target:

sh
syncthing cli config folders "shared-data" devices "UNTRUSTED-ID" encryption-password set "strongpassword"

The remote device stores encrypted blobs and cannot read the file contents.

Access Control

Syncthing has no concept of user permissions within a shared folder. All devices sharing a folder have full read/write access (unless configured as send-only or receive-only). Implement access control at the filesystem level or by creating separate folders for different access levels.

Verdict

Syncthing does one thing well: decentralized file synchronization. The FreeBSD package works reliably, kqueue-based file watching is efficient, and the TLS encryption is solid. For sysadmins who need to keep directories in sync across FreeBSD hosts without a central server, it is the best option available.

Its limitations are clear: it is not a backup tool, it does not replace a full collaboration platform, and performance degrades with very large file sets. But within its scope, it is well-engineered and low-maintenance.

Rating: 8/10 -- Excellent at its core task. Minor deductions for performance overhead on large datasets and limited access control.

Frequently Asked Questions

Does Syncthing work inside a FreeBSD jail?

Yes. Syncthing does not require any special kernel features. Install it in a jail, expose port 22000, and it works. Use nullfs mounts to sync directories that exist outside the jail.

How do I handle conflicts?

When two devices modify the same file simultaneously, Syncthing renames one copy with a .sync-conflict suffix. Check for conflict files periodically:

sh
find /data/shared -name "*.sync-conflict-*" -type f

Resolve conflicts manually. There is no automatic merge.

Can I sync between FreeBSD and Windows?

Yes. Syncthing is cross-platform. Install the Windows client, pair devices, and sync works transparently. Be aware of filename restrictions on Windows (no :, *, etc.) and case sensitivity differences.

How do I automate Syncthing configuration?

The REST API is available at http://localhost:8384/rest/. Use it for automation:

sh
curl -s -H "X-API-Key: YOUR_API_KEY" http://localhost:8384/rest/system/config

The API key is in config.xml.

What happens if a device is offline for a long time?

When the device comes back online, Syncthing calculates differences and syncs only changed files. There is no time limit on how long a device can be offline. The sync will simply take longer if many files have changed.

Can Syncthing replace ZFS replication?

No. ZFS replication (zfs send | zfs receive) preserves snapshots, permissions, and dataset properties. Syncthing syncs file contents only. Use ZFS replication for disaster recovery and Syncthing for live file synchronization where both sides need read/write access.