FileSync

An honest look at what this MIT-licensed tool actually does — and what it doesn’t.

---

TL;DR

• What it is: A self-hosted web app for sending files between devices in real-time using peer-to-peer WebRTC — more like a self-hosted AirDrop than a sync tool [README][website].
• Who it’s for: Privacy-conscious individuals and small teams who want to move files between devices without creating accounts on WeTransfer, Google Drive, or similar SaaS — and who can spin up a Docker container [README].
• Cost savings: WeTransfer Pro runs ~$16/mo with storage limits. Self-hosted FileSync runs on a $5–10/mo VPS with no per-transfer limits and no file expiry.
• Key strength: Zero-account, zero-install file transfer with end-to-end encryption. Open a browser, share a room link, files move directly between devices [README][website].
• Key weakness: Despite the name, this is a transfer tool, not a sync tool. Files aren’t persisted anywhere. Once all parties close the tab, the session is gone. There are no third-party reviews of this specific tool, which signals how niche the use case is.

---

What is FileSync

FileSync (github.com/polius/filesync) is a browser-based file transfer application built on WebRTC. The pitch in the README is exactly one sentence: “Send files from one device to many in real-time” [README]. That’s an accurate description.

The mechanics: you open FileSync in a browser, get a room link, and share that link with other devices or people. They open the link, and files transfer directly between browsers using PeerJS — a WebRTC wrapper — without passing through any server [README][website]. The server’s only role is to broker the initial WebRTC handshake via STUN/TURN. Once the peer connection is established, the server steps out of the way entirely [website].

What you get from that architecture: end-to-end encryption by default (WebRTC encrypts in transit), no file size limits imposed by the software (only by your browser and RAM), no account creation, no app installation on the receiving end, and no files stored on your server [website]. Optional password protection on rooms is supported.

What you need to understand before deploying: FileSync is not Syncthing. It does not continuously monitor folders and keep two locations in sync [README]. It is closer in concept to Firefox Send (discontinued) or Snapdrop/PairDrop than to Nextcloud or Syncthing. If your mental model is “I want my phone’s photos to automatically appear on my laptop,” this is not the right tool. If your mental model is “I want to securely send a 4GB video from my laptop to a colleague’s machine without uploading it to Google Drive,” this is exactly the right tool.

The project sits at 1,138 GitHub stars under the MIT license, maintained by a single developer [merged profile].

---

Why People Choose It

There are no published third-party reviews of this specific tool — a fact worth flagging directly. The file transfer / file sharing category has hundreds of tools, and most coverage focuses on the bigger names: Syncthing, Nextcloud, Seafile, and the full-featured sync platforms listed across aggregator sites [2]. A narrow-scope WebRTC transfer tool at ~1,100 stars doesn’t attract tech press.

What the primary sources suggest about the appeal:

No-account receiving. The receiver needs nothing installed, no account, and no registration. They click a link and a browser tab opens. For anyone who has sent a “just create a Dropbox account” link to a non-technical family member and watched it fail, this matters.

Privacy of the transfer path. Files never touch the server. The WebRTC handshake server only sees metadata about who is connecting to whom, not what is being transferred [website]. For sensitive documents — financial records, legal files, medical data — that’s meaningfully different from uploading to WeTransfer, which stores the file on their servers for the link lifetime.

One-to-many. The room model supports multiple receivers simultaneously. You open one room, share one link, and multiple devices can join and download [README]. This is useful for distributing large files to multiple team members simultaneously without multiple uploads or email attachments.

The deployment breadth. The README includes Docker Compose configs for both HTTP (local/dev) and HTTPS (production with Caddy auto-SSL) setups [README]. Anyone who can run docker-compose up -d has this running in under 10 minutes.

---

Features

Core transfer:

• Browser-to-browser peer-to-peer file transfer [README]
• End-to-end encryption via WebRTC [README][website]
• One-to-one and many-to-many transfer in a single room [website]
• Room-based sharing: share a URL, receiver clicks it [README]
• Optional password protection per room [README]
• “Download all” bulk download on the receiver side [README]
• Display name customization per participant [README]
• Per-file download status tracking — sender can see who downloaded what [README]
• No account creation required for sender or receiver [website]
• No app installation required on any device [website]

Infrastructure:

• Docker and Docker Compose deployment [README]
• HTTP and HTTPS deployment paths included [README]
• Built-in STUN/TURN server (Coturn) for NAT traversal via port 3478 [README]
• Caddy for automatic Let’s Encrypt SSL in the HTTPS config [README]
• Configurable secret key for session security [README]

What’s not here:

