PrivyDrop

Open-source P2P file transfer, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: Open-source (MIT) peer-to-peer file and text transfer tool built on WebRTC — think AirDrop, but cross-platform, browser-based, and running on your own server [README].
• Who it’s for: People who regularly need to move files between their own devices or within a small team without touching a third-party server. Privacy-conscious founders, remote workers, and home lab enthusiasts [3].
• Cost savings: WeTransfer Pro runs $12/mo, Dropbox Transfer is bundled into plans starting at $10/mo. PrivyDrop self-hosted runs on a $5–10/mo VPS with unlimited transfers and zero per-file fees.
• Key strength: True end-to-end encryption — files never touch the signaling server. Docker deployment is genuinely simple, with multiple modes (LAN, public IP, full domain with auto-HTTPS) handled by a single shell script [README][3].
• Key weakness: Only 121 GitHub stars as of this review — a young, single-maintainer project with no independent third-party reviews and no track record under sustained load. WebRTC requires a TURN server for reliable cross-network transfers, which adds infrastructure complexity the simple deployment story glosses over [README][3].

---

What is PrivyDrop

PrivyDrop is a browser-based file and text transfer tool. You open a “room,” share a link or QR code with someone, and files go directly browser-to-browser via WebRTC. The server only handles signaling (coordinating the connection) and stores nothing — the actual bytes never touch it [README].

The GitHub description calls it “an open-source web-app alternative to AirDrop,” which is the plainest and most accurate pitch. The homepage headline — “Free Secure Online Clipboard & File Transfer Tool” — is slightly overselling a product that is, at its core, a P2P file transfer relay with a rich text clipboard thrown in [homepage].

The project was formerly called SecureShare and was rebranded to PrivyDrop at some point [README]. It’s a solo project by developer david-bai00, written in Next.js 14 on the frontend and Node.js/Express on the backend, with Socket.IO for signaling and Redis for session state [README]. The Reddit announcement post [3] was tagged “AI-Assisted App,” meaning portions of the codebase were generated with AI tools — worth noting for anyone auditing the source before deploying it.

As of this review, it sits at 121 GitHub stars. That’s not a thumbs-down, but it is a useful calibration: this is a new project with no track record in production, no independent reviews, and no user base large enough to surface edge cases through bug reports.

---

Why people choose it

The honest answer here is thin, because there are no independent third-party reviews. The primary public signal is the creator’s own Reddit post on r/selfhosted [3] and a listing in the awesome-selfhosted directory [1][2]. The Reddit post received enough engagement that the community noticed it, but the discussion is mostly questions and encouragement rather than independent users reporting long-term production use.

That said, the appeal is legible. The r/selfhosted community consistently asks for tools that move files between devices without routing data through Google Drive, Dropbox, or WeTransfer. PrivyDrop’s pitch — WebRTC P2P, server sees nothing, one Docker command — maps directly onto that demand [3].

Versus AirDrop. AirDrop works only between Apple devices on the same network. PrivyDrop works in any browser, over the internet, across operating systems. If you’re sending files from a Mac to an Android phone, or from your home network to a client’s laptop, AirDrop is irrelevant and PrivyDrop (or something like it) is the actual comparison [README][3].

Versus WeTransfer / Dropbox Transfer. These are upload-to-server, generate-a-link tools. Your file lives on their infrastructure until the recipient downloads it, and on free tiers it gets deleted after days. PrivyDrop is direct transfer — the file never lands anywhere except the recipient’s device [README]. The privacy argument is real if you’re moving anything sensitive.

Versus PairDrop and ShareDrop. This is the more competitive fight that the README and marketing materials don’t address. PairDrop (a maintained fork of Snapdrop) and ShareDrop are both also WebRTC-based, open-source, and self-hostable. PairDrop in particular has a hosted version at pairdrop.net, thousands of GitHub stars, and years of community testing. PrivyDrop’s differentiators are resumable transfers and rich text clipboard — features PairDrop doesn’t have — but anyone evaluating PrivyDrop should look at PairDrop first and decide whether those features justify switching to a less-proven codebase.

