Usa tu propio nodo: aprovecha el retransmisor y el almacenamiento de Relayium gratis

Última actualización: 2026-07-22

Las transferencias entre redes y los enlaces almacenados usan ancho de banda de retransmisión y disco que nos cuestan dinero, así que funcionan con una franquicia gratuita y se pagan a partir de ahí. Hay una forma de evitarlo: ejecuta tu propio nodo de retransmisión/almacenamiento, vincúlalo a tu cuenta, y tus transferencias fluyen por tu nodo en lugar del nuestro — nada medido, nada facturado.

Esto es distinto de autoalojar todo el servidor de Relayium. Sigues usando tu cuenta habitual de relayium.com y las mismas aplicaciones; solo estás añadiendo un nodo que es tuyo para que lleve tu tráfico. Esta guía te lleva de una máquina Linux recién instalada a un nodo en línea en unos cinco minutos.

Por qué ejecutar tu propio nodo

Dos razones. Primero, el coste: un nodo que es tuyo lleva tu tráfico de retransmisión y almacenamiento directamente, así que nunca toca nuestra infraestructura medida y no hay nada que facturar — tu uso es gratis por grande que sea.

Segundo, el control: los bytes retransmitidos y los blobs almacenados residen en hardware que tú operas, bajo tu propio control operativo. Las transferencias en tiempo real siguen cifradas de extremo a extremo durante todo el trayecto, así que incluso tu propio nodo solo ve texto cifrado.

Qué necesitas

Un servidor Linux accesible desde internet — sirve tanto un VPS barato como una máquina siempre encendida en casa. Necesitarás root (o sudo) y la capacidad de abrir unos cuantos puertos entrantes. Se admiten tanto amd64 como arm64.

Paso 1 — obtén tu comando de instalación

Inicia sesión en relayium.com, abre la página de cuenta (/me), desplázate hasta «Mis nodos» y haz clic en «Añadir nodo». Obtendrás un comando de instalación de un solo uso con un token incrustado — el token se muestra una única vez, así que cópialo de inmediato. Tiene este aspecto:

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

La parte <your-token> se rellena por ti en la página de cuenta — no pegues literalmente el marcador de posición de arriba.
RELAYIUM_NODE_STORAGE_DIR activa el almacenamiento de blobs además de la retransmisión. Déjalo desactivado (omite la variable) si solo quieres que el nodo retransmita y no almacene.

Paso 2 — ejecútalo en tu servidor, como root

Pega el comando en tu servidor. Canaliza nuestro instalador a sh: el instalador descarga y verifica por suma de comprobación el binario relayium-node, lo instala en /usr/local/bin, escribe un servicio systemd y lo arranca. El sudo inicial es lo que le permite instalar el servicio; si ya eres root, es un no-op inofensivo.

Como es un servicio systemd, el nodo se habilita al arrancar y se reinicia por sí solo si alguna vez se cae — se mantiene en línea a través de los reinicios sin nada más que hacer. Si ves `relayium-node: command not found`, ejecutaste el binario directamente en lugar del instalador de arriba — es el comando de una línea el que pone el binario en su sitio.

Comprueba que arrancó: `systemctl status relayium-node` (debería indicar active/running).
Confirma la persistencia al arranque: `systemctl is-enabled relayium-node` (debería indicar enabled).
Observa los registros en vivo: `journalctl -u relayium-node -f`.

¿Es seguro ejecutar este instalador como root?

Antes que nada: los nodos que aportas tú ejecutan el mismo código y el mismo endurecimiento que los nodos de nuestra propia flota — el mismo binario de la misma versión firmada, instalado por el mismo script, bajo la misma unidad de systemd. La única diferencia es de quién es la máquina. Todo lo que sigue describe a ambos.

Es una pregunta justa ante un comando que canaliza un script de internet hacia una shell de root, y merece una respuesta concreta en lugar de una frase tranquilizadora. root se usa para la instalación y para nada de lo que el nodo hace después. El instalador crea una cuenta de sistema llamada relayium-node, sin shell de acceso y sin directorio personal, escribe las unidades de systemd, arranca el servicio y termina. El nodo en sí nunca se ejecuta como root: su unidad fija User=relayium-node, así que desde el segundo en que se pone en línea es una cuenta sin privilegios que no posee nada más en tu máquina. (La actualización automática, activada por omisión, sí añade una segunda unidad que se ejecuta como root — la sección siguiente trata por entero de lo que esa unidad puede y no puede hacer.)

Alrededor de esa cuenta, la unidad levanta un espacio aislado de systemd. Cada línea apunta a algo que un atacante intentaría alcanzar si alguna vez se hiciera con el proceso del nodo. Nada de esto se te oculta: tras instalar, lee la unidad completa con `cat /etc/systemd/system/relayium-node.service`.

