Relayium selbst hosten: eigener Dateiübertragungs-Server

Zuletzt aktualisiert: 2026-07-09

Relayium ist MIT-lizenziert und Open Source, und der Server ist ein einziges eigenständiges Image — keine externe Datenbank, kein Storage-Bucket eines Drittanbieters, nichts, wofür man sich anmelden müsste. Wenn du lieber alles selbst betreibst, statt dich auf relayium.com zu verlassen, bringt dich diese Anleitung mit Docker zu einem laufenden Server und richtet die CLI darauf aus.

Selbst hosten heißt, volle Kontrolle darüber zu haben, wo deine Daten liegen, eine eigene Domain und ein eigenes TLS-Zertifikat zu nutzen, und von niemandes fremden Betriebsentscheidungen abhängig zu sein. Alles Folgende stützt sich auf Dateien, die tatsächlich im Repository liegen — docker-compose.yml, server/.env.example und docs/DEPLOYMENT.md —, sodass hier keine Flag oder Einstellung erwähnt wird, die es nicht wirklich gibt.

Warum selbst hosten

Relayiums Echtzeit-Übertragungen sind bereits Peer-to-Peer und Ende-zu-Ende verschlüsselt, sodass der Server dabei nie deine Dateibytes sieht. Er hält aber dein Konto und — bei gespeicherten/link-basierten Übertragungen — verschlüsselte Blobs sowie eine kleine SQLite-Datenbank. Selbst hosten bedeutet, dass diese Daten auf Infrastruktur liegen, die du kontrollierst, unter deiner eigenen Domain, ohne dass fremde Betriebsentscheidungen mitspielen.

Da das Projekt MIT-lizenziert und Open Source ist (github.com/relayium/relayium), kannst du genau nachlesen, was der Server tut, bevor du ihm irgendetwas anvertraust, und ihn frei forken oder verändern.

Schnellstart mit Docker

Im Repository-Root liegen ein Dockerfile und ein docker-compose.yml, die ein einziges eigenständiges Image bauen — ein statisches Go-Binary, das die vorgebaute Web-App ausliefert, sodass für den reinen Betrieb weder ein separates Node, eine Go-Toolchain noch nginx nötig ist:

docker compose up -d --build

Das ist bereits der gesamte Server, er lauscht auf :8080. Setze in Produktion nginx oder Caddy davor, um TLS zu übernehmen — eine vollständige nginx-Konfiguration findest du in docs/DEPLOYMENT.md.
Die App-Konfiguration kommt aus einer optionalen server/.env-Datei plus dem environment:-Block in docker-compose.yml. Jede Einstellung hat einen passenden RELAYIUM_*-Key — kopiere server/.env.example als Ausgangspunkt.
Die vier für eine einfache Bereitstellung wichtigen Keys: RELAYIUM_ADDR (Listen-Adresse), RELAYIUM_STATIC (Pfad zur gebauten Web-App), RELAYIUM_DB (SQLite-Dateipfad) und RELAYIUM_BLOB_DIR (wohin das Chiffrat gespeicherter Links geschrieben wird). docker-compose.yml setzt für alle vier bereits sinnvolle Standardwerte und persistiert sie in einem benannten Volume.

Ein TURN-Relay für netzwerkübergreifende Übertragungen hinzufügen

Übertragungen im selben Netzwerk (LAN) und SSH-basiertes push/pull funktionieren ohne alles Zusätzliche. Netzwerkübergreifende Echtzeit-Übertragungen (zwei Geräte hinter unterschiedlichen NATs) brauchen manchmal ein TURN-Relay, um einen Pfad herzustellen — das Relay sieht dabei stets nur Chiffrat, niemals deinen Dateiinhalt.

docker-compose.yml hat ein optionales relay-Profil, das zusammen mit dem Hauptserver coturn (den TURN-Server) und eine kleine Redis-Instanz für die Zählung der Relay-Bytes startet:

RELAYIUM_TURN_SECRET=$(openssl rand -hex 32) docker compose --profile relay up -d --build

coturn braucht die echte öffentliche IP des Hosts und einen offenen UDP-Portbereich, um zu funktionieren — die vollständige Einrichtung (inklusive Ein-Befehl-Installationsskript) steht in docs/coturn.md, Fehlersuche bei einem reinen NAT-Traversal-Problem in docs/enable-turn.md.
Ohne --profile relay und RELAYIUM_TURN_SECRET läuft der Server trotzdem einwandfrei — netzwerkübergreifende Übertragungen fallen dann nur auf reines STUN zurück, das bei einfacheren NAT-Typen funktioniert, aber nicht bei den strengsten.

Die CLI auf deinen Server ausrichten

Die Relayium CLI verwendet für netzwerkübergreifendes send/receive standardmäßig den Rendezvous-Server auf relayium.com. Übergib --server, um stattdessen deinen eigenen zu nutzen:

relayium send ./report.pdf --server https://your-domain

relayium receive --server https://your-domain

Egal welchen Server sie nutzt, die CLI ist kostenlos und braucht kein Konto — --server ändert nur, mit welchem Rendezvous-Server sie für den Pairing-Code-Handshake spricht.
push/pull (über dein eigenes SSH) sowie serve + daemon-direct push relayium://host berühren relayium.com überhaupt nicht, selbst gehostet oder nicht — sie verbinden sich direkt mit der von dir angegebenen Gegenstelle.

Häufige Fragen

Muss ich TURN einrichten?

Nur, wenn netzwerkübergreifende Echtzeit-Übertragungen auch durch strenge NATs funktionieren sollen. Übertragungen im selben Netzwerk, SSH-basiertes push/pull und daemon-direct funktionieren alle ohne TURN — TURN dient ausschließlich der NAT-Traversal auf dem netzwerkübergreifenden Pairing-Code-Pfad.

Ist die CLI beim Selbsthosten immer noch kostenlos?

Ja. Ob sie mit relayium.com oder einem selbst betriebenen Server spricht, die CLI ist völlig kostenlos und braucht kein Konto — --server richtet sie nur auf deine Instanz aus.

Kann ich meine eigene Domain und ein eigenes TLS-Zertifikat verwenden?

Ja. Das Docker-Image lauscht selbst auf reinem HTTP auf :8080; setze nginx oder Caddy mit deiner eigenen Domain und deinem Zertifikat davor (z. B. über certbot/Let's Encrypt). docs/DEPLOYMENT.md enthält eine vollständige nginx-Konfiguration zum Übernehmen.

Welche Daten speichert mein selbst gehosteter Server?

Eine SQLite-Datenbank (Konten, Sessions) unter RELAYIUM_DB und, bei gespeicherten/link-basierten Übertragungen, verschlüsselte Blobs unter RELAYIUM_BLOB_DIR, die der Server selbst nicht entschlüsseln kann. Echtzeit-Peer-to-Peer-Übertragungen werden nirgendwo gespeichert — der Server leitet nur den Signaling-Handshake weiter.

Installiere die kostenlose Relayium CLI und richte sie mit --server auf deinen eigenen Server aus.

CLI holen