---

Features

Based on the README and homepage:

Core transfer engine:

• WebRTC P2P connections — files go browser-to-browser, server handles only signaling [README]
• Unlimited file size via Chrome’s direct-to-disk streaming (requires setting a save directory in the browser) [README]
• File and folder transfer [README]
• Multi-receiver support: multiple people can download from the same room simultaneously without interrupting ongoing transfers [README]
• Resumable transfers: if the connection drops, you can pick up from the interruption point — though both sender and receiver currently need to refresh their pages to restart [README]
• Real-time transfer progress and speed display [README]

Text and sharing:

• Rich text clipboard with formatted text editing (not just plaintext paste) [README]
• Room sharing via link or QR code [README]

Infrastructure:

• Responsive design for desktop and mobile [README]
• English and Chinese localization [README]
• Docker deployment with five distinct modes: LAN HTTP, LAN HTTP with TURN, LAN HTTPS (self-signed), public IP, and full domain with auto-HTTPS via Let’s Encrypt [README]
• In-app navigation persistence: switching pages in the same tab doesn’t interrupt active transfers [README]

Tech stack:

• Frontend: Next.js 14, React 18, TypeScript, Tailwind CSS, shadcn/ui [README]
• Backend: Node.js, Express.js, TypeScript [README]
• Real-time: WebRTC, Socket.IO [README]
• State: Redis [README]
• Deployment: Docker Compose, Nginx [README]

What’s notably absent: there’s no user account system, no transfer history, no admin dashboard, and no access controls. Anyone with a room link can join. For personal use or trusted teams, that’s fine. For anything with untrusted external participants, it’s a gap to be aware of.

---

Pricing: SaaS vs self-hosted math

PrivyDrop is unusual in the self-hosted space: the hosted version at privydrop.app is free, with no sign-up and no usage limits stated on the homepage. The self-hosted version is MIT-licensed and also free [README][homepage].

So this isn’t the typical “escape your SaaS bill” calculation. The math is simpler: what are you currently paying for file transfer, and what could you replace?

Common paid alternatives:

• WeTransfer Pro: $12/mo for 200GB storage, larger file sizes, custom links
• Dropbox Transfer: bundled in Dropbox plans starting ~$10/mo
• Google Drive + sharing links: included in Workspace plans from $6/user/mo

Self-hosted PrivyDrop:

• VPS to run it on: $5–10/mo (Hetzner, Contabo, DigitalOcean)
• Redis (bundled in Docker Compose): $0
• Domain and SSL: $10–15/year, SSL auto-managed via Let’s Encrypt [README]

If you’re paying WeTransfer Pro for nothing except file transfer to clients and colleagues, self-hosting PrivyDrop eliminates that $144/year entirely. The tradeoff is a VPS bill and the maintenance responsibility.

However: if your primary use case is personal file transfer between your own devices, the free hosted privydrop.app handles that at zero cost to you. Self-hosting only makes sense if you need the server under your own control — for privacy reasons, for reliability, or to run it on your LAN where it works without any internet connection at all [3].

There is no paid tier, no enterprise license, and no commercial cloud offering. This is pure open-source.

---

Deployment reality check

The README’s deployment story is genuinely good. One script, five modes, Let’s Encrypt auto-configured. The creator specifically called out “5-minute deployment” in the Reddit post [3], and for someone comfortable with Docker, that’s plausible for the LAN mode.

What you actually need:

• A Linux VPS or local machine with Docker and docker-compose
• For internet-facing use: a domain name (if you want HTTPS without browser warnings)
• For cross-network transfers: a TURN server (included in the deploy script’s --with-turn flag)
• Redis (bundled in the Docker Compose setup)
• Ports 80/443 open if using the Nginx mode

