Cómo alojar un servidor SimpleX en un VPS

Qué hace un servidor SimpleX de chat autohospedado

Para autohospedar un servidor SimpleX de chat, ejecute un daemon en un VPS: smp-server, el relay de SMP (simplex messaging protocol). Este mantiene las colas de mensajes en las que sus contactos escriben y de las que leen. Un segundo daemon opcional, llamado xftp-server, retransmite las transferencias de archivos. Ambos proceden del mismo proyecto, simplexmq, y cada uno consta de un único binario, un archivo de configuración y un registro de solo anexado.

Este texto está dirigido al operador, no al usuario de la aplicación. El relay no mantiene cuentas, listas de contactos ni historial de chats. Mantiene colas, algunos mensajes cifrados aún no entregados y un certificado que lo identifica. Lo que usted asume es la disponibilidad del servicio, un pequeño consumo de disco y los metadatos que pasan por su servidor.

Todos los comandos, rutas, puertos y flags siguientes proceden de la documentación del proyecto: la página de alojamiento del servidor SMP, la página del servidor XFTP y el documento de seguridad del protocolo. Cuando un número es relevante, se indica junto a él la página de la que procede.

Por qué una red sin identificadores de usuario sigue necesitando relays

SimpleX no tiene nombres de usuario, números de teléfono ni ID de cuenta. Un contacto es una cola unidireccional: una dirección en un relay en la que un extremo escribe y el otro lee. Dos de tus contactos no comparten ningún identificador que un servidor pueda relacionar.

Aun así, esas colas tienen que estar alojadas en algún sitio por una razón sencilla. Rara vez dos teléfonos están conectados al mismo tiempo. Algo tiene que aceptar un mensaje ahora y conservarlo hasta que el otro dispositivo lo solicite. Esa es toda la función de un relay SMP. Esto también significa que los dos dispositivos nunca se conectan entre sí, por lo que ninguno conoce la dirección IP (protocolo de Internet) del otro. En su lugar, el relay asume esa exposición.

El nombre de host del relay forma parte de la dirección de la cola, por lo que aparece en cada enlace de invitación que compartas desde él. Tenlo en cuenta cuando leas el modelo de amenazas al final.

Qué puede y qué no puede ver un relay

El proyecto describe este modelo de amenazas en protocol/security.md. Conviene leerlo antes de instalar nada, porque después de seguir esta guía ese relay será suyo. Un relay, incluso si un atacante lo controla por completo, no puede conocer el contenido ni el tipo de los mensajes, añadir, duplicar o alterar mensajes individuales sin que pueda detectarse, ni romper el cifrado de extremo a extremo mediante un ataque activo.

La misma página enumera lo que un relay sí puede hacer. Puede saber cuándo un destinatario de una cola está conectado. Puede contar cuántos mensajes pasan por una cola. Puede conocer la dirección IP de un destinatario. Puede descartar todos los mensajes futuros de una cola o falsear el estado de esa cola.

Por tanto, la separación es clara. La confidencialidad es responsabilidad del cliente y el self-hosting no la modifica. Los metadatos y la disponibilidad son responsabilidad del operador del relay, y el self-hosting le asigna ambas responsabilidades a usted.

Qué necesita antes de empezar

• Un VPS con Ubuntu 22.04 o 24.04. El proyecto publica binarios de lanzamiento compilados específicamente para esas dos versiones, en x86-64 y aarch64.
• Un nombre de dominio con un registro A que apunte al VPS, además de un registro AAAA si tiene IPv6. La documentación usa smp1.example.com como ejemplo.
• Acceso root o sudo, y una segunda sesión SSH abierta mientras modifica el firewall.
• Un lugar fuera del servidor para guardar una copia de seguridad, porque el directorio de configuración contiene la identidad del servidor.

En una instancia ARM, use el recurso aarch64 en lugar de x86-64. No cambia nada más en esta guía, y la elección entre planes VPS ARM y x86 depende del precio y del rendimiento por núcleo, no de si este software funciona.

Instale una versión fijada, no "latest"

El proyecto proporciona un script de instalación que descarga la versión actual y registra un comando simplex-servers-update. Funciona. Aun así, fije la versión: si el binario de un relay cambia sin que usted lo controle, no podrá determinar la causa cuando algo falle.

