Bring Your Own Node: Relay und Speicher von Relayium kostenlos nutzen

Zuletzt aktualisiert: 2026-08-06

Netzübergreifende Übertragungen und gespeicherte Links nutzen Relay-Bandbreite und Speicherplatz, die uns Geld kosten, und laufen daher auf einem kostenlosen Kontingent, das darüber hinaus kostenpflichtig ist. Es gibt einen Ausweg: Betreibe deinen eigenen Relay-/Speicher-Node, binde ihn an dein Konto, und deine Übertragungen fließen über deinen Node statt über unseren — nichts wird gemessen, nichts wird berechnet.

Das unterscheidet sich davon, den gesamten Relayium-Server selbst zu hosten. Du verwendest weiterhin dein normales relayium.com-Konto und dieselben Apps; du fügst lediglich einen Node hinzu, der dir gehört und deinen Datenverkehr trägt. Diese Anleitung führt dich in etwa fünf Minuten von einem frischen Linux-Rechner zu einem Online-Node.

Warum einen eigenen Node betreiben

Zwei Gründe. Erstens die Kosten: Ein Node, der dir gehört, trägt deinen Relay- und Speicherverkehr direkt, berührt also nie unsere abrechnungspflichtige Infrastruktur, und es gibt nichts zu berechnen — deine Nutzung ist kostenlos, egal wie groß.

Zweitens die Kontrolle: Die weitergeleiteten Bytes und gespeicherten Blobs liegen auf Hardware, die du betreibst, unter deiner eigenen betrieblichen Kontrolle. Echtzeit-Übertragungen bleiben auf dem gesamten Weg Ende-zu-Ende-verschlüsselt, sodass selbst dein eigener Node immer nur Chiffretext sieht.

Den Node installieren und online bringen

Was du vor Schritt 1 brauchst

Einen aus dem Internet erreichbaren Linux-Server — ein günstiger VPS oder eine dauerhaft laufende Kiste zu Hause tun es beide. amd64 und arm64 werden unterstützt.
root auf diesem Server, oder sudo. Die Installation braucht es einmal; der Node selbst läuft nie als root.
Die Möglichkeit, eingehende Ports zu öffnen — in der Host-Firewall und auf einem Cloud-VPS zusätzlich in der Security Group des Anbieters.
Ein relayium.com-Konto, an dem du angemeldet bist. Der Installationsbefehl wird auf der Kontoseite erzeugt und trägt ein Einmal-Token.
Plattenplatz, aber nur wenn der Node außer relayen auch speichern soll. Ein reiner Relay-Node braucht keinen — lass RELAYIUM_NODE_STORAGE_DIR dann weg.

Vier Dinge der Reihe nach: den Befehl erzeugen, ihn ausführen, die Ports öffnen und bestätigen, dass der Node online gegangen ist. Auf einer frischen Kiste rund fünf Minuten.

Melde dich auf relayium.com an und öffne deine Kontoseite unter /me.
Scroll zu Meine Nodes und klick auf Node hinzufügen. Kopiere den Installationsbefehl sofort — das Token darin wird genau einmal angezeigt und lässt sich nicht erneut abrufen.

Führ ihn auf deinem Server aus. Er lädt das relayium-node-Binary, prüft dessen Checksumme, installiert es nach /usr/local/bin, schreibt einen systemd-Dienst und startet ihn.

curl -fsSL https://relayium.com/install-node.sh | sudo RELAYIUM_CENTRAL_URL=https://relayium.com RELAYIUM_NODE_TOKEN=<your-token> RELAYIUM_NODE_STORAGE_DIR=/var/lib/relayium-node/blobs sh