En la unidad	Qué bloquea si el nodo llega a verse comprometido
`User=relayium-node`	El atacante es un usuario que no posee nada, no root.
`ProtectHome=yes`	/home y /root son invisibles — ni claves SSH privadas, ni datos de otros proyectos.
`ProtectSystem=strict`	Todo el sistema de archivos es de solo lectura; no se puede modificar ningún archivo del sistema.
`ReadWritePaths=`	Los únicos lugares escribibles son el directorio de estado del propio nodo y, si configuraste uno, el directorio de almacenamiento. Escribir en cualquier otro sitio falla.
`NoExecPaths=`	Nada del directorio de almacenamiento se puede ejecutar — un archivo subido no puede echarse a andar.
`NoNewPrivileges=yes`	No hay camino de vuelta a root; los trucos habituales de escalada quedan cerrados.
`CapabilityBoundingSet=`	Vacío — ninguna capability de Linux, ni una.
`ProtectKernelTunables=yes, ProtectKernelModules=yes`	El núcleo queda fuera de alcance: ni cambios de sysctl, ni carga de módulos, ni rootkits.

ReadWritePaths y NoExecPaths solo nombran el directorio de almacenamiento en un nodo que realmente almacena. Un nodo de solo retransmisión no lleva ninguna de las dos líneas y no puede escribir en ningún sitio salvo en su propio directorio de estado.
En el caso normal el conjunto de capabilities está vacío. La única excepción es un proceso a la escucha de descarga directa en un puerto por debajo de 1024, que necesita CAP_NET_BIND_SERVICE para poder asociarse; el puerto de descarga por omisión es 2053, por encima de 1024, así que no se concede nada.
El nodo no guarda ninguna clave. Los archivos los cifra el remitente antes de subirlos, así que lo que llega a un nodo de almacenamiento es texto cifrado que no puede leer — eso incluye tu propio nodo, y te incluye a ti.

Qué puede y qué no puede hacer la actualización automática

El instalador también configura un temporizador de actualización automática, activado por omisión: relayium-node-update.timer pregunta a relayium.com, más o menos cada diez minutos, qué versión debería estar ejecutando este nodo. Es una segunda unidad, y se ejecuta como root, así que te debe su propia explicación.

El servidor central nunca envía un binario. Toda su respuesta es un número de versión, dos indicadores (si a este nodo le toca moverse ahora y si se trata de una vuelta atrás deliberada) y un breve motivo — ni bytes, ni URL, ni comando. Después es el nodo quien descarga esa versión por su cuenta, coteja el SHA-256 del archivo con el checksums.txt de la versión y verifica una firma ECDSA P-256 sobre ese checksums.txt con una clave pública compilada dentro del mismísimo binario que hace la comprobación. La mitad privada de esa clave no está en el servidor que responde a esos sondeos. Un servidor central comprometido podría, pues, nombrar una versión; lo que no podría es fabricar un binario que pase la verificación.

El actualizador y el nodo son dos procesos distintos con poderes opuestos. relayium-node.service es el espacio aislado de arriba — bajo ProtectSystem=strict no puede escribir en /usr/local/bin en absoluto, así que el nodo nunca puede modificar un binario, ni siquiera el suyo. relayium-node-update.service es una pequeña unidad oneshot que se ejecuta como root y que deliberadamente no lleva aislamiento, porque reemplazar un archivo en /usr/local/bin exige exactamente el privilegio que el aislamiento del nodo existe para negarle. Encerrar ese poder en una única unidad de un solo propósito, en vez de aflojar el endurecimiento del propio nodo, es todo el sentido de la separación: el proceso que tiene root solo intercambia binarios, y el proceso enjaulado nunca puede tocar uno.

Una actualización que sale mal se deshace sola. El actualizador conserva el binario anterior junto al nuevo, reinicia el servicio y luego vigila el latido durante diez minutos como máximo; si la nueva versión no se declara sana en esa ventana, repone el binario anterior, reinicia de nuevo y anota la versión defectuosa para no reintentarla. Nada de esto lee, mueve ni borra jamás los archivos almacenados.

Si no la quieres: vuelve a ejecutar el instalador con RELAYIUM_NODE_AUTO_UPDATE=off. El temporizador y su servicio se desactivan y se eliminan; el nodo sigue funcionando y lo actualizas cuando tú decidas.
¿Terminaste del todo con el nodo?: consulta «Eliminar tu nodo» más abajo.

Eliminar tu nodo