A fecha del 11 de octubre de 2026, la versión más reciente de simplexmq que GitHub no marca como versión preliminar es v6.5.0, publicada el 29 de abril de 2026. Las etiquetas v7.0.0 y v7.0.1 de finales de julio de 2026 y las versiones beta v7.1.0 están marcadas como versiones preliminares. Consulte la página de versiones para elegir la etiqueta que desea y use esa etiqueta en todos los comandos siguientes.

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp no establece ninguna contraseña, por lo que nadie inicia sesión directamente como smp. Cree usted mismo los dos directorios antes de ejecutar cualquier otra cosa, porque /etc/opt pertenece a root y tiene el modo 755. Esto deja al usuario smp sin un directorio de configuración propio donde escribir.

VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-server

Compare ese hash con las sumas de comprobación SHA2-256 publicadas en las notas de la versión para la misma etiqueta. La página del servidor también describe un archivo de sumas de comprobación firmado, _sha256sums, junto con su firma _sha256sums.asc, que se verifica con la clave FB44AF81A45BDE327319797C85107E357D4A17FC. La página de compilaciones reproducibles del proyecto indica otra clave de firma, build@simplex.chat, con la huella digital BBDF 7BDA D154 8B16 836A F5B9 D53B DFD1 53C3 66BA. A fecha del 11 de octubre de 2026, ninguno de los dos archivos de firma está adjunto a las versiones del servidor v6.5.0 o v7.0.1 en GitHub. Por tanto, para esas etiquetas, la comprobación disponible es el hash de las notas de la versión. Si la versión que fija incluye los archivos de firma, confirme en la página de compilaciones reproducibles qué clave la firmó antes de confiar en el resultado.

sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server

Instálelo deliberadamente con root como propietario. El servicio se ejecuta como smp, por lo que un compromiso del servicio no puede modificar el binario desde el que se inicia.

Inicialice el servidor y los dos secretos que muestra

sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"

• --store-log (-l) escribe un registro de colas de solo adición en /var/opt/simplex/smp-server-store.log, de modo que el relay sobreviva a un reinicio. Sin esta opción, un reinicio descarta todas las colas y cualquier contacto encaminado a través de usted deja de funcionar.
• --daily-stats (-s) escribe los contadores en formato CSV en /var/opt/simplex/smp-server-stats.daily.log.
• --fqdn incluye su dominio en el certificado generado. Use --ip si no tiene un dominio.
• --no-password permite que cualquiera cree una cola en su relay. Para mantenerlo privado, establezca create_password en [AUTH] dentro de /etc/opt/simplex/smp-server.ini después de la inicialización, en lugar de pasar --password aquí, porque una línea de comandos queda visible en el historial del shell y en la lista de procesos mientras se ejecuta.

Init genera un certificado y muestra los dos valores que debe conservar. El primero es la huella digital, una cadena base64 que también se escribe en /etc/opt/simplex/fingerprint. El segundo es la dirección completa del servidor, formada por la huella digital y el nombre de host. Copie ambos ahora.

Init también crea /etc/opt/simplex/ca.key, y la documentación indica que debe mover ese archivo a un almacenamiento sin conexión. El motivo es importante: los clientes fijan la huella digital de esa autoridad certificadora, por lo que cualquiera que tenga ca.key puede emitir un certificado de servidor nuevo que sus clientes aceptarán como propio. Sólo necesitará recuperarlo para rotar posteriormente el certificado del servidor con smp-server cert.

Trate init como un paso que se ejecuta una sola vez. La huella digital de su dirección procede de la autoridad que genera init, por lo que regenerar esa autoridad le proporciona una dirección diferente y deja inutilizada la que ya distribuyó.

Ejecútelo con systemd como un usuario sin privilegios

Escriba /etc/systemd/system/smp-server.service exactamente como aparece en la documentación:

[Unit]
Description=SMP server systemd service

