Apportez votre propre nœud : utilisez gratuitement le relais et le stockage de Relayium

Dernière mise à jour: 2026-08-06

Les transferts inter-réseaux et les liens stockés consomment de la bande passante de relais et de l'espace disque qui nous coûtent de l'argent ; ils fonctionnent donc dans la limite d'un quota gratuit et deviennent payants au-delà. Il existe un moyen de contourner cela : faites tourner votre propre nœud de relais/stockage, rattachez-le à votre compte, et vos transferts passent par votre nœud au lieu du nôtre — rien de mesuré, rien de facturé.

C'est différent d'auto-héberger l'ensemble du serveur Relayium. Vous continuez à utiliser votre compte relayium.com habituel et les mêmes applications ; vous ajoutez simplement un nœud qui vous appartient pour acheminer votre trafic. Ce guide vous mène d'une machine Linux vierge à un nœud en ligne en environ cinq minutes.

Pourquoi faire tourner votre propre nœud

Deux raisons. D'abord, le coût : un nœud qui vous appartient achemine directement votre trafic de relais et de stockage, il ne touche donc jamais notre infrastructure facturée à l'usage et il n'y a rien à facturer — votre utilisation est gratuite, quelle que soit son ampleur.

Ensuite, le contrôle : les octets relayés et les blobs stockés résident sur du matériel que vous exploitez, sous votre propre contrôle opérationnel. Les transferts en temps réel restent chiffrés de bout en bout sur tout le trajet, de sorte que même votre propre nœud ne voit jamais que du texte chiffré.

Installer le nœud et le mettre en ligne

Quatre choses dans l'ordre : générer la commande, l'exécuter, ouvrir les ports et confirmer que le nœud est passé en ligne. Environ cinq minutes sur une machine neuve.

1. Connectez-vous sur relayium.com et ouvrez votre page de compte, /me.

2. Descendez jusqu'à Mes nœuds et cliquez sur Ajouter un nœud. Copiez tout de suite la commande d'installation — le jeton qu'elle contient n'est affiché qu'une fois et ne peut pas être réaffiché.

3. Collez-la sur votre serveur. Elle télécharge le binaire relayium-node, en vérifie la somme de contrôle, l'installe dans /usr/local/bin, écrit un service systemd et le démarre.

   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

4. Vérifiez que le service tourne et qu'il reviendra après un redémarrage. Les deux réponses comptent : active dit qu'il tourne maintenant, enabled est ce qui survit à un redémarrage.

   systemctl is-active relayium-node

   systemctl is-enabled relayium-node

5. Ouvrez les ports entrants dans le pare-feu de l'hôte. L'état En ligne ne demande qu'un accès sortant, mais c'est par ces ports que les pairs relaient et stockent.

   sudo ufw allow 3478/udp        # TURN
   sudo ufw allow 8081/tcp        # storage
   sudo ufw allow 49152:65535/udp # relay

6. Sur un VPS cloud, autorisez aussi les mêmes ports dans le groupe de sécurité du fournisseur. Avec ufw seul ils restent bloqués en amont, et le nœud a l'air parfaitement sain pendant tout ce temps.

7. De retour sur /me, regardez le nœud passer En ligne — en général en une trentaine de secondes. À partir de là, les transferts de votre compte le préfèrent automatiquement.

8. Facultatif : activez « N'utiliser que mes propres nœuds pour le relais et le stockage » pour qu'un transfert échoue au lieu de revenir discrètement sur notre infrastructure partagée.

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

• La partie <your-token> est renseignée pour vous sur la page du compte — ne collez pas le paramètre fictif ci-dessus tel quel.
• RELAYIUM_NODE_STORAGE_DIR active le stockage de blobs en plus du relais. Laissez-le désactivé (omettez la variable) si vous voulez que le nœud ne fasse que relayer, pas stocker.
• Vérifiez qu'il a démarré : systemctl status relayium-node (devrait indiquer active/running).
• Confirmez la persistance au démarrage : systemctl is-enabled relayium-node (devrait indiquer enabled).
• Suivez les journaux en direct : journalctl -u relayium-node -f.
• 3478/udp est le port TURN que les pairs utilisent pour relayer ; 8081/tcp est le port HTTP du stockage de blobs ; 49152–65535/udp est la plage média du relais.
• Sur un VPS cloud, autorisez-les aussi dans le groupe de sécurité / pare-feu réseau du fournisseur, pas seulement dans ufw.

Est-il prudent d'exécuter cet installateur en root ?