Bestätige, dass der Dienst läuft und nach einem Neustart wiederkommt. Beide Antworten zählen: active heißt, er läuft jetzt, enabled ist das, was einen Neustart überlebt.
```
systemctl is-active relayium-node
```
```
systemctl is-enabled relayium-node
```
Öffne die eingehenden Ports in der Host-Firewall. Für den Online-Status reicht ausgehender Zugriff, aber Peers relayen und speichern über genau diese Ports.
```
sudo ufw allow 3478/udp        # TURN
sudo ufw allow 8081/tcp        # storage
sudo ufw allow 49152:65535/udp # relay
```
Auf einem Cloud-VPS erlaub dieselben Ports zusätzlich in der Security Group des Anbieters. Mit ufw allein bleiben sie weiter oben dicht — und der Node sieht die ganze Zeit gesund aus.
Zurück auf /me: warte, bis der Node auf Online springt, meist in etwa 30 Sekunden. Ab da bevorzugen die Übertragungen deines Kontos ihn automatisch.
Optional: Schalte "Nur meine eigenen Nodes für Relay/Speicher verwenden" ein, damit eine Übertragung fehlschlägt, statt still auf unsere geteilte Infrastruktur zurückzufallen.

So sieht ein funktionierender Node aus

systemd meldet den Dienst als active UND enabled, und der Node steht unter Meine Nodes auf Online. active allein genügt nicht — ein Node ohne enabled ist nach dem nächsten Neustart weg.

$ systemctl is-active relayium-node
active
$ systemctl is-enabled relayium-node
enabled

Der Teil <your-token> wird auf der Kontoseite für dich ausgefüllt — füge den obigen Platzhalter nicht wörtlich ein.
RELAYIUM_NODE_STORAGE_DIR aktiviert neben dem Relay auch die Blob-Speicherung. Lass es weg (die Variable auslassen), wenn der Node nur weiterleiten und nicht speichern soll.
Prüfen, ob er gestartet ist: systemctl status relayium-node (sollte active/running anzeigen).
Boot-Persistenz bestätigen: systemctl is-enabled relayium-node (sollte enabled anzeigen).
Logs live verfolgen: journalctl -u relayium-node -f.
3478/udp ist der TURN-Port, den Peers zum Weiterleiten verwenden; 8081/tcp ist der HTTP-Port der Blob-Speicherung; 49152–65535/udp ist der Relay-Medienbereich.
Auf einem Cloud-VPS erlaube sie auch in der Sicherheitsgruppe / Netzwerk-Firewall des Anbieters, nicht nur in ufw.

Ist es sicher, diesen Installer als root auszuführen?

Zuerst das Wichtigste: BYO-Nodes laufen mit demselben Code und derselben Härtung wie unsere eigenen Flotten-Nodes — dieselbe Binärdatei aus demselben signierten Release, installiert vom selben Skript, unter derselben systemd-Unit. Der einzige Unterschied ist, wem die Maschine gehört. Alles Folgende beschreibt beide.

Das ist eine berechtigte Frage zu einem Befehl, der ein Skript aus dem Internet in eine root-Shell leitet, und sie verdient eine konkrete Antwort statt einer Beruhigung. root wird für die Installation gebraucht und für nichts, was der Node danach tut. Der Installer legt ein Systemkonto namens relayium-node ohne Login-Shell und ohne Home-Verzeichnis an, schreibt die systemd-Units, startet den Dienst und beendet sich. Der Node selbst läuft nie als root: Seine Unit setzt User=relayium-node, er ist also ab der Sekunde, in der er online geht, ein unprivilegiertes Konto, dem auf deiner Maschine nichts gehört. (Die standardmäßig aktive Auto-Aktualisierung fügt allerdings eine zweite Unit hinzu, die als root läuft — der nächste Abschnitt handelt ausschließlich davon, was diese kann und was nicht.)

Um dieses Konto legt die Unit eine systemd-Sandbox. Jede Zeile zielt auf etwas, wonach ein Angreifer greifen würde, der den Node-Prozess je übernimmt. Nichts davon ist vor dir verborgen: Lies nach der Installation die ganze Unit mit cat /etc/systemd/system/relayium-node.service.

