Compare · File-transfer primitive
Bowline vs rsync
rsync is a file-transfer primitive. 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 rsync is. rsync is the classic, universal Unix utility for fast, incremental one-way file transfer over SSH. It is GPL-licensed, installed nearly everywhere, and known for a delta algorithm that sends only what changed. It is the DIY baseline: "I'll just rsync it to the server."
How it works. You run rsync, often from a script or cron and sometimes wrapped with a watcher like lsyncd, to push a directory from one host to another. It computes deltas and transfers only changed blocks. It is one-way per invocation, with no continuous watching, no two-way merge, and no conflict model, and it has no env or agent awareness of its own.
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 rsync, point by point
Every row uses the same dimensions. bowline's column is on the left; rsync's on the right.
| Dimension | Bowline | rsync |
|---|---|---|
| Where your code lives | Real local directories on every machine, kept in sync automatically. | Real files too, but you run the copy; nothing is watching or reconciling. |
| Laptop stays first-class | Yes. Every machine is a peer. | Whatever you script. There is no model of peers, just a source and a destination. |
| Works offline | Automatic conflict record, both versions kept. | None. Re-run the transfer; the last run wins and reverse edits can be overwritten. |
| Code-aware sync | Yes. node_modules and caches stay local, and lockfiles are respected. | No. You hand-write --exclude rules per invocation. |
| Git working state | Synced coherently by default. | Copies bytes; a mid-write .git can transfer inconsistently. Not Git-aware. |
| Env & secrets | Env and secrets follow the project, encrypted, on trusted devices only. | You would scp or rsync .env yourself: unmanaged, and unencrypted at rest on the target. |
| Coding agents | First-class leases plus bowline review / bowline accept. | None. |
| Setup & config | One install, then open a folder. | Write and maintain the rsync command, its excludes, and any watcher or cron around it. |
| Trust & encryption | Encrypted relay, revocable per-device trust, recovery keys you hold. | Rides SSH, with proven transport trust, but no workspace encryption at rest and no device model. |
| Price | Free Solo tier; Pro at $12/mo (as of 2026-07-01). | Free. |
| Open source | Apache 2.0 CLI and daemon. | GPL, universal and proven. |
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 rsync is the better choice
No tool wins every case. Pick rsync when these are true; we would too.
- You need a one-off or scripted one-way transfer and nothing continuous.
- You want the most universal, zero-install tool, already on virtually every box.
- Delta-transfer efficiency for large files over a thin link is your priority.
- You explicitly do not want any daemon, relay, or account, just a command you fully control.
Who should choose Bowline
If these fit, bowline is the tool rsync is not trying to be.
- Two-way and continuous by default, with no cron, no lsyncd, and no "which direction did I last run it?"
- Real conflict handling instead of one-way last-write-wins that can silently clobber edits made on the other side.
- Collapses the rsync + lsyncd + scp-the-.env + git-handling stack into one thing that just works.
- Code-aware and agent-aware, which a raw file-copy tool cannot be.
Moving from rsync
If your setup is an rsync command (maybe wrapped in lsyncd or cron) plus a separate step to copy .env, bowline replaces the whole stack with one workspace that watches, syncs two ways, handles conflicts, and carries env and Git state. Your files stay real files, so you can keep the rsync script as a fallback while you try it.
Bowline vs rsync: FAQ
The questions developers ask when weighing bowline against rsync.
Isn't rsync good enough for syncing code to a server?
For a one-way, one-off push, rsync is excellent and universal. It becomes glue when you want continuous two-way sync: you end up adding lsyncd or cron, hand-writing --exclude rules, scp-ing .env separately, and hoping you never run it the wrong direction. Bowline collapses that stack into one workspace that watches, syncs both ways, and handles conflicts.
Does Bowline use rsync internally?
No. Bowline has its own open-source sync engine, encrypted relay, and per-device trust model. It is not an rsync wrapper, though it shares rsync's goal of moving only what changed.
Can rsync handle two machines editing the same file?
Not really. rsync is one-way per run, so the last transfer wins and edits on the other side can be silently overwritten. Bowline records an explicit conflict and keeps both versions, so offline edits on two machines are not lost.
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.