Compare · File-sync engine
Bowline vs Syncthing
Syncthing is a file-sync engine. bowline is developer workspace sync. They overlap on one job, keeping your code available on more than one machine, and diverge on nearly everything else. Here is the honest breakdown.
TL;DR
What Syncthing is. Syncthing is a free, open-source (MPL-2.0) continuous file-synchronization tool. It syncs folders directly between your devices peer-to-peer, with each device holding cryptographic trust and no central server or cloud account. It has a large, long-standing install base and a good reputation.
How it works. You pair devices by ID and share folders between them. Syncthing watches those folders and continuously replicates changes over an encrypted peer-to-peer connection. It syncs whatever bytes are in the folder; conflicting edits produce .sync-conflict-* copies you resolve by hand.
Where bowline differs. bowline keeps one real ~/Code in sync across every machine and agent. That covers source, opaque Git state, env and secrets, and agent leases, code-aware and with zero per-project config.
Bowline vs Syncthing, point by point
Every row uses the same dimensions. bowline's column is on the left; Syncthing's on the right.
| Dimension | Bowline | Syncthing |
|---|---|---|
| Where your code lives | Real local directories, code-aware. | Real local folders too, but replicated verbatim, whatever is inside them. |
| Laptop stays first-class | Yes. | Yes. Every device is a first-class peer, no VM. |
| Works offline | Divergence becomes one recorded conflict, both versions kept. | Diverging edits spawn .sync-conflict-* files you have to find and merge yourself. |
| Code-aware sync | Yes. node_modules and caches stay local, and lockfiles are respected. | No. It syncs node_modules and .git and thrashes on them unless you hand-maintain ignore patterns. |
| Git working state | Synced coherently by default. | Copies .git as raw files, which can transfer inconsistently mid-write. Not Git-aware. |
| Env & secrets | Env and secrets follow the project, encrypted, on trusted devices only. | No secrets concept. A .env in the folder is just another synced file, unmanaged. |
| Coding agents | First-class agent leases plus bowline review / bowline accept. | None. |
| Setup & config | One install, then open a folder. | Pair device IDs, share folders, and tune ignore patterns per folder. |
| Trust & encryption | Encrypted relay, explicit revocable per-device trust, recovery keys you hold. | Strong peer-to-peer crypto and per-device trust, a genuine strength, but no code or secret semantics on top. |
| Price | Free Solo tier; Pro at $12/mo (as of 2026-07-01). | Free and open source. |
| Open source | Apache 2.0 CLI and daemon. | MPL-2.0, fully open with a large community. |
Where your code actually lives
This is the fault line under most of the table.
With bowline, your code is ordinary local directories on every machine you use: real files on disk, not a mount, symlink trick, or remote filesystem. If bowline disappeared tomorrow, your code would still be sitting there as plain files. Nothing is trapped, and there is no lock-in to unwind.
bowline understands what those files are. node_modules and caches stay local and regenerate there, lockfiles are respected, and generated folders follow policy. On top of the source it carries the working state Git and file-sync tools leave behind: uncommitted and untracked edits, opaque Git internals, encrypted env and secrets, and agent leases.
When Syncthing is the better choice
No tool wins every case. Pick Syncthing when these are true; we would too.
- You want a purely peer-to-peer tool with no central relay or cloud account in the path, a real privacy win.
- You are syncing general files (documents, photos, media), not only code.
- You value a mature, widely-audited open-source project with a large install base.
- You are happy to maintain ignore patterns and you do not run coding agents on remote hosts.
Who should choose Bowline
If these fit, bowline is the tool Syncthing is not trying to be.
- Code-aware: node_modules and caches stay local instead of being replicated and thrashed device-to-device.
- No .sync-conflict-* litter: offline divergence is one explicit conflict record with both versions kept.
- Git working state stays coherent instead of .git being copied as raw bytes mid-write.
- Env, secrets, and agent leases are first-class objects with real semantics, beyond plain files in a folder.
Moving from Syncthing
Syncthing and bowline can coexist while you switch, since both leave real files on disk. The practical move is to stop pointing Syncthing at code folders, where node_modules and .git cause the most pain, and let bowline carry those instead. Keep Syncthing for general file sync if you like it.
Bowline vs Syncthing: FAQ
The questions developers ask when weighing bowline against Syncthing.
Will Bowline sync node_modules and .git the way Syncthing does?
No, and that is the core difference. Bowline is code-aware: node_modules and caches stay local and regenerate, and Git working state is carried coherently rather than by copying .git as raw bytes. Syncthing replicates whatever is in the folder unless you maintain ignore patterns.
Is Bowline peer-to-peer like Syncthing?
No, and it is a real trade-off. Syncthing is pure P2P with no central relay, which is a genuine privacy strength. Bowline routes encrypted workspace state through a relay so it can carry secrets and offer per-device trust and recovery keys. Files are encrypted in transit and at rest and only rematerialize on devices you approve.
What happens to Syncthing's .sync-conflict files under Bowline?
Bowline does not create them. Offline divergence becomes a single explicit conflict record that keeps both versions for you to resolve, instead of scattering .sync-conflict-* copies through the tree.
Your ~/Code, on every machine and every agent.
Install bowline and your projects follow you. It just works.
curl -fsSL https://install.bowline.sh | shmacOS app · Linux CLI. Then run bowline login.