Receive-Only and Send-Only Folders
Syncthing's default folder type (sendreceive) allows any peer to make changes and have them propagate everywhere. For production architectures, you often need one-way data flow — a build server that distributes assets, or a backup node that never writes back.
Map your real-world data flow requirements to the correct folder type before creating a folder pair. Changing folder types after sync has begun can cause unexpected behavior.
| Folder Type | This Device Can Send | This Device Can Receive | Use Case |
|---|---|---|---|
sendreceive | ✅ | ✅ | Standard bilateral sync (default) |
sendonly | ✅ | ❌ | Source of truth — distributes to peers |
receiveonly | ❌ | ✅ | Passive mirror, audit copy, backup node |
receiveencrypted | ❌ | ✅ encrypted blobs | Untrusted node — stores but cannot read |
Send-Only Folders
Use when this device is the authoritative source and should never accept changes from peers:
<folder id="dist-assets" path="/var/www/html/dist" type="sendonly">
<device id="VPS1-DEVICE-ID"></device>
<device id="VPS2-DEVICE-ID"></device>
</folder>
In the GUI: Folder → Edit → Advanced → Folder Type → Send Only.
On a sendonly folder, if a peer deletes or modifies a file, Syncthing will not propagate those changes back to the source. However, it will show a warning that the remote is "out of sync." This is expected and can be ignored.
Receive-Only Folders
Use when this device should never originate changes — only receive what the source sends:
<folder id="dist-assets" path="/var/www/html/dist" type="receiveonly">
<device id="BUILD-SERVER-DEVICE-ID"></device>
</folder>
If you make local changes on a receiveonly device, they appear as "local additions" in the GUI. Use "Revert Local Changes" to wipe them and restore the source state.
# Via REST API — revert local changes on a receiveonly folder
STKEY="your-api-key"
CERT="$HOME/.local/share/syncthing/https-cert.pem"
curl -s -X POST \
-H "X-API-Key: $STKEY" \
"https://localhost:8384/rest/db/revert?folder=dist-assets" \
--cacert "$CERT"
Receive-Encrypted Folders
The most powerful pattern for untrusted backup nodes. The backup node stores encrypted blobs it cannot read — even if the node is compromised, file contents remain secret.
Setup on the Primary Device
- Open the folder → Edit → Sharing
- For the backup node, enable "Encrypt communications with this device"
- Set a unique folder encryption password — this is different from the GUI password
<folder id="private-docs" path="/home/user/Documents" type="sendreceive">
<device id="BACKUP-NODE-ID" encryptionPassword="your-folder-encryption-pass"></device>
<device id="TRUSTED-PEER-ID"></device> <!-- normal sync, no encryption password -->
</folder>
Setup on the Backup Node
<folder id="private-docs" path="/mnt/backup/private-docs" type="receiveencrypted">
<device id="PRIMARY-DEVICE-ID"></device>
</folder>
The backup node syncs encrypted blobs. To restore, you need access to a device that holds the encryption key.
Practical Patterns
| Scenario | Primary Type | Secondary Type |
|---|---|---|
| CI/CD asset distribution | sendonly | receiveonly on all CDN nodes |
| Audit archive | sendreceive | receiveonly (read: never delete) |
| Cloud backup without trust | sendreceive | receiveencrypted on cloud VPS |
| Developer laptop → prod read-only | sendonly (laptop) | receiveonly (prod) |
Common Mistakes
| Mistake | Effect | Fix |
|---|---|---|
Using sendonly but forgetting receiveonly on peers | Peers ignore your changes — out-of-sync warning forever | Set receiving peers to receiveonly |
Editing files on a receiveonly node | Creates "local additions" that will be reverted | Never write to receiveonly folders manually |
Losing the encryption password for receiveencrypted | Cannot restore data — blobs are unreadable | Store encryption password in a password manager, separately from device credentials |