[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity

[Install]
WantedBy=multi-user.target

La unidad de upstream también incluye AmbientCapabilities=CAP_NET_BIND_SERVICE. Esa línea es necesaria porque el proceso se ejecuta como smp y los puertos inferiores a 1024 están cerrados para los procesos que no son root. Sin ella, el daemon no puede enlazarse a 80 ni a 443. Añádala si sirve esos puertos. LimitNOFILE=65535 es importante porque cada cliente suscrito mantiene abierta una conexión TCP y el límite predeterminado es muy inferior al que necesita un relay con carga. ExecStopPost copia el registro del almacén en un archivo .bak en cada detención. Esto proporciona un punto de reversión disponible sin coste.

sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server

Un arranque correcto registra la dirección del servidor. Después, confirme que los sockets están realmente abiertos:

sudo ss -tlnp | grep -E ':(443|5223)'

Las dos líneas deben indicar smp-server. Ejecutar el daemon con su propia cuenta y sin permisos de sudo sigue la misma práctica descrita en cuentas por servicio en un VPS. Esto evita que un error en un daemon de red se convierta en un shell de root.

Qué puertos abrir y cuál mantener cerrado

La documentación indica tres: 5223/tcp, 443/tcp y 80/tcp. El puerto 5223 es el transporte SMP. La configuración incluida establece port: 5223,443 en [TRANSPORT], por lo que el mismo protocolo también responde en 443. Esto es importante porque muchas redes restrictivas permiten conexiones salientes por 443 y ningún otro puerto. El puerto 80 sólo es necesario para la página informativa opcional y su redirección a HTTPS.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable

No abra 5224. Es el puerto de control, y la documentación accede a él desde el propio servidor mediante nc 127.0.0.1 5224. Muestra el estado del servidor y elimina colas, por lo que debe permanecer en loopback, con las contraseñas de administrador y de usuario configuradas en [AUTH]. Si no conoce la herramienta, los conceptos básicos de ufw en un VPS explican el orden de las reglas y cómo evitar bloquearse el acceso.

Hay otro control que suele causar problemas. La mayoría de los proveedores ejecuta un firewall de red en el panel, separado de ufw en el servidor. Un puerto puede estar abierto en ufw y, aun así, los paquetes pueden descartarse antes de llegar al servidor.

La dirección del servidor que necesitan sus clientes

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

Esa cadena constituye toda la configuración del cliente. Péguela en los ajustes del servidor de la aplicación o permita que alguien escanee el código QR que muestra la aplicación. La documentación indica que el QR incluye la contraseña, por lo que quien lo escanee también podrá recibir mensajes a través de su servidor.

Hay un comportamiento documentado que sorprende a todo el mundo. Añadir el servidor en la aplicación sólo afecta a los contactos que cree a partir de ese momento. Los contactos existentes permanecen en los relays en los que se crearon sus colas y no se transfieren automáticamente. Por eso tampoco puede apagar un relay al día siguiente de sustituirlo.

Añadir un relay de archivos XFTP

XFTP (protocolo de transferencia de archivos SimpleX) gestiona la parte de archivos de la red. Es un daemon independiente con su propia dirección. Según el anuncio de XFTP del proyecto, los relays no reciben metadatos de archivos: sólo ven fragmentos individuales de 256kb, 1mb o 4mb, cuyo acceso se autoriza mediante credenciales anónimas. Un remitente puede distribuir los fragmentos de un archivo entre varios relays. Por tanto, el servidor almacena piezas, no archivos.

sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"

Su configuración se encuentra en /etc/opt/simplex-xftp/, su estado en /var/opt/simplex-xftp/ y los fragmentos de archivos en la ruta que indique -p. La unidad de systemd tiene la misma estructura, con User=xftp y ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS. La inicialización muestra una dirección xftp:// con el mismo formato que la de SMP y con su propia huella digital en /etc/opt/simplex-xftp/fingerprint.

Hay que planificar un conflicto de puertos. El puerto documentado del servidor XFTP es 443, y la configuración de SMP también incluye 443. Dos procesos no pueden enlazar el mismo puerto en la misma dirección. Por tanto, en un VPS uno de los dos servicios debe usar otro puerto. La solución más sencilla es establecer port: 5223 en la sección [TRANSPORT] de SMP y dejar 443 para el relay de archivos, aunque los clientes de redes restrictivas perderán la alternativa de conexión por 443. Las alternativas son añadir una segunda dirección IP al mismo VPS o usar un segundo VPS.

Asigne la cuota de forma realista. -q '20gb' representa el espacio de disco disponible. El relay de archivos es el componente que consume disco y ancho de banda. El relay de mensajes apenas consume ninguno de los dos.

Qué se almacena en disco y qué restaura una copia de seguridad

Hay dos directorios importantes. /etc/opt/simplex/ contiene la identidad: smp-server.ini, el certificado y la clave del servidor, ca.key y fingerprint. /var/opt/simplex/ contiene el estado: smp-server-store.log almacena las colas y, cuando restore_messages: on, los mensajes no entregados, junto con el archivo de estadísticas diarias.

sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-server

Debe quedar claro qué contiene ese archivo. No es un archivo de mensajes: los elementos en cola son texto cifrado para claves que el relay nunca tuvo, y la configuración distribuida [STORE_LOG] elimina los mensajes después de 21 días de todos modos. Es una copia de la identidad del servidor, incluido ca.key, por lo que cualquiera que obtenga el archivo puede hacerse pasar por su relay ante sus contactos. Cífrelo y manténgalo fuera del servidor.

La ventaja se obtiene al restaurar. Copie /etc/opt/simplex en un VPS nuevo, dirija el mismo nombre DNS hacia él y la huella digital no cambiará, por lo que todas las direcciones que haya distribuido seguirán funcionando. Si pierde ese directorio, no hay recuperación: una instalación nueva implica una huella digital nueva, lo que implica una dirección nueva y significa que todos los contactos que usaban su relay dejarán de estar disponibles.

TLS: dos certificados con funciones distintas

El transporte SMP no utiliza una autoridad certificadora pública. Init genera una autoridad privada y un certificado de servidor, y la huella digital de esa autoridad se incluye en la dirección del servidor. El cliente compara lo que presenta el servidor con esa huella fijada. El proyecto describe este mecanismo como una protección de la conexión entre el cliente y el servidor frente a ataques de tipo machine-in-the-middle. No es necesario ejecutar un cliente ACME (automatic certificate management environment) en ese puerto. La rotación se realiza manualmente con smp-server cert y SMP_SERVER_CFG_PATH configurado.

La página de información opcional utiliza el otro certificado. Su sección [WEB] incluye static_path, https: 443, cert: /etc/opt/simplex/web.crt y key: /etc/opt/simplex/web.key. Un navegador no reconoce su autoridad privada. Por eso, este es el único lugar donde corresponde utilizar un certificado de confianza pública. La guía de inicio rápido de Docker coloca Caddy delante del servidor exactamente para ese fin y emite el certificado automáticamente.

Acceder al relay mediante Tor

La documentación incluye una sección sobre Tor que instala Tor desde el repositorio de Tor Project y añade un servicio onion en /etc/tor/torrc:

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

Lea detenidamente las dos líneas de modo. Un solo salto y sin anonimato significa que la ubicación del relay no está oculta. La dirección onion es rápida y ofrece a los clientes una forma de acceso que nunca revela su dirección IP al operador del relay, pero el servidor sigue siendo localizable mediante su IP pública. El nombre de host onion de /var/lib/tor/simplex-smp/hostname se añade al final de la dirección del servidor, después de una coma. Si también quiere ocultar la ubicación del servidor, necesita una configuración diferente; ejecutar un servicio onion real en un VPS explica las ventajas y desventajas. La diferencia entre lo que oculta cada herramienta se trata en Tor comparado con una VPN y se aplica directamente en este caso.

Modelo de amenazas: qué cambia al alojar el servicio usted mismo

Qué obtiene. Los metadatos (qué colas existen, cuándo se leen y qué direcciones se conectan) quedan en una máquina que usted controla, y usted decide durante cuánto tiempo se conserva cada dato. Tampoco forma parte de un grupo grande cuyos datos puedan solicitarse de una sola vez.

Qué no obtiene, dicho claramente:

• El cifrado no cambia. Los mensajes ya estaban cifrados de extremo a extremo antes de que configurara esto y siguen cifrados de extremo a extremo después. El alojamiento propio es una decisión sobre los metadatos, no sobre la criptografía.
• Su proveedor de VPS ve el tráfico dirigido a su dirección IP y conserva sus datos de facturación. Ha trasladado la confianza de un operador de mensajería a un operador de alojamiento. No la ha eliminado.
• Su relay forma un grupo pequeño. Si atiende a un solo hogar, conectarse a él identifica a ese hogar, y su nombre de host aparece dentro de cada enlace de invitación que envía desde él. Un relay público con mucha actividad le oculta mejor en ese aspecto, y ese es el verdadero intercambio. Un servidor de búsqueda privado tiene la misma característica, por lo que qué oculta realmente SearXNG en su propio VPS depende de cuántas personas compartan la instancia con usted.
• La disponibilidad depende ahora de usted. Un disco lleno o un equipo apagado impide entregar los mensajes, y sus contactos no tienen forma de evitarlo mediante otra ruta.

El mismo razonamiento se aplica a cualquier servicio privado que coloque en un equipo propio, ya sea este relay o una VPN de WireGuard en su propio VPS. Está eligiendo qué parte ve los metadatos. No está haciendo que desaparezcan.

Cuando no funciona

El servicio se inicia y se detiene de inmediato. Lea sudo journalctl -u smp-server -n 50. Un error de enlace indica el puerto que no pudo utilizar. Después, ejecute sudo ss -tlnp | grep :443 para ver qué proceso ya lo está usando. En un servidor recién instalado, normalmente será nginx, Caddy o el servidor XFTP que instaló hace una hora.

Init no puede escribir su configuración. Ejecutar smp-server init como el usuario smp antes de que exista /etc/opt/simplex produce un error de permisos porque /etc/opt pertenece a root. Cree primero el directorio con el propietario correcto y vuelva a ejecutar init.

Los clientes no pueden acceder al relay. Compruebe que el nombre resuelva a la dirección correcta con dig +short smp1.example.com. Después, pruebe el puerto desde su portátil, no desde el servidor: nc -vz smp1.example.com 5223. Si la conexión falla desde fuera mientras ss muestra el socket abierto en el servidor, el problema está en el firewall de red del proveedor. Es un control independiente de ufw.

Un contacto no puede conectarse a través de su relay. La huella digital de la dirección que compartió debe coincidir con el contenido actual de /etc/opt/simplex/fingerprint. Si configuró create_password en [AUTH], la dirección también debe incluir esa contraseña. De lo contrario, el cliente no puede crear una cola.

No se movió nada después de añadir el servidor en la aplicación. Es el comportamiento previsto. Sólo los contactos nuevos utilizan el relay recién añadido. Los contactos existentes conservan las colas que ya tienen.

FAQ

¿Aumenta la seguridad de mis mensajes alojar mi propio servidor SimpleX?

No, y es así por diseño. SimpleX cifra los mensajes de extremo a extremo entre dispositivos, por lo que el relay nunca tiene las claves, independientemente de quién lo administre. El alojamiento propio cambia quién observa los metadatos asociados a esos mensajes: qué colas existen, cuándo se leen y qué direcciones IP se conectan. Es una decisión sobre metadatos. Si el motivo para alojarlo por cuenta propia es obtener un cifrado más fuerte, el cifrado ya estaba disponible.

¿Qué puede ver realmente el operador de un relay SimpleX?

El protocol/security.md del proyecto lo especifica. Un relay no puede leer el contenido ni los tipos de los mensajes, modificar mensajes individuales sin que se detecte ni romper el cifrado de extremo a extremo mediante un ataque activo. Puede ver cuándo el destinatario de una cola está conectado, contar los mensajes que pasan por una cola, conocer la dirección IP de un destinatario, descartar mensajes futuros de una cola o mentir sobre el estado de esa cola. Esas son las capacidades que obtiene cuando el relay es suyo.

¿Necesito un nombre de dominio y un certificado TLS?

Necesita un dominio para una configuración utilizable, y smp-server init acepta --ip si realmente no tiene ninguno. No necesita un certificado de una autoridad pública para el puerto de mensajería: init genera su propia autoridad y el cliente fija la huella digital que aparece en su dirección smp://. Sólo necesita un certificado reconocido públicamente para la página web informativa opcional, configurada como cert y key en la sección [WEB] de smp-server.ini.

¿Qué ocurre si pierdo /etc/opt/simplex?

Todas las direcciones que haya distribuido dejarán de funcionar. Ese directorio contiene la autoridad certificadora cuya huella digital está integrada en la dirección de su servidor, por lo que una reconstrucción genera una huella digital diferente y, por tanto, un servidor diferente. Los contactos cuyas colas están alojadas en ese relay no se pueden reparar desde el cliente. Haga una copia de seguridad cifrada del directorio y guárdela fuera del servidor. Almacene también ca.key sin conexión, como indican los documentos, porque quien lo tenga puede suplantar a su relay.

¿Puedo ejecutar el relay SMP y el relay de archivos XFTP en el mismo VPS?

Sí, pero debe resolver un conflicto. El puerto documentado del servidor XFTP es 443 y la configuración predeterminada de SMP incluye port: 5223,443, por lo que ambos intentan usar el mismo socket. Asigne 443 a uno de ellos: establezca port: 5223 para el servidor SMP, o mueva el relay de archivos a una segunda dirección IP o a un segundo VPS. Ajuste también la cuota de almacenamiento al espacio de disco disponible, porque el relay de archivos es el componente que consume disco y ancho de banda.