Why upload your files to someone else's server?
Your phone and your computer are already connected to the same network.
FerriSync lets them communicate directly:
Device A ←──────────→ Device B
your LANDevices discover and authenticate each other, then synchronize directly. Today, sync is LAN-only: your photos, documents, and projects never leave the hardware you control.
What that gets you
Private
Your files stay on your devices. Nothing is uploaded — ever.
Fast
Transfers go device-to-device at local-network speed, not upload speed.
No account
No signup, no cloud storage plan, no subscription.
Works offline
Your local network is enough. No internet required.
How it works
Discover
Devices find each other automatically on your network via mDNS — zero configuration, no central registry.
Pair once, then stay paired
Confirm the connection on either side. Devices exchange certificates and pin each other's fingerprint — after that they recognize each other automatically. Unknown devices always ask before they are let in.
Choose folders
Pick what should sync where, on each side. Peers exchange indexes and transfer only what changed.
Done — it stays in sync
A filesystem watcher pushes changes as you make them. Conflicts never destroy data: the newest version wins and the overwritten copy is preserved as a .bak file in the activity history.
See it in action
$ ferrisync Type 'help' for commands, 'exit' or Ctrl-D to quit. ferrisync> discover alice-phone._ferrisync._tcp.local. [192.168.1.23:9847] ferrisync> pair 192.168.1.23 Paired with alice-phone (a3f8…91c2) ferrisync> status Paired devices ● alice-phone 192.168.1.23:9847 online Folders ~/Documents ↔ alice-phone idle · last sync 12:04 ferrisync> exit
ferrisync> watch ~/Photos --device 192.168.1.23:9847 watch #1 started: ~/Photos ↔ 192.168.1.23:9847 (background) # edit files in another window… [watch:~/Photos] change detected, syncing... [watch:~/Photos] pushed 2, pulled 1, conflicts 0 ferrisync> unwatch 1 watch #1 stopped
$ ferrisync sync ~/Documents --device 192.168.1.23:9847 index exchange… 214 entries, 3 changed pushed report.pdf (1.2 MB) pulled budget.xlsx (96 KB) conflict todo.txt — edited on both devices kept newest copy, backup saved as todo.txt.bak done — 2 synced, 1 conflict resolved # every action lands in the activity history, on both ends
Why FerriSync?
Existing tools have proven that private peer-to-peer synchronization works. FerriSync explores a different approach, focusing on:
LAN-first
Designed around your local network, not the internet.
Simple pairing
Discover, tap, confirm — unknown devices ask before they connect.
A reusable engine
One small Rust core powering every client — embed sync in your own apps.
FerriSync vs the alternatives
| FerriSync | Cloud storage | |
|---|---|---|
| Your files stay local | ✓ | ✗ |
| Cloud account | ✗ | ✓ |
| Monthly fee | ✗ | Often |
| Direct LAN transfer | ✓ | Usually ✗ |
| Internet required | ✗ for sync | Usually |
| Open source | ✓ | Usually ✗ |
And vs Syncthing?
Syncthing is excellent and mature — if you need battle-tested, wide-platform sync today, use it. FerriSync is an early-stage project exploring a leaner take on the same idea: a simpler first-run experience, explicit pairing consent built in from day one, and one reusable core behind CLI, TUI, and Android clients instead of a monolithic daemon. If you want to watch — or build — a LAN-first alternative, that's FerriSync.
Private by construction, not by promise
TLS 1.3 everywhere
Every connection between devices is encrypted end-to-end.
Trust on first use
Certificates are generated locally on each device; fingerprints are pinned when you pair.
Explicit consent
Unknown devices cannot connect silently — they wait until you approve them.
BLAKE3 integrity
Content hashes decide what transfers and catch corruption.
No telemetry
No servers, no relays, no analytics, nothing phoning home.
Open source
AGPL-3.0 — audit exactly what happens to your data.
Built with Rust · TLS 1.3 · BLAKE3 · mDNS
Try the Developer Preview
Build FerriSync from source and run it on two devices connected to the same network (Rust 1.80+, about five minutes). No account needed.
# Linux / macOS / Windows
git clone https://github.com/DavidNeurieder/FerriSync.git
cd FerriSync && cargo build --release
# Interactive shell (default)
./target/release/ferrisync-tui
ferrisync> serve ~/Documents # host a folder on machine A
ferrisync> pair 192.168.1.42 # from machine B, then confirm on A
ferrisync> sync ~/DocumentsCopy --device 192.168.1.42
# Full-screen terminal UI
cargo run -p ferrisync-tui -- tui
# Android client (Flutter + flutter_rust_bridge)
cd ferrisync-flutter
flutter pub get
flutter_rust_bridge_codegen generate
flutter runDon't want to build? Packaged releases are on the near-term roadmap — star the repo to hear about them.
For developers
┌────────────────────┬───────────────────────┐
│ Flutter GUI │ TUI + CLI (ratatui) │
│ (mobile + desktop) │ interactive shell │
├────────────────────┴───────────────────────┤
│ ferrisync-core — sync engine │
│ discovery · protocol · storage · crypto │
├────────────────────────────────────────────┤
│ TcpTransport — TCP + TLS 1.3 (LAN) │
│ QuicTransport — internet (exploring) │
└────────────────────────────────────────────┘One engine, thin clients. ferrisync-core is a reusable
crate — embed sync in your own app instead of shelling out to a monolith.
The GUIs are just clients of the library.
mDNS discovery · TOFU pairing over TLS 1.3 · disk-index based bidirectional
sync with deterministic conflict handling (newer mtime wins, hash breaks ties, loser preserved as .bak)
Development
cargo fmt --all --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test # unit + black-box REPL tests
cd ferrisync-flutter && flutter testWhat's next?
Near term
- Packaged releases & installers
- Headless daemon with system tray
- Improved conflict handling UX
- Improved GUI / mobile UX
Exploring
- Version vectors
- Block-level incremental sync
- Internet sync via QUIC transport
Help shape FerriSync
FerriSync is early. We're looking for developers and technical users willing to test it across real devices, report problems, and help shape the synchronization model.