PairDrop vs Send: Local or Link-Based Sharing?

Source: Dev.to

Quick Verdict

PairDrop and Send solve different problems.

• PairDrop: instant, local file transfers between nearby devices (think AirDrop).
• Send: sharing files with anyone via encrypted, expiring links (think WeTransfer).

Pick based on your use case, not which is “better.”

Feature Comparison

Self‑Hosting

PairDrop (single container)

# docker-compose.yml
services:
  pairdrop:
    image: ghcr.io/schlagmichdoch/pairdrop:v1.11.2
    ports:
      - "3000:3000"
    restart: unless-stopped

• One container, no database, no persistent storage.
• The server only handles WebRTC signaling; files never touch it.

Send (app + Redis + storage)

# docker-compose.yml
services:
  send:
    image: registry.gitlab.com/timvisee/send:v3.4.27
    ports:
      - "1443:1443"
    volumes:
      - ./uploads:/uploads
    environment:
      - REDIS_HOST=redis
    depends_on:
      - redis
  redis:
    image: redis:7-alpine

• Requires two containers (app + Redis) and a persistent volume for uploaded files.
• Configuration includes BASE_URL, upload limits, and expiry defaults.

Resource Usage

Community & Maintenance

• PairDrop: ~4.5 k GitHub stars, active development, fork of Snapdrop with rooms, persistent pairing, and text sharing. Documentation includes Docker deployment and optional TURN server setup.
• Send: ~4.8 k GitHub stars, maintained fork of the discontinued Firefox Send. The maintainer (timvisee) provides regular updates and a separate Docker‑Compose repository with deployment examples.

Result: Both have similar community size and active maintenance.

Choosing the Right Tool

• Use PairDrop when:

  • You need AirDrop‑like functionality across all platforms.
  • Privacy is paramount (files never touch a server).
  • Transfers are between devices on the same network (office, home).
  • You want a zero‑maintenance deployment.

• Use Send when:

  • You need to share files with people outside your network.
  • Expiring, password‑protected download links are required.
  • End‑to‑end encryption of stored files matters.
  • You’re replacing WeTransfer or similar services.
  • You need to control download counts.

• Both together: They are complementary. PairDrop handles local, fast, private transfers; Send handles remote, link‑based sharing.

• If you can pick only one:

  • PairDrop for personal/home use (most file sharing happens between your own devices).
  • Send for team/business use (sharing with clients, partners, or anyone outside your network).

Frequently Asked Questions

Q: Does PairDrop work without a TURN server?
A: Yes, but only between devices on the same LAN or VPN. A TURN server (e.g., coturn) is required for relaying connections across NATs or the internet.

Q: Is the encryption in Send truly end‑to‑end?
A: Yes. Encryption happens in the browser before upload. The server stores only encrypted blobs; the decryption key is part of the URL fragment (#…) and never sent to the server.

Q: What happens to files after they expire in Send?
A: The encrypted file is automatically deleted from the server. Neither the file nor its metadata is recoverable.

Q: How much RAM does each service consume?
A: PairDrop uses ~30 MB RAM (signaling only). Send uses ~80‑110 MB RAM (app + Redis) plus disk space for stored uploads.

Related Topics

• Self‑hosting PairDrop
• Self‑hosting Send
• Send vs WeTransfer
• Self‑hosted alternatives to AirDrop
• Self‑hosted alternatives to WeTransfer
• Best self‑hosted file‑sharing tools
• Docker Compose basics