What can go sideways:

The most important thing the deployment docs under-emphasize is TURN server dependency. WebRTC works great when both parties are on the same network or have simple NAT setups. When both sides are behind symmetric NAT (common on mobile networks and corporate firewalls), direct P2P fails and falls back to a TURN relay. Without --with-turn, transfers between people on different networks may simply not establish [README][3].

Running your own TURN server (via coturn, bundled in the --with-turn mode) adds another moving part. The community hasn’t tested this at scale, so TURN stability under load is an open question.

LAN HTTPS has a CA certificate step. The self-signed mode requires importing a CA certificate into each browser or system trust store. The README documents this, but it’s a non-trivial friction point for non-technical users — they’ll see browser security warnings until they complete this step [README].

The “refresh both pages to resume” limitation. The resumable transfer feature requires refreshing both sender and receiver pages after an interruption [README]. For a tool billing itself on resumable transfers as a headline feature, that’s a notable UX rough edge.

Redis is a required dependency even for simple use cases. The Docker Compose setup handles it, but it’s an additional component to understand if anything goes wrong.

Realistic setup time: 15–30 minutes for a technical user on the Docker path to a working LAN instance. Add another 30–60 minutes if you’re configuring a public domain, HTTPS, and TURN. For a non-technical founder: budget a couple of hours, or pay someone to deploy it once.

---

Pros and cons

Pros

• True P2P encryption. Files don’t touch the server. This is architecturally different from most file-sharing tools, where data flows through the vendor’s infrastructure [README][3].
• MIT license. No restrictions, no commercial clauses, no “fair-code” gotchas. You can deploy it, modify it, embed it in your own product [README].
• Resumable transfers. The ability to resume after interruption is genuinely rare in WebRTC-based file transfer tools and solves a real problem with large files on unstable networks [README][3].
• Multi-receiver support. A sender can broadcast to multiple recipients simultaneously, without disrupting ongoing transfers when new people join [README].
• Folder transfer. Not all comparable tools support sending entire folder trees [README].
• Rich text clipboard. Formatted text sharing alongside files is a practical feature for mixed text+file workflows [README].
• Docker deployment script handles the complexity. Five deployment modes with a single shell script is genuinely thoughtful infrastructure work [README].
• No registration required. For the hosted version and self-hosted instances, there are no accounts. Link-and-go [README][homepage].

Cons

• 121 stars, single maintainer. This is a young project with no production track record, no bug reports from a large user base, and no community around it yet. If the maintainer stops updating it, you inherit the codebase [GitHub].
• No independent reviews. The only public signal beyond the README is the creator’s own Reddit post [3] and list inclusions [1][2]. There are no third parties who have tested this in production and written about it.
• TURN server required for reliable internet transfers. Without it, WebRTC falls back and connections may fail between users on different networks [README].
• Resume requires page refresh on both ends. The headline resumable transfer feature has a significant UX caveat that undermines it for non-technical users [README].
• No access controls. Anyone with a room URL can join. No passwords, no authentication, no expiry [README].
• No transfer history or logging. Once a transfer is done, there’s no record of it [README].
• AI-assisted codebase. The Reddit post labels it “AI-Assisted App” [3]. For most use cases this is irrelevant, but for anyone deploying this in a security-sensitive environment, the codebase warrants more careful auditing than a fully human-written project.
• Crowded category with more mature alternatives. PairDrop has years of production use and community testing. If you don’t need resumable transfers specifically, it’s the safer bet.

---

Who should use this / who shouldn’t

Use PrivyDrop if:

• You’re moving files between your own devices (desktop ↔ phone, home ↔ office) and want something under your own control.
• You’re running a small team that regularly shares files with clients and are tired of WeTransfer’s limits or storage expiry.
• You specifically need resumable transfers for large files on unreliable connections and want a browser-based solution.
• You’re deploying this on a local network (LAN mode) where NAT traversal issues don’t apply.
• You want MIT-licensed source code you can read, audit, or modify.

