Auto-héberger Relayium : gérez votre propre serveur de transfert

Dernière mise à jour: 2026-07-09

Relayium est sous licence MIT et open source, et le serveur est une image unique et autonome — pas de base de données externe, pas de bucket de stockage tiers, rien à quoi s'inscrire. Si vous préférez tout faire tourner vous-même plutôt que dépendre de relayium.com, ce guide vous fait monter un serveur avec Docker et paramètre la CLI pour qu'elle s'y connecte.

S'auto-héberger vous donne un contrôle total sur l'emplacement de vos données, votre propre domaine et certificat TLS, et aucune dépendance aux décisions opérationnelles de quelqu'un d'autre. Tout ce qui suit s'appuie sur des fichiers réellement présents dans le dépôt — docker-compose.yml, server/.env.example et docs/DEPLOYMENT.md — donc rien ici n'est un indicateur ou un réglage qui n'existe pas réellement.

Pourquoi s'auto-héberger

Les transferts en temps réel de Relayium sont déjà pair-à-pair et chiffrés de bout en bout, donc le serveur ne voit jamais les octets de vos fichiers dans ce cas. Mais il conserve bien votre compte et — pour les transferts stockés/basés sur un lien — des blobs chiffrés ainsi qu'une petite base SQLite. S'auto-héberger signifie que ces données vivent sur une infrastructure que vous contrôlez, sous votre propre domaine, sans que les décisions opérationnelles de quelqu'un d'autre n'interviennent.

Le projet étant sous licence MIT et open source (github.com/relayium/relayium), vous pouvez lire exactement ce que fait le serveur avant de lui confier quoi que ce soit, et le forker ou le modifier librement.

Démarrage rapide avec Docker

La racine du dépôt fournit un Dockerfile et un docker-compose.yml qui construisent une seule image autonome — un binaire Go statique servant l'application web précompilée, donc aucun Node, chaîne d'outils Go ou nginx séparés n'est requis juste pour le faire tourner :

docker compose up -d --build

C'est tout le serveur, à l'écoute sur :8080. En production, placez nginx ou Caddy devant pour le TLS — voir docs/DEPLOYMENT.md pour une configuration nginx complète.
La configuration de l'appli provient d'un fichier server/.env optionnel plus le bloc environment: dans docker-compose.yml. Chaque réglage a une clé RELAYIUM_* correspondante — copiez server/.env.example comme point de départ.
Les quatre clés qui comptent pour un déploiement de base : RELAYIUM_ADDR (adresse d'écoute), RELAYIUM_STATIC (chemin vers l'application web compilée), RELAYIUM_DB (chemin du fichier SQLite) et RELAYIUM_BLOB_DIR (où est écrit le chiffré des liens stockés). docker-compose.yml définit déjà des valeurs par défaut raisonnables pour ces quatre clés et les persiste dans un volume nommé.

Ajouter un relais TURN pour les transferts entre réseaux

Les transferts sur le même réseau (LAN) et le push/pull basé sur SSH fonctionnent sans rien de plus. Les transferts en temps réel entre réseaux différents (deux appareils derrière des NAT différents) nécessitent parfois un relais TURN pour établir un chemin — le relais ne voit jamais que du chiffré, jamais le contenu de vos fichiers.

docker-compose.yml a un profil relay optionnel qui démarre coturn (le serveur TURN) et une petite instance Redis pour la mesure des octets relayés, aux côtés du serveur principal :

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

coturn a besoin de la véritable IP publique de l'hôte et d'une plage de ports UDP ouverte pour fonctionner — voir docs/coturn.md pour la configuration complète (avec un script d'installation en une commande) et docs/enable-turn.md pour dépanner un échec limité au NAT traversal.
Sans --profile relay ni RELAYIUM_TURN_SECRET, le serveur fonctionne quand même parfaitement — les transferts entre réseaux différents basculent simplement sur STUN seul, ce qui fonctionne pour les NAT les plus simples mais pas pour les plus stricts.

Paramétrer la CLI pour votre serveur

Par défaut, la CLI Relayium utilise le serveur de rendez-vous de relayium.com pour le send/receive entre réseaux différents. Passez --server pour utiliser le vôtre à la place :

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

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

Quel que soit le serveur utilisé, la CLI est gratuite et ne nécessite aucun compte — --server change seulement le serveur de rendez-vous avec lequel elle communique pour la poignée de main du code d'appairage.
push/pull (via votre propre SSH) ainsi que serve + le push daemon-direct relayium://host ne touchent jamais relayium.com, auto-hébergé ou non — ils se connectent directement à la machine distante que vous indiquez.

Questions fréquentes

Dois-je configurer TURN ?

Seulement si vous voulez que les transferts en temps réel entre réseaux différents fonctionnent à travers des NAT stricts. Les transferts sur le même réseau, le push/pull basé sur SSH et le daemon-direct fonctionnent tous sans TURN — TURN sert uniquement au NAT traversal sur le chemin du code d'appairage entre réseaux différents.

La CLI reste-t-elle gratuite si je m'auto-héberge ?

Oui. Qu'elle parle à relayium.com ou à un serveur que vous exploitez vous-même, la CLI est entièrement gratuite et ne nécessite aucun compte — --server la fait simplement pointer vers votre instance.

Puis-je utiliser mon propre domaine et mon propre certificat TLS ?

Oui. L'image Docker écoute elle-même en HTTP simple sur :8080 ; placez nginx ou Caddy devant avec votre propre domaine et votre certificat (par exemple via certbot/Let's Encrypt). docs/DEPLOYMENT.md contient une configuration nginx complète à reprendre telle quelle.

Quelles données mon serveur auto-hébergé stocke-t-il ?

Une base SQLite (comptes, sessions) sous RELAYIUM_DB et, pour les transferts stockés/basés sur un lien, des blobs chiffrés sous RELAYIUM_BLOB_DIR que le serveur lui-même ne peut pas déchiffrer. Les transferts pair-à-pair en temps réel ne sont stockés nulle part — le serveur ne fait que relayer la poignée de main de signalisation.

Installez la CLI Relayium gratuite et faites-la pointer vers votre propre serveur avec --server.

Obtenir la CLI