• No persistent file storage — sessions are ephemeral
• No user accounts or authentication layer
• No folder sync or continuous monitoring
• No file versioning or history
• No mobile native apps (browser-only)
• No API

---

Pricing: SaaS vs Self-Hosted Math

FileSync has no SaaS pricing — the software is MIT and free. The website (filesync.app) appears to run a hosted demo instance.

The relevant comparison is against the SaaS tools people use to solve the same “send this file to someone” problem:

WeTransfer:

• Free: 2GB per transfer, files expire after 7 days, ads
• Pro: ~$16/mo, 200GB storage, larger transfers, no expiry
• WeTransfer Plus: ~$25/mo

Google Drive / Dropbox:

• Google Workspace Starter: $6/user/mo
• Dropbox Plus: ~$11.99/mo

Self-hosted FileSync:

• Software: $0 (MIT)
• VPS to run it on: $5–10/mo (Hetzner, Contabo)
• Your time to deploy: ~30 minutes if you’ve used Docker before

If your use case is “send files to people outside my organization without paying per-storage or dealing with account creation on both ends,” the self-hosted math is simple. $6–10/mo replaces $16–25/mo indefinitely, with no file expiry and no size limits imposed by the software.

The caveat that matters: this only makes sense if file transfer is actually your bottleneck. If you already pay for Google Workspace and people have Google accounts, Drive handles this for free. FileSync earns its place when the receiver cannot or should not create an account on any third-party service — client files, regulated industries, non-technical family members.

---

Deployment Reality Check

The README’s install path is Docker Compose, and it’s genuinely short [README]. The steps:

1. Download docker-compose.yml from the deploy/ folder
2. Generate a 32-byte base64 secret key with a one-liner Python command
3. Drop the secret key into two places in the compose file
4. docker-compose up -d

For HTTPS (production), you add a Caddyfile with your domain, switch to docker-compose-ssl.yml, and Caddy handles Let’s Encrypt automatically [README].

Port requirements — this is where non-obvious setup complexity lives:

• HTTP setup: port 80 (web) + port 3478 TCP and UDP (STUN/TURN for WebRTC)
• HTTPS setup: port 443 (web) + port 3478 TCP and UDP

Port 3478 is essential. WebRTC needs it to establish peer connections when devices are behind NAT or corporate firewalls [README]. If your VPS firewall or cloud security group doesn’t allow 3478 UDP, the transfer will fail silently for devices behind NAT — which is most home and office connections. This is the single most likely setup failure point. Open 3478 TCP+UDP before you test.

What can go sideways:

• Missing port 3478 means transfers silently fail for some clients (NAT traversal fails)
• The secret key must match in both places in the compose file — the README shows two <SECRET_KEY> placeholders that are easy to miss [README]
• Large files (multi-GB) put pressure on the receiver’s browser RAM since WebRTC streams into memory; not ideal for files over a few hundred MB on low-RAM devices
• No documented mechanism for limiting who can create rooms — the app is open to anyone who can reach your server URL

Realistic setup time:

• Experienced Docker user: 15–30 minutes including domain DNS propagation
• First-time Docker user: 1–3 hours including Linux VPS basics
• No Linux experience: needs help from someone technical

The setup is genuinely simpler than most self-hosted tools [README][5] — no database, no background workers, no external services beyond optional Caddy.

---

Pros and Cons

Pros

• True P2P — files never touch the server. The architectural choice is real, not marketing. Your server only sees who connects to a room; it never sees file contents [website][README]. This is a genuine privacy win over WeTransfer and similar services.
• Zero receiver friction. No account, no install, no consent checkbox, no 14-day trial. A link and a browser tab. Works on any device with a modern browser [website].
• MIT license. Fork it, embed it, modify it, run it in a regulated environment with custom branding. No commercial agreement needed [README].
• Docker Compose with HTTPS included. The HTTPS setup with automatic Caddy SSL is provided out of the box — you don’t have to figure out nginx configs or certbot renewal [README].
• One-to-many in a single session. One room link, multiple receivers, simultaneous transfers. No re-uploading per recipient [README].
• Built-in STUN/TURN server. Included in the Docker Compose, so NAT traversal works without signing up for a Twilio/Metered account [README].
• No database dependency. Stateless architecture means no Postgres, no Redis, no migrations. Fewer things to break, easier backups.

Cons