In der Unit	Was es verhindert, falls der Node je kompromittiert wird
`User=relayium-node`	Der Angreifer ist ein Benutzer, dem nichts gehört — nicht root.
`ProtectHome=yes`	/home und /root sind unsichtbar — keine privaten SSH-Schlüssel, keine Daten anderer Projekte.
`ProtectSystem=strict`	Das gesamte Dateisystem ist schreibgeschützt; keine Systemdatei lässt sich ändern.
`ReadWritePaths=`	Beschreibbar sind nur das eigene Statusverzeichnis des Nodes und, falls konfiguriert, das Speicherverzeichnis. Schreibzugriffe woanders schlagen fehl.
`NoExecPaths=`	Nichts im Speicherverzeichnis ist ausführbar — eine hochgeladene Datei kann nicht gestartet werden.
`NoNewPrivileges=yes`	Kein Weg zurück zu root; die üblichen Eskalationstricks sind versperrt.
`CapabilityBoundingSet=`	Leer — überhaupt keine Linux-Capabilities.
`ProtectKernelTunables=yes, ProtectKernelModules=yes`	Der Kernel ist außer Reichweite: keine sysctl-Änderungen, kein Laden von Modulen, kein Rootkit.

ReadWritePaths und NoExecPaths nennen das Speicherverzeichnis nur auf einem Node, der tatsächlich speichert. Ein reiner Relay-Node bekommt keine der beiden Zeilen und kann nirgends außer in sein eigenes Statusverzeichnis schreiben.
Im Normalfall ist die Capability-Menge leer. Die einzige Ausnahme ist ein Direkt-Download-Listener auf einem Port unter 1024, der zum Binden CAP_NET_BIND_SERVICE braucht; der voreingestellte Download-Port ist 2053, also über 1024, sodass gar nichts gewährt wird.
Der Node besitzt keine Schlüssel. Dateien werden vom Absender vor dem Hochladen verschlüsselt, auf einem Speicher-Node landet also Chiffretext, den er nicht lesen kann — das gilt auch für deinen eigenen Node und auch für dich.

Was die Auto-Aktualisierung kann und was nicht

Der Installer richtet außerdem einen Selbstaktualisierungs-Timer ein, standardmäßig aktiv: relayium-node-update.timer fragt relayium.com etwa alle zehn Minuten, welche Version dieser Node laufen lassen soll. Das ist eine zweite Unit, und sie läuft als root — sie schuldet dir also eine eigene Erklärung.

Die Zentrale schickt nie eine Binärdatei. Ihre gesamte Antwort besteht aus einer Versionsnummer, zwei Flags (darf dieser Node jetzt wechseln, und ist das ein bewusstes Downgrade) und einer kurzen Begründung — keine Bytes, keine URL, kein Befehl. Der Node holt sich dieses Release anschließend selbst, prüft den SHA-256 des Archivs gegen die checksums.txt des Releases und verifiziert eine ECDSA-P-256-Signatur über die checksums.txt mit einem öffentlichen Schlüssel, der in genau die Binärdatei einkompiliert ist, die diese Prüfung durchführt. Die private Hälfte dieses Schlüssels liegt nicht auf dem Server, der diese Abfragen beantwortet. Eine kompromittierte Zentrale könnte also eine Version benennen; eine Binärdatei, die die Prüfung besteht, könnte sie nicht herstellen.

Aktualisierer und Node sind zwei getrennte Prozesse mit entgegengesetzten Rechten. relayium-node.service ist die obige Sandbox — unter ProtectSystem=strict kann er überhaupt nicht nach /usr/local/bin schreiben, der Node kann also nie eine Binärdatei verändern, auch nicht seine eigene. relayium-node-update.service ist eine kleine oneshot-Unit, die als root läuft und bewusst keine Sandbox trägt, denn eine Datei in /usr/local/bin zu ersetzen erfordert genau das Privileg, das die Sandbox des Nodes ihm verwehren soll. Diese Macht in einer einzigen Unit mit einem einzigen Zweck zu bündeln, statt die Härtung des Nodes aufzuweichen, ist der ganze Sinn der Trennung: Der Prozess mit root tauscht nur Binärdateien aus, und der Prozess im Käfig kommt an keine heran.