Desinstalar es un solo script, el mismo tanto si tu nodo almacena archivos como si solo retransmite. Elimina las unidades, el binario, la configuración y la cuenta de servicio, y hace un intento de mejor esfuerzo por avisar a relayium.com de que el nodo ya no está. Si esa llamada falla, es una línea en tu terminal y no una desinstalación rota: muestra el ID del nodo para poder marcarlo como eliminado a mano.

Descárgalo, compruébalo y luego ejecútalo. Canalizarlo directamente a `sh` significa que un 404 o un corte de red pasajero hace que todo el comando no muestre nada y termine con código 0, lo que parece una desinstalación correcta.

Solo elimina lo que reconoce: cualquier cosa inesperada en el directorio de estado o de almacenamiento se conserva y se informa en vez de barrerse.

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

Se niega mientras el directorio de almacenamiento contenga algún archivo que no reconozca — incluido un blob caducado que la limpieza aún no ha alcanzado — porque cada archivo almacenado vive en exactamente un nodo y no hay réplicas. Espera a que ese recuento llegue a cero, o pasa RELAYIUM_NODE_FORCE=1 aceptando que esos archivos queden inalcanzables.
Si no logra determinar dónde viven tus blobs, se detiene en lugar de adivinar. RELAYIUM_NODE_ASSUME_NO_STORAGE=1 es la única forma de saltarse eso, y sigue sin borrar nada que no reconozca.
El directorio de almacenamiento se conserva salvo que pases también RELAYIUM_NODE_PURGE_STORAGE=1. Las variables de entorno no sobreviven a `| sudo sh`: pásalas como `sudo env RELAYIUM_NODE_PURGE_STORAGE=1 sh uninstall-node.sh`.
Después, `systemctl status relayium-node` debería decir not-found y no debería listarse ningún temporizador relayium-node. Si vuelves a instalarlo más adelante, tu cuenta obtiene un nodo completamente nuevo: la desinstalación borra el archivo de identidad del nodo, así que una instalación nueva registra un nodo nuevo en lugar de revivir el anterior.

Paso 3 — abre los puertos entrantes

Estar en línea (un latido hacia relayium.com) solo necesita acceso saliente, que ya tienes. Pero para que otros pares realmente retransmitan a través de tu nodo y almacenen en él, sus puertos entrantes deben ser accesibles. Si el host ejecuta un cortafuegos, ábrelos — con ufw es así:

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

3478/udp es el puerto TURN que los pares usan para retransmitir; 8081/tcp es el puerto HTTP del almacenamiento de blobs; 49152–65535/udp es el rango de medios de la retransmisión.
En un VPS en la nube, permítelos también en el grupo de seguridad / cortafuegos de red del proveedor, no solo en ufw.

Paso 4 — confirma y enruta el tráfico a través de él

De vuelta en la página de cuenta, tu nodo aparece bajo «Mis nodos» y cambia a «En línea» en unos 30 segundos. A partir de entonces, las transferencias de tu cuenta prefieren tu propio nodo automáticamente.

Para forzarlo — que nunca recurra a nuestra infraestructura compartida — activa «Usar solo mis propios nodos para retransmisión/almacenamiento» en la misma página. Con eso activado, si ninguno de tus nodos está en línea, una transferencia falla en lugar de usar discretamente los nuestros.

Preguntas frecuentes

Recibí «relayium-node: command not found» — ¿qué salió mal?

Ejecutaste el binario relayium-node antes de instalarlo. Usa el comando de instalación de una línea de la página de cuenta (la forma curl … | sudo … sh): descarga el binario, lo coloca en tu PATH y lo arranca como servicio. Nunca instalas relayium-node por separado.

¿El nodo sigue en línea tras un reinicio?

Sí. El instalador registra un servicio systemd que se habilita al arrancar y está configurado con Restart=always, así que vuelve tras un reinicio y se reinicia por sí solo si se cae. Nada más que ejecutar.

¿En qué se diferencia esto de autoalojar Relayium?

Usar tu propio nodo conserva tu cuenta y aplicaciones habituales de relayium.com y solo añade un nodo que es tuyo para llevar tu tráfico. El autoalojamiento ejecuta toda la pila del servidor (cuentas, aplicación web, señalización) en tu propio dominio — consulta la guía «Aloja Relayium por tu cuenta» para eso.

¿Puede alguien más usar mi nodo o ver mis datos?

No. Un nodo está vinculado a tu cuenta por su token y solo lleva el tráfico de tu cuenta. Las transferencias en tiempo real están cifradas de extremo a extremo y los blobs almacenados son texto cifrado que tu nodo no puede leer. Tus datos y la configuración de tu nodo solo los puedes usar tú.

Inicia sesión, abre tu página de cuenta y añade tu primer nodo en menos de un minuto.

Abrir la página de cuenta