Syncthing for Homelab: Sync Files Between All Your Devices
Scale Syncthing past one laptop. Real folder-sharing strategy, versioning, and per-device ignore patterns for a mesh of laptops, phones, and a homelab server.
The basic Syncthing setup guide covers getting the container running and pairing one laptop to your server. That’s the easy part. The moment you add a second device, then a phone, then maybe a NAS, the questions change. Which folders go where? What happens when two devices edit the same file? Do you really want your entire vault syncing to a laptop you sometimes leave in a coffee shop?
This guide picks up where that one left off. I’m assuming Syncthing is already running on your homelab server (if it isn’t, go set that up first, it takes about ten minutes) and you’re ready to build out an actual multi-device mesh instead of a single pair.
Why your server should be the hub, not a spoke
Syncthing is peer-to-peer by design. Any device can talk to any other device directly, and there’s no requirement that traffic flows through a central point. In practice, for a homelab setup, you want to treat your always-on server as the hub anyway.
Here’s why. Your laptop is asleep half the day. Your phone is off Wi-Fi during the commute. Your desktop is powered down overnight. The server is the one device that’s always reachable, so it’s the one that should hold the canonical copy of every synced folder and relay changes between the devices that are never online at the same time.
Picture it as a star, not a mesh, even though the underlying protocol supports full mesh. Server in the middle. Laptop, phone, and anything else you add around the edges, each syncing to the server and, if you choose, to each other. My own setup follows this pattern: an Ubuntu VM as the hub syncing my Obsidian vault to a Mac, plus a one-way camera folder from an Android phone (the Immich + Syncthing guide covers that second piece in detail). Every device I’ve added since has plugged into the same hub instead of pairing directly with each other.
Map your devices before you touch a setting
Before adding a third or fourth device, write down two things for each one: what folders does it need, and in which direction should changes flow. This takes five minutes and saves you from the most common mistake, which is sharing everything to everything and then discovering a phone somehow has write access to a folder it should only be reading from.
A simple table works:
| Device | Folder | Direction |
|---|---|---|
| Homelab server | Obsidian vault | Send & Receive (hub) |
| Mac laptop | Obsidian vault | Send & Receive |
| Android phone | Camera roll | Send Only |
| Windows desktop | Obsidian vault | Send & Receive |
| Windows desktop | Downloads staging | Receive Only |
Notice the phone only sends. It never receives changes back, which means nothing you do on the server or laptop can ever wipe or alter the phone’s original camera roll. That one-way pattern from the Immich guide isn’t specific to photos; it’s the right default any time a folder’s source of truth lives on one device and everything else should just be a copy.
Adding a new device
Once you know what a device needs, adding it to the mesh is mechanical.
- Install Syncthing on the new device. Desktop OSes use the native app or a package manager install; mobile uses the Syncthing app (Android) or a third-party client (iPhone, with real limitations covered below.)
- On the new device, open Actions -> Show ID and copy the Device ID.
- On your server’s Syncthing web UI, go to Devices -> Add Remote Device, paste the ID, name it something you’ll recognize in six months (“Kid’s Old Laptop” beats “Device 4”), and save.
- Accept the pairing prompt that shows up on the new device.
- From the server, share only the specific folders that device needs. Don’t use “share all” shortcuts if your provider’s client offers one.
The devices are now paired but nothing syncs until you explicitly share a folder to the new pairing. That’s intentional. Pairing and folder-sharing are separate steps in Syncthing precisely so you can add a device to your network without immediately handing it access to everything.
Folder type matters more with three-plus devices
With two devices, Send & Receive on both ends is usually fine; you’re syncing your own files between your own laptop and your own server. Once you’re at three or more devices sharing the same folder, mixing folder types becomes the tool you use to keep things safe.
- Send & Receive: full read/write. Use this for devices you trust to make real edits, like your primary laptop and the server.
- Send Only: the device can push changes out but never receives them back. Use this for phones and any “source of truth” device where you don’t want a bad sync from elsewhere to alter the original.
- Receive Only: the device gets a passive copy and can’t push changes upstream. Use this for a secondary backup laptop, a media-viewing tablet, or any device that should just have a current copy without being able to affect the source.
Mixing these deliberately, rather than defaulting every device to Send & Receive, is the single biggest thing that separates a mesh that behaves predictably from one that occasionally eats a file because a stale laptop woke up and pushed six-month-old versions of everything.
File versioning: the safety net for a bigger mesh
The more devices touch a folder, the more chances there are for something to go wrong: an accidental delete, a bad merge, a laptop that reconnects after being off the network for a month and pushes outdated files. Versioning is what makes those events recoverable instead of catastrophic.
On the hub server, open a folder’s settings, go to the Versioning tab, and set Staggered File Versioning. It keeps a rolling set of old versions with more recent snapshots kept more densely and older ones thinned out over time, so you’re not burning unlimited disk space to keep every historical copy forever.
File Versioning: Staggered
Maximum Age: 90 (days)Ninety days is a reasonable default for most personal use. If disk space on your server is tight, drop it to 30. The versions live in a hidden .stversions folder inside the synced directory, so they’re easy to browse and restore from if you ever need to roll a file back.
Set this on the hub, not on every peripheral device. The server is the one place you want the safety net; you don’t need staggered versioning eating storage on a phone.
Ignore patterns need to be per-device, not global
The basic setup guide covers ignore patterns for a single folder. With multiple devices, remember that ignore patterns are set per folder, per device, not globally across your whole mesh. A pattern you add on your laptop doesn’t automatically apply on your desktop’s copy of the same shared folder.
If you want a consistent ignore list across every device syncing a folder, you have to add it on each one, or centralize the logic by only editing .stignore patterns on the hub and letting devices inherit through a shared root pattern file where practical. For most homelab setups this is a five-minute annoyance once, not an ongoing burden: set your node_modules/, .DS_Store, and temp-file patterns on each device the first time you add it, and you’re done.
Running Syncthing headless on a NAS or second box
Not every device in your mesh needs a monitor. If you’re adding a Synology, an Unraid box, or a second small server as a backup target, you’ll be running Syncthing without a desktop session.
- Synology: install via the Community Package source, or run the container manually if you’re on DSM 7+ with Container Manager.
- Unraid: the Community Applications plugin has a Syncthing template that mirrors the standard linuxserver.io image, same environment variables as the Docker Compose setup.
- Headless Linux (no desktop): install the native package and enable it as a systemd service so it survives reboots without a login session:
sudo apt install syncthing
sudo systemctl enable --now syncthing@youruserAll of these expose the same web UI on port 8384. Once it’s up, the pairing and folder-sharing steps are identical to any other device, browser instead of desktop app.
Bandwidth and battery, at mesh scale
One device syncing rarely causes problems. A handful of devices syncing simultaneously on a residential upload connection can. A few settings worth checking once your mesh grows past two or three devices:
- Rate limiting: under Settings -> Connections, you can cap outgoing and incoming rates. Useful if a large initial sync (say, a multi-hundred-gigabyte photo folder) is choking your connection for everything else in the house.
- Mobile sync conditions: in the Android app, restrict syncing to Wi-Fi only, and ideally to Wi-Fi plus charging, under the per-folder sync conditions. This matters more as you add folders; a single small vault barely touches battery, several gigabytes of photos syncing on cellular will.
- Scan intervals: the default full-folder rescan interval is fine for most homelab use. If you have a very large, rarely-changing archive folder, raising the interval reduces background CPU use on lower-power hardware without meaningfully delaying sync of actual changes, since Syncthing also watches the filesystem for real-time changes between scans.
A note on iPhone
If your mesh includes an iPhone, be realistic about what it can do. iOS sandboxing prevents true background folder sync, so there’s no native Syncthing app the way there is on Android. Third-party options like Möbius Sync exist and work for manual or app-foreground sync, but they can’t continuously watch the system camera roll the way the Android app can. For iPhone-heavy households, treat the phone as a manual sync point you open occasionally, not a background node in the mesh, and lean on Immich’s own mobile backup for continuous photo capture instead.
Keep an eye on the whole mesh
Once you’re past two devices, it’s worth knowing when a sync silently stalls instead of finding out three weeks later that your desktop hasn’t received a change since a router reboot. Uptime Kuma can monitor the Syncthing web UI’s HTTP endpoint on each device that runs one, which at least confirms the service is alive. For deeper mesh health, Syncthing’s own web UI shows each device’s last-seen timestamp on the Devices page; a quick weekly glance catches a device that’s silently fallen out of sync before it becomes a real gap.
Where this fits in the bigger picture
A multi-device Syncthing mesh is a convenience layer, not a backup strategy. It’s genuinely great for keeping a vault, a document set, or a photo folder current everywhere you work. It is not a substitute for point-in-time backups that protect you from deletions propagating across every synced copy at once. Pair this setup with the approach in the homelab backup strategy guide so you have both: files that follow you everywhere, and a real recovery path if something goes wrong.
For HTTPS access to the Syncthing web UI on every device instead of typing raw IPs and ports, the Nginx Proxy Manager guide and wildcard SSL setup cover getting a clean syncthing.yourdomain.com in front of it, and Authelia covers locking that down since the Syncthing UI has no real auth of its own.
See everything else running in this homelab at /stack/.