Eine misslungene Aktualisierung macht sich selbst rückgängig. Der Aktualisierer legt die alte Binärdatei neben die neue, startet den Dienst neu und wartet bis zu zehn Minuten auf einen Heartbeat; meldet sich die neue Version in diesem Fenster nicht gesund, stellt er die alte Binärdatei zurück, startet erneut neu und vermerkt die fehlerhafte Version, damit sie nicht wieder versucht wird. Gespeicherte Dateien werden dabei nie gelesen, verschoben oder gelöscht.

Nicht erwünscht: Führe den Installer erneut mit RELAYIUM_NODE_AUTO_UPDATE=off aus. Der Timer und sein Dienst werden deaktiviert und gelöscht; der Node läuft weiter, und du aktualisierst ihn, wann du willst.
Node ganz aufgeben: siehe „Node entfernen“ weiter unten.

Node entfernen

Die Deinstallation ist ein einziges Skript — dasselbe, ob dein Node Dateien speichert oder nur weiterleitet. Es entfernt die Units, die Binärdatei, die Konfiguration und das Dienstkonto und meldet relayium.com nach bestem Wissen, dass der Node weg ist. Schlägt dieser Aufruf fehl, ist das eine Zeile auf deinem Terminal und keine kaputte Deinstallation — die ausgegebene Node-ID erlaubt es, ihn von Hand als entfernt zu markieren.

Herunterladen, prüfen, dann ausführen. Direkt in sh zu pipen bedeutet, dass ein 404 oder ein kurzer Netzaussetzer den ganzen Befehl nichts ausgeben und mit Code 0 enden lässt — was wie eine erfolgreiche Deinstallation aussieht.

Entfernt wird nur, was es kennt: Unerwartetes im Status- oder Speicherverzeichnis wird behalten und gemeldet statt mitgelöscht.

curl -fsSL https://relayium.com/uninstall-node.sh -o uninstall-node.sh && \
  [ -s uninstall-node.sh ] && sudo sh uninstall-node.sh

Es verweigert die Deinstallation, solange im Speicherverzeichnis noch eine Datei liegt, die es nicht kennt — auch ein abgelaufener Blob, den die Aufräumung noch nicht erreicht hat. Jede gespeicherte Datei liegt auf genau einem Node, Repliken gibt es nicht. Warte, bis dieser Zähler null ist, oder übergib RELAYIUM_NODE_FORCE=1 und nimm in Kauf, dass diese Dateien unerreichbar werden.
Kann es nicht ermitteln, wo deine Blobs liegen, hält es an, statt zu raten. RELAYIUM_NODE_ASSUME_NO_STORAGE=1 ist der einzige Weg daran vorbei — und löscht weiterhin nichts, was es nicht kennt.
Das Speicherverzeichnis selbst bleibt erhalten, sofern du nicht zusätzlich RELAYIUM_NODE_PURGE_STORAGE=1 übergibst. Umgebungsvariablen überleben | sudo sh nicht — übergib sie als sudo env RELAYIUM_NODE_PURGE_STORAGE=1 sh uninstall-node.sh.
Danach sollte systemctl status relayium-node not-found melden und kein relayium-node-Timer mehr gelistet sein. Installierst du später erneut, ist der Node, den dein Konto bekommt, ein ganz neuer: die Deinstallation löscht die Identitätsdatei, eine Neuinstallation registriert also einen frischen Node statt den alten wiederzubeleben.

Wenn es nicht funktioniert

Fünf Fehler decken fast jeden Node ab, der nicht hochkommt, und drei davon sehen vom Server aus gesund aus: Der Dienst läuft, und nur die Kontoseite oder ein lauschender Socket sagt etwas anderes.

Symptom, Prüfung, Lösung

Die Shell antwortet "relayium-node: command not found".

command -v relayium-node
# keine Ausgabe

Das Binary ist nicht installiert. relayium-node wird nie separat installiert — der Einzeiler von der Kontoseite ist das, was es herunterlädt, in deinen PATH legt und als Dienst startet. Führ stattdessen diesen Befehl aus.