Avant tout : les nœuds que vous apportez tournent avec le même code et le même durcissement que les nœuds de notre propre flotte — le même binaire issu de la même version signée, installé par le même script, sous la même unité systemd. La seule différence est de savoir à qui appartient la machine. Tout ce qui suit décrit les deux.

La question est légitime pour une commande qui achemine un script pris sur Internet vers un shell root, et elle mérite une réponse précise plutôt qu'une formule rassurante. root sert à l'installation et à rien de ce que le nœud fait ensuite. L'installateur crée un compte système nommé relayium-node, sans shell de connexion ni répertoire personnel, écrit les unités systemd, démarre le service et se termine. Le nœud lui-même ne tourne jamais en root : son unité fixe User=relayium-node, si bien que dès la seconde où il est en ligne, c'est un compte non privilégié qui ne possède rien d'autre sur votre machine. (La mise à jour automatique, active par défaut, ajoute bien une seconde unité qui, elle, tourne en root — la section suivante lui est entièrement consacrée.)

Autour de ce compte, l'unité dresse un bac à sable systemd. Chaque ligne vise quelque chose qu'un attaquant chercherait à atteindre s'il prenait un jour le contrôle du processus du nœud. Rien ne vous est caché : après l'installation, lisez l'unité entière avec cat /etc/systemd/system/relayium-node.service.

• ReadWritePaths et NoExecPaths ne désignent le répertoire de stockage que sur un nœud qui stocke réellement. Un nœud purement relais n'a ni l'une ni l'autre de ces lignes et ne peut écrire nulle part sauf dans son propre répertoire d'état.
• Dans le cas normal, l'ensemble des capabilities est vide. La seule exception est un processus à l'écoute pour le téléchargement direct sur un port inférieur à 1024, qui a besoin de CAP_NET_BIND_SERVICE pour s'y attacher ; le port de téléchargement par défaut est 2053, au-dessus de 1024, donc rien n'est accordé.
• Le nœud ne détient aucune clé. Les fichiers sont chiffrés par l'expéditeur avant d'être téléversés : ce qui arrive sur un nœud de stockage est du texte chiffré qu'il ne peut pas lire — y compris sur votre propre nœud, et y compris pour vous.

Ce que la mise à jour automatique peut et ne peut pas faire

L'installateur met aussi en place un minuteur de mise à jour automatique, actif par défaut : relayium-node-update.timer demande à relayium.com, environ toutes les dix minutes, quelle version ce nœud devrait exécuter. C'est une seconde unité, et elle tourne en root : elle vous doit donc ses propres explications.

Le serveur central n'envoie jamais de binaire. Toute sa réponse tient en un numéro de version, deux options (ce nœud peut-il bouger maintenant, et s'agit-il d'un retour en arrière délibéré) et une brève justification — pas d'octets, pas d'URL, pas de commande. C'est ensuite le nœud qui récupère lui-même cette version, compare le SHA-256 de l'archive au checksums.txt de la version, puis vérifie une signature ECDSA P-256 sur ce checksums.txt à l'aide d'une clé publique compilée dans le binaire même qui effectue la vérification. La moitié privée de cette clé ne se trouve pas sur le serveur qui répond à ces sondages. Un serveur central compromis pourrait donc nommer une version ; il ne pourrait pas fabriquer un binaire qui passe la vérification.

Le programme de mise à jour et le nœud sont deux processus distincts aux pouvoirs opposés. relayium-node.service, c'est le bac à sable ci-dessus — sous ProtectSystem=strict, il ne peut pas écrire du tout dans /usr/local/bin, donc le nœud ne peut jamais modifier un binaire, pas même le sien. relayium-node-update.service est une petite unité oneshot qui tourne en root et ne porte délibérément aucun bac à sable, car remplacer un fichier dans /usr/local/bin exige précisément le privilège que le bac à sable du nœud existe pour lui refuser. Enfermer ce pouvoir dans une seule unité à usage unique, plutôt que d'assouplir le durcissement du nœud lui-même, est tout l'intérêt de cette séparation : le processus qui détient root ne fait que remplacer des binaires, et celui qui est en cage ne peut jamais en toucher un.

Une mise à jour qui tourne mal se défait d'elle-même. Le programme conserve l'ancien binaire à côté du nouveau, redémarre le service, puis guette un signal de présence pendant dix minutes au plus ; si la nouvelle version ne se déclare pas saine dans cette fenêtre, il remet l'ancien binaire, redémarre à nouveau et note la version fautive pour ne pas la réessayer. Les fichiers stockés ne sont jamais lus, déplacés ni supprimés par tout cela.

