Selective Sync Strategies

Real-world deployments rarely need to sync the entire contents of a folder identically to every device. Selective sync lets you control which files go where using folder structure, device-specific ignores, and folder types.

Core Idea

Syncthing does not have a native "download only these paths" mode like some cloud clients. Instead, you achieve selective sync through a combination of multiple folder pairs, ignore rules, and folder types.

Strategy 1: Multiple Folder Pairs

Instead of one large folder, split data into several focused folders and share each folder only with the devices that need it.

Example: Photography workflow

/photos/
├── raw/       ← Heavy files, only sync between NAS and Workstation
├── exports/   ← Sync to Phone and Tablet too
└── archive/   ← Only on NAS (no sync to other devices)

Syncthing configuration:

• Folder raw → shared between NAS + Workstation only
• Folder exports → shared between NAS + Workstation + Phone
• Folder archive → not shared (only on NAS)

Benefit: Fine-grained per-device control with zero complexity in ignore rules.

Strategy 2: Device-Specific stignore via #include

When you need the same folder on multiple devices but want each device to ignore different paths:

/data/project/.stignore (synced to all)

// Global excludes for everyone
*.tmp
*.log

// Pull each device's local-only ignores
#include .stignore-local

Each device has its own .stignore-local (which is itself in .stignore so it never syncs):

.stignore

// Prevent local files from being synced
.stignore-local

/data/project/.stignore-local on the VPS server

// VPS doesn't need build tools
node_modules/
.venv/
dist/

/data/project/.stignore-local on the developer laptop

// Laptop doesn't need server-generated reports
/reports/server-generated/

Strategy 3: Receive Only as a Read Replica

Configure a device as Receive Only to create a one-way mirror without needing complex ignore rules.

flowchart LR
  MASTER[Master Node\nSend Only] --files--> NAS[Replica Node\nReceive Only]
  MASTER --files--> LAP[Laptop\nReceive Only]

• The Master pushes everything it has.
• Replicas only receive data — they never push local edits or deletions back.
• If someone accidentally creates files locally on a Receive Only node, those files never affect the master.

Benefit: Zero-conflict, zero-risk read replicas. Great for media distribution, report delivery, or content publishing.

Strategy 4: Ignore Large Files on Low-Bandwidth Devices

Use .stignore-local on a mobile or low-bandwidth device to exclude large binary files, keeping only small working files:

.stignore-local (on mobile/low-bandwidth device)

// Skip video files — too large for mobile data
*.mp4
*.mkv
*.mov
*.avi

// Skip RAW photos — only need exports
/raw/

// Skip archives
*.zip
*.tar.gz
*.7z

The desktop and server still sync everything. The mobile device gets only the lightweight files.

Strategy 5: Sync on a Schedule Using Folder Pause

For near-real-time sync but with bandwidth windows (e.g., only sync at night):

sync-schedule.sh

API_KEY="YOUR_API_KEY"
FOLDER_ID="uploads-prod"
BASE="http://127.0.0.1:8384"

# Pause sync (run at start of business hours)
curl -s -X POST "${BASE}/rest/db/pause?folder=${FOLDER_ID}" \
  -H "X-API-Key: ${API_KEY}"

# Resume sync (run at night)
curl -s -X POST "${BASE}/rest/db/resume?folder=${FOLDER_ID}" \
  -H "X-API-Key: ${API_KEY}"

Combine with a systemd timer to automate the schedule.

Comparing the Strategies

Strategy	Setup Complexity	Best For
Multiple folder pairs	Low	Clearly separated data domains
Device-specific stignore	Medium	Same folder, different device needs
Receive Only replicas	Low	Read-only distribution, media sharing
Ignore large files per device	Low	Mobile or bandwidth-limited nodes
Schedule-based pausing	Medium	Bandwidth budgeting

What's Next

• TLS and Device Authentication