Der Dienst ist active, aber der Node springt auf der Kontoseite nie auf Online.

journalctl -u relayium-node -n 50 --no-pager

Über Online entscheidet ein ausgehender Heartbeat, eine Firewall ist hier also selten die Ursache — die Registrierung ist es. Das Token gilt einmal, ein bereits ausgeführter oder ein alter Befehl aus einem früheren Versuch scheitert deshalb. Klick erneut auf Node hinzufügen und führ den frischen Befehl aus.

Der Node steht auf Online, aber Übertragungen laufen weiter über unsere geteilte Infrastruktur.

sudo ss -lunp | grep 3478

Online belegt nur den ausgehenden Heartbeat. Peers brauchen die eingehenden Ports: Prüfe, dass der Node lauscht, und öffne dann 3478/udp, 8081/tcp und 49152-65535/udp in der Host-Firewall UND in der Cloud-Security-Group. Um ein stilles Zurückfallen ganz auszuschließen, schalte die Einstellung für ausschließlich eigene Nodes ein.

Die Deinstallation gab nichts aus, endete mit 0, und der Dienst ist noch da.

systemctl status relayium-node
# active (running)

Genau so sieht es aus, wenn ein fehlgeschlagener Download in sh gepipet wird: Ein 404 oder ein kurzer Netzaussetzer gibt nichts aus und endet mit 0, was sich wie Erfolg liest. Lad das Skript herunter, prüfe, dass es nicht leer ist, und führ es dann aus — deshalb steht der Befehl in dieser Anleitung in drei Teilen und nicht als eine Pipe.

Die Deinstallation verweigert sich, solange im Speicherverzeichnis noch Dateien liegen.

sudo ls /var/lib/relayium-node/blobs | wc -l

Das ist Absicht. Jede gespeicherte Datei liegt auf genau einem Node, Repliken gibt es nicht — den Node zu entfernen macht sie also unerreichbar. Warte, bis die Zahl mit dem Ablaufen der Blobs auf null geht, oder nimm den Verlust mit RELAYIUM_NODE_FORCE=1 in Kauf. Umgebungsvariablen überleben eine Pipe nach sudo sh nicht, übergib sie also als sudo env RELAYIUM_NODE_FORCE=1 sh uninstall-node.sh.

Häufig gestellte Fragen

Ich habe „relayium-node: command not found“ bekommen — was ist schiefgelaufen?

Du hast die relayium-node-Binärdatei ausgeführt, bevor du sie installiert hast. Verwende den Einzeiler-Installationsbefehl von der Kontoseite (in der Form curl … | sudo … sh): Er lädt die Binärdatei herunter, legt sie in deinen PATH und startet sie als Dienst. Du installierst relayium-node nie separat.

Bleibt der Node nach einem Neustart online?

Ja. Der Installer registriert einen systemd-Dienst, der beim Booten aktiviert und auf Restart=always gesetzt ist, sodass er nach einem Neustart zurückkehrt und sich bei einem Absturz selbst neu startet. Es ist nichts weiter auszuführen.

Wie unterscheidet sich das davon, Relayium selbst zu hosten?

Bring-your-own-node behält dein normales relayium.com-Konto und deine Apps bei und fügt lediglich einen Node hinzu, der dir gehört und deinen Verkehr trägt. Hostest du Relayium selbst, läuft der gesamte Server-Stack (Konten, Web-App, Signalisierung) auf deiner eigenen Domain — siehe dazu die Anleitung „Relayium selbst hosten“.

Kann jemand anderes meinen Node nutzen oder meine Daten sehen?

Nein. Ein Node ist über seinen Token an dein Konto gebunden und trägt nur den Verkehr deines Kontos. Echtzeit-Übertragungen sind Ende-zu-Ende-verschlüsselt und gespeicherte Blobs sind Chiffretext, den dein Node nicht lesen kann. Deine Daten und deine Node-Konfiguration sind ausschließlich von dir nutzbar.

Melde dich an, öffne deine Kontoseite und füge in unter einer Minute deinen ersten Node hinzu.

Kontoseite öffnen