• Vous n'en voulez pas : relancez l'installateur avec RELAYIUM_NODE_AUTO_UPDATE=off. Le minuteur et son service sont désactivés puis supprimés ; le nœud continue de tourner et vous le mettez à jour quand vous le décidez.
• Vous arrêtez tout : voir « Retirer votre nœud » plus bas.

Retirer votre nœud

La désinstallation tient en un seul script, le même que votre nœud stocke des fichiers ou se contente de relayer. Il retire les unités, le binaire, la configuration et le compte de service, et signale à relayium.com, sans garantie, que le nœud a disparu. Si cet appel échoue, c'est une ligne sur votre terminal et non une désinstallation cassée — l'identifiant du nœud s'affiche pour qu'on puisse le marquer retiré à la main.

Téléchargez-le, vérifiez-le, puis exécutez-le. Le faire passer directement dans sh signifie qu'une 404 ou un accroc réseau fait que toute la commande n'affiche rien et se termine avec le code 0 — ce qui ressemble à une désinstallation réussie.

Il ne retire que ce qu'il reconnaît : tout élément inattendu dans le répertoire d'état ou de stockage est conservé et signalé plutôt que balayé.

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

• Il refuse tant que le répertoire de stockage contient un fichier qu'il ne reconnaît pas — y compris un blob expiré que le nettoyage n'a pas encore atteint — car chaque fichier stocké vit sur un seul nœud et il n'y a pas de réplique. Attendez que ce décompte tombe à zéro, ou passez RELAYIUM_NODE_FORCE=1 en acceptant que ces fichiers deviennent inaccessibles.
• S'il n'arrive pas à déterminer où vivent vos blobs, il s'arrête au lieu de deviner. RELAYIUM_NODE_ASSUME_NO_STORAGE=1 est le seul moyen de passer outre, et il ne supprime toujours rien qu'il ne reconnaisse pas.
• Le répertoire de stockage lui-même est conservé sauf si vous passez aussi RELAYIUM_NODE_PURGE_STORAGE=1. Les variables d'environnement ne survivent pas à | sudo sh — passez-les via sudo env RELAYIUM_NODE_PURGE_STORAGE=1 sh uninstall-node.sh.
• Ensuite, systemctl status relayium-node doit répondre not-found et aucun minuteur relayium-node ne doit être listé. Si vous réinstallez plus tard, votre compte obtient un nœud entièrement nouveau : la désinstallation supprime le fichier d'identité, donc une nouvelle installation enregistre un nœud neuf au lieu de ressusciter l'ancien.

Quand ça ne marche pas

Cinq pannes couvrent presque tous les nœuds qui ne démarrent pas, et trois d'entre elles paraissent saines depuis le serveur : le service tourne, et seuls la page de compte ou une socket en écoute disent le contraire.

Questions fréquentes

J'ai obtenu « relayium-node: command not found » — qu'est-ce qui a mal tourné ?

Vous avez exécuté le binaire relayium-node avant de l'installer. Utilisez la commande d'installation en une ligne de la page du compte (de la forme curl … | sudo … sh) : elle télécharge le binaire, le place dans votre PATH et le démarre en tant que service. Vous n'installez jamais relayium-node séparément.

Le nœud reste-t-il en ligne après un redémarrage ?

Oui. L'installateur enregistre un service systemd qui est activé au démarrage et réglé sur Restart=always, si bien qu'il revient après un redémarrage et se relance de lui-même en cas de plantage. Rien de plus à exécuter.

En quoi est-ce différent d'auto-héberger Relayium ?

Bring-your-own-node conserve votre compte relayium.com et vos applications habituels et ajoute simplement un nœud qui vous appartient pour acheminer votre trafic. L'auto-hébergement fait tourner toute la pile serveur (comptes, application web, signalisation) sur votre propre domaine — voyez le guide « Auto-héberger Relayium » pour cela.

Quelqu'un d'autre peut-il utiliser mon nœud ou voir mes données ?

Non. Un nœud est rattaché à votre compte par son jeton et n'achemine que le trafic de votre compte. Les transferts en temps réel sont chiffrés de bout en bout et les blobs stockés sont du texte chiffré que votre nœud ne peut pas lire. Vos données et la configuration de votre nœud ne sont utilisables que par vous.

Continuer la lecture

• Auto-héberger Relayium : gérez votre serveur de transfert de fichiers et de texte
• Faire tourner Relayium en service de réception permanent
• Comment Relayium chiffre vos fichiers de bout en bout
• Relayium vs Nextcloud pour l'envoi de fichiers
• Relayium