• Name is misleading. “FileSync” implies continuous synchronization. The tool does one-time room-based transfers. This mismatch will cause confusion for anyone evaluating it against Syncthing or Nextcloud [README][website].
• No persistence. When all parties close the tab, the transfer session is gone. No file history, no re-download links, no “check what was sent last Tuesday.”
• No access control. Anyone who can reach your server URL can create a room. There’s no user management, no admin interface, no IP allowlist built in [README].
• Large file fragility. WebRTC transfers into browser RAM. Transferring a 20GB video to a device with 4GB RAM will fail. Data not available on the exact limits, but this is a known WebRTC constraint.
• Port 3478 requirement is easy to miss. Not opening this port means transfers silently fail for NAT’d clients. The README mentions it, but it’s buried in the port requirements section [README].
• No mobile apps. Browser-only. iOS Safari’s WebRTC support has historically been inconsistent with some P2P scenarios — real-world experience on iOS is not documented in available sources.
• Small project, one maintainer. 1,138 stars and a single contributor. No SLA, no commercial backer, no enterprise support path [merged profile].
• No third-party reviews. Zero coverage from tech press or community review sites as of this writing. Hard to assess real-world reliability beyond what the README describes.

---

Who Should Use This / Who Shouldn’t

Use FileSync if:

• You regularly send files to clients, collaborators, or non-technical people who shouldn’t need to create accounts
• Your files contain sensitive data and you don’t want them stored on a third-party server, even temporarily
• You want a dead-simple answer to “how do I send you this file” that works from any browser
• You’re paying WeTransfer Pro and your use case is primarily transfer (not long-term cloud storage)
• You can deploy Docker and open two ports

Skip it if you need actual file sync:

• Continuous folder mirroring between devices → use Syncthing (free, no server needed)
• Team file storage with versioning → use Nextcloud or Seafile
• Photo library sync from phone → use Immich

Skip it if:

• You need receiver-side re-download links that persist longer than the session
• Files are routinely over 2–3GB (RAM pressure on receiving devices)
• You need access control or audit logs for compliance
• Your org’s firewall policy makes UDP 3478 outbound problematic
• You want mobile native apps with background transfer support

---

Alternatives Worth Considering

• Syncthing — continuous bidirectional folder sync, no server needed, production-grade, 65K+ GitHub stars. The correct tool if you want files to stay in sync across devices automatically.
• PairDrop / Snapdrop — nearly identical architecture to FileSync (WebRTC, browser-based, no account), but designed specifically for local network discovery. Better for office use; FileSync is better for internet transfers.
• LocalSend — native apps for all platforms (including iOS/Android), LAN-based, no server required. Better mobile experience than FileSync; requires app install on receiver.
• Nextcloud — full cloud storage platform with file sharing, versioning, calendar, contacts. Much heavier to deploy; right for teams who want a self-hosted Google Workspace replacement.
• Seafile — file sync and share with a cleaner architecture than Nextcloud. Better if you specifically need sync + web access + team collaboration.
• Firefox Send (discontinued) — the conceptual predecessor. Mozilla shut it down in 2020 due to abuse. FileSync covers the same basic use case for self-hosters.
• Pingvin Share — self-hosted file sharing with persistent links, expiry controls, and download limits. Better than FileSync if you need the “share a link that lasts 48 hours” workflow.

The honest competitive position: FileSync is the minimal-footprint, real-time, zero-receiver-friction option. It doesn’t try to be Nextcloud. If you want something heavier with persistence, user management, and a proper admin UI, the alternatives above are closer fits [2].

---

Bottom line

FileSync solves exactly one problem — getting files from one device to another without any accounts, without any server storage, and without any app install on the receiving end — and it solves that problem cleanly. The deployment is genuinely simple, the MIT license is real, and the WebRTC architecture means your files stay private in the only way that matters: they never touch a server. The trade-offs are equally clear: no persistence, no access control, no sync, misleading name, and one maintainer at 1,100 stars. For a non-technical founder paying $16/mo to WeTransfer because their clients can’t deal with Google account creation prompts, a $6 VPS and 30 minutes of setup makes that bill permanently disappear. Just don’t expect it to replace Syncthing.

---

Sources

1. LinuxLinks — osync: two way filesync script (contextual: file sync category overview and alternative tools). https://www.linuxlinks.com/osync-two-way-filesync-script/
2. Neoxion.net — BACKUP-FILESYNC link aggregator (contextual: comprehensive list of file sync and backup tools in the self-hosted category). https://neoxion.net/backup-filesync/
3. blog.pulipuli.info — Build a File Sync Tool for Google Drive: ownCloud + rclone (contextual: real-world file sync setup complexity for self-hosted deployments). https://blog.pulipuli.info/2023/03/blog-post_26.html

Primary sources:

• GitHub repository and README: https://github.com/polius/filesync (1,138 stars, MIT license)
• Official website and hosted demo: https://filesync.app