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.

Learning Focus

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.

Tool Snapshot

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:

flowchart LR
  BUILD[Build Server\nsendonly] -->|distributes| VPS1[VPS 1\nreceiveonly]
  BUILD -->|distributes| VPS2[VPS 2\nreceiveonly]
  VPS1 -.->|changes ignored| BUILD

config.xml — send-only folder
<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.

warning

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:

config.xml — receive-only folder
<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.

revert-local-changes.sh
# 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.

flowchart LR
  PRIMARY[Primary Device\nHolds encryption key] -->|encrypted blobs only| BACKUP[Untrusted Cloud VPS\nreceiveencrypted]
  PRIMARY -->|normal sync| SECONDARY[Trusted Secondary\nsendreceive]

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

config.xml — encrypt for a specific peer
<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

config.xml — 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

Send-Only Folders​

Receive-Only Folders​

Receive-Encrypted Folders​

Setup on the Primary Device​

Setup on the Backup Node​

Practical Patterns​

Common Mistakes​

What's Next​