PairDrop selbst hosten: Die AirDrop-Alternative für alle Geräte

Warum PairDrop?

Dateien zwischen Rechner und Handy zu schicken, ist ohne Apple-Ökosystem oft eine Qual: USB-Kabel, Messenger mit Kompression oder Cloud-Zwischenstopps. PairDrop löst das mit einem Browser-Tab pro Gerät – die Dateien wandern direkt von A nach B, in Originalqualität, ohne Umweg über deinen Server. Als Fork von Snapdrop bringt es dazu erweiterte Funktionen wie dauerhaftes Geräte-Pairing, öffentliche Räume und Teilen direkt aus dem Android/iOS-Share-Menü.

So funktioniert der Transfer

• WebRTC: Die eigentlichen Daten fließen verschlüsselt und direkt zwischen den Geräten (P2P). Der Server vermittelt nur die Verbindung (Signaling).
• Geräte-Erkennung: Alle Geräte im selben Netzwerk (oder Raum) sehen sich – mit Namen, Icon und Empfangsbestätigung vor dem Versand.
• Pairing & Räume: Per 6-stelligem Code oder QR dauerhaft gekoppelte Geräte finden sich auch über das Internet; 5-Buchstaben-Räume verbinden temporär fremde Geräte.
• Kein Zwischenspeichern: Ohne WS-Fallback speichert dein Server nichts – es gibt keine Datenbank und kein Volume mit übertragenen Dateien.

Docker Compose – die Datei

Deine Vorlage, aufgeräumt und kommentiert: entfernt wurden der leere networks: {}-Block und das überflüssige network_mode: bridge (Bridge ist ohnehin das Standard-Netz), der Port steht in Anführungszeichen:

services:
  pairdrop:
    image: lscr.io/linuxserver/pairdrop:latest
    container_name: pairdrop
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: "4.0"
          memory: 4G
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - WS_FALLBACK=false
      - RATE_LIMIT=false
      - RTC_CONFIG=
      - DEBUG_MODE=false
    ports:
      - "127.0.0.1:50513:3000"   # Web-UI nur lokal – Zugriff über Reverse Proxy
      # - ./rtc_config.json:/config/rtc_config.json:ro   # nur bei eigenen STUN/TURN-Servern

Der Container ist bewusst zustandslos – übertragene Dateien werden nirgends gespeichert, ein Volume ist nicht nötig. PUID/PGID greifen erst, wenn du eigene Dateien (z. B. eine rtc_config.json) einbindest; dann müssen Host-Ordner dem Nutzer 1000 gehören.

Umgebungsvariablen im Detail

Eigene STUN/TURN-Server (z. B. Coturn) bindest du so ein:

# rtc_config.json (im Container erreichbar unter /config/)
{
  "iceServers": [
    { "urls": "stun:stun.example.org:3478" },
    { "urls": "turn:turn.example.org:3478",
      "username": "pairdrop",
      "credential": "geheim" }
  ]
}

Dann in der Compose-Datei das Volume einbinden und RTC_CONFIG=/config/rtc_config.json setzen. Ohne eigene TURN-Server nutzen Clients öffentliche STUN-Server und scheitern in hartem NAT ggf. am Direktverbindungsaufbau – genau dafür ist WS_FALLBACK oder ein eigener TURN-Server da.

Reverse Proxy & HTTPS

Öffentlich erreichbar sein soll die Instanz nur über HTTPS mit korrekt gesetzten Headern. Der LinuxServer-README zufolge ist vor allem X-Forwarded-For entscheidend – wird es falsch gesetzt, „sehen“ sich alle Clients gegenseitig (alle erscheinen unter derselben IP):

send.meine.domain {
  encode zstd gzip
  reverse_proxy 127.0.0.1:50513
}

• Caddy setzt X-Forwarded-For automatisch korrekt – ebenso die meisten Standard-Proxys.
• Bei Cloudflare Proxy kann eine Zusatzkonfiguration nötig sein (echte Client-IP aus CF-Connecting-IP übernehmen), damit die Rate-Limit- und Raum-Logik pro Client funktioniert.
• WebSockets (Signaling) muss der Proxy durchreichen – bei Caddy und Nginx-aktuell automatisch, bei älteren Nginx-Setups Upgrade-Header prüfen.

Erster Start & Nutzung

cd ~/pairdrop
docker compose up -d
docker compose logs -f pairdrop

Danach https://send.meine.domain auf beiden Geräten öffnen – sie tauchen automatisch in der Geräteliste auf. Nützlich im Alltag:

• Als App installieren: PWA im Browser-Menü auf den Homescreen – fühlt sich wie eine native App an.
• Paaren statt Räume: Eigene Geräte per 6-stelligem Code/QR dauerhaft koppeln, damit sie sich auch über das Internet finden.
• Mehrere Dateien landen als ZIP auf dem Empfänger; Texte und Code-Snippets lassen sich direkt verschicken.
• Share-Menü: Unter Android/iOS direkt „Mit PairDrop teilen“, unter Linux/Windows per Kontextmenü-Skript.
• Kopierte Inhalte vorab einfügen und Empfänger danach wählen.

Sicherheit & Privatsphäre

• Standard = P2P: Dateien gehen verschlüsselt direkt von Gerät zu Gerät, dein Server sieht nur die Verbindungsvermittlung.
• Keine Konten, kein Speicher: Es gibt nichts anzumelden und nichts zu leaken – die Übertragung existiert nur, solange beide Browser-Tabs offen sind.
• WS-Fallback aus: Solange WS_FALLBACK=false ist, kann dein Server nie Daten lesen. Erst der Fallback-Modus macht ihn zum Relay.
• Rate-Limit einschalten, wenn öffentlich: RATE_LIMIT=true gegen Missbrauch – kombiniert mit korrektem X-Forwarded-For.
• Kein Debug-Modus: DEBUG_MODE=true loggt Client-IPs – für den Dauerbetrieb tabu.

Updates & Wartung

Da der Container nichts speichert, ist die Wartung denkbar einfach:

docker compose pull pairdrop && docker compose up -d

• Kein Backup nötig – es gibt keine eigenen Daten. Lediglich optionale Dateien wie rtc_config.json liegen außerhalb.
• Der :latest-Tag zieht die neueste LinuxServer-Version; wer kontrolliert aktualisieren will, pinnt einen Versions-Tag.
• Nach Updates reicht ein kurzer Log-Check: docker compose logs pairdrop.

Häufige Probleme (FAQ)

Fazit

PairDrop ist die pragmatischste AirDrop-Alternative, die es ohne Apple-Hardware gibt: Browser auf, Gerät sehen, Datei rüberschieben – fertig. Wer die Instanz privat für sich und Familie betreibt, bekommt mit dem Standard-Setup echten P2P-Transfer ohne Datenumweg. Wer öffentlich hostet, schaltet Rate-Limit und ggf. Fallback bewusst – und weiß dann auch, was das für die Privatsphäre bedeutet.