Wait and watch (or pick PairDrop instead) if:

• You need a proven, production-tested tool. PairDrop has the track record; PrivyDrop doesn’t yet.
• You need the tool to work reliably across complex network topologies (corporate firewalls, mobile data) without running your own TURN server.
• Non-technical users will be the primary senders or receivers — the resume-after-page-refresh workflow and browser certificate requirements will cause friction.

Skip it entirely if:

• Your use case is sending large files asynchronously (sender uploads, recipient downloads later). PrivyDrop requires both parties to be online simultaneously [README]. For async delivery, use something like Nextcloud or Seafile.
• You need access controls, transfer logs, or audit trails. None of these exist.
• You’re evaluating this for a compliance-regulated environment. No SOC 2, no audit logs, no documented access controls.

---

Alternatives worth considering

• PairDrop — the most direct comparison. Also WebRTC-based, browser-only, self-hostable. More mature, larger community, years of production deployments. Lacks resumable transfers and rich text clipboard. Hosted at pairdrop.net free. Start here.
• ShareDrop — another WebRTC option, simpler than PairDrop, good for LAN discovery. Less actively maintained.
• LocalSend — native app (not browser-based), works over LAN only, no internet transfer. Excellent for device-to-device within the same network. Much more mature and widely used.
• Magic Wormhole — CLI tool, code-based transfer, end-to-end encrypted, works across the internet. Excellent for technical users who are comfortable with terminals and don’t need a browser UI.
• OnionShare — Tor-based file sharing, anonymous sender, works across the internet without NAT issues. Slower due to Tor routing. Best when anonymity is the primary requirement.
• Nextcloud — full file storage and sync platform. Much heavier to self-host, but supports async transfer, sharing links, access controls, and a full ecosystem. The right choice if you need more than point-to-point transfer.
• Seafile — similar to Nextcloud but faster sync engine. Again, async and storage-first rather than ephemeral P2P transfer.

For the “quick transfer, browser-based, no accounts” category, the realistic shortlist is PrivyDrop vs PairDrop. Pick PrivyDrop if resumable transfers or multi-receiver simultaneously are requirements you’ve actually hit in practice. Pick PairDrop if you want proven infrastructure.

---

Bottom line

PrivyDrop solves a real problem with a clean technical approach: browser-to-browser file transfer that never touches a server, with resumable transfers and folder support that comparable tools don’t have. The deployment story is better than most projects at this star count. If you’re on a LAN or have a straightforward NAT setup, it probably just works.

The honest caution is scale: 121 stars, one maintainer, no independent production reports. You’re an early adopter, not a late adopter picking up proven infrastructure. For personal or small-team use where you can absorb some rough edges, that’s a reasonable bet. For anything critical, give it another year of community testing, or stick with PairDrop until PrivyDrop proves itself at scale.

If the Docker deployment is the blocker, upready.dev deploys exactly this kind of self-hosted tooling for clients — one-time setup, you own the server.

---

Sources

1. Clones/awesome-selfhosted — mirror of awesome-selfhosted list including PrivyDrop under File Transfer. https://git.libox.fr/Clones/awesome-selfhosted
2. Track Awesome List — weekly updates tracker for awesome-selfhosted/awesome-selfhosted. https://www.trackawesomelist.com/awesome-selfhosted/awesome-selfhosted/week/
3. ForwardRope6029 (project creator), r/selfhosted — “PrivyDrop - Open Source WebRTC File Transfer Tool with One-Click Docker Deployment, P2P Encrypted Transfer”. https://www.reddit.com/r/selfhosted/comments/1o6630p/privydrop_open_source_webrtc_file_transfer_tool/

Primary sources:

• GitHub repository and README: https://github.com/david-bai00/privydrop (121 stars, MIT license)
• Official website: https://www.privydrop.app