Autoalojar Matrix en un VPS.
Synapse + Element. Federado. Cifrado de extremo a extremo.

Matrix es un protocolo abierto de comunicación en tiempo real. Un homeserver es un servidor que ejecuta el protocolo; los usuarios pertenecen a un homeserver cada uno, identificados como @alice:example.com — el mismo patrón que el correo electrónico. Las salas son las unidades de conversación; una sola sala puede tener miembros de muchos homeservers diferentes, y el estado de la sala se replica en todos los homeservers participantes. Las salas privadas cifran cada mensaje con claves por dispositivo (Olm/Megolm) para que el servidor solo vea texto cifrado. Toda la red es un grafo de homeservers que federan el estado de las salas entre sí.

Las propiedades interesantes: ninguna autoridad central puede apagar Matrix (el protocolo es abierto y funciona en todas partes), los usuarios en diferentes servidores se comunican de forma transparente (federación), las salas privadas tienen cifrado de extremo a extremo adecuado (no cifrado en tránsito de tipo publicitario), y un usuario puede cambiar de homeserver y mantener su identidad ejecutando el suyo propio. La contrapartida es la complejidad operativa — ejecutar un homeserver es más trabajo que iniciar sesión en Discord — y un ecosistema de clientes pulidos más pequeño que el de las plataformas propietarias.

Lo que despliega en esta guía: Synapse (el homeserver), PostgreSQL (su base de datos), Element Web (el cliente de navegador, alojado desde su propio dominio) y Caddy (el proxy inverso + TLS automático). Opcionalmente un backend de almacenamiento de medios y los endpoints well-known para el descubrimiento de federación. Todo el stack son dos archivos Docker Compose y una configuración de Caddy.

Inicie un VPS de Debian 12 nuevo, apunte tres registros DNS hacia él: matrix.example.com (el nombre de host del homeserver), element.example.com (el cliente web) y example.com en sí si desea el identificador corto @alice:example.com. Acceda por SSH como usuario sudo.

1. Instalar Docker y Compose. curl -fsSL https://get.docker.com | sh — Docker Engine incluye Compose v2 en el mismo paquete.

2. Generar la configuración de Synapse. mkdir -p ~/synapse/data && docker run -it --rm -v ~/synapse/data:/data -e SYNAPSE_SERVER_NAME=example.com -e SYNAPSE_REPORT_STATS=no matrixdotorg/synapse:latest generate — esto escribe homeserver.yaml. Edítelo: cambie la base de datos de SQLite a PostgreSQL, establezca la URL de medios, establezca enable_registration: false para empezar (por ahora cree usuarios vía el CLI de administración).

3. Escribir docker-compose.yml. Tres servicios: postgres (postgres:16, volumen persistente, locale C), synapse (matrixdotorg/synapse:latest, monta ~/synapse/data, depende de postgres), element (vectorim/element-web:latest, monta un pequeño config.json que apunta a https://matrix.example.com). Mapee solo synapse:8008 y element:80 a localhost; no haga bind a 0.0.0.0.

4. Poner Caddy al frente. Dos sitios en Caddyfile: matrix.example.com proxy hacia 127.0.0.1:8008 (Synapse) en ambos puertos 443 y 8448 (el puerto de federación); element.example.com proxy hacia 127.0.0.1:8001 (Element Web). Caddy obtiene los certificados Let's Encrypt automáticamente.

5. Descubrimiento de federación (.well-known). Añada dos archivos JSON estáticos en example.com: /.well-known/matrix/server que devuelva {"m.server": "matrix.example.com:443"} y /.well-known/matrix/client que devuelva {"m.homeserver": {"base_url": "https://matrix.example.com"}}. Esto permite que los identificadores cortos @alice:example.com se resuelvan correctamente. Verifique con el Federation Tester en federationtester.matrix.org.

6. Crear el primer usuario. docker exec -it synapse register_new_matrix_user -u alice -p <contraseña> -a -c /data/homeserver.yaml http://localhost:8008 — eso crea una cuenta de administrador. Inicie sesión vía https://element.example.com.

Ejecutar un homeserver de Matrix significa aceptar que el operador es responsable de lo que hace el servidor. En un homeserver privado solo por invitación, esa responsabilidad es pequeña — conoce a cada usuario. En un homeserver público, la responsabilidad escala con la base de usuarios.

Abuso entrante. Una sala pública federada puede verse involucrada en coordinación de abusos, volcados de imágenes o acoso. Synapse expone endpoints de la API de administración para vetar a un usuario (en todas las salas), bloquear un homeserver (sin más federación) y forzar a un servidor a abandonar una sala. El bot Mjolnir agrupa estas acciones en un flujo de trabajo de sala de moderación; el fork Draupnir es su continuación con mantenimiento activo.

Abuso saliente. Una cuenta de usuario comprometida puede publicar contenido abusivo en salas federadas, lo que daña la reputación del servidor ante el resto de la red. Dos medidas de mitigación: limitar la tasa por usuario (los límites por defecto de Synapse son razonables) y requerir verificación por correo electrónico para las nuevas cuentas (eleva el listón ante el registro automatizado).

Postura legal. En la UE, el rol de proveedor de infraestructura otorga fuertes protecciones de responsabilidad de intermediario (Artículo 14 de la Directiva de Comercio Electrónico, Artículo 6 del DSA) — no es responsable del contenido del usuario siempre que responda a las notificaciones de retirada. Las jurisdicciones nórdicas amplían esto con protecciones constitucionales explícitas de libertad de prensa. El mismo homeserver ejecutado en una jurisdicción sin protecciones de intermediario es operativamente más arriesgado; elija la ubicación del proveedor en consecuencia.

El valor predeterminado seguro. Registro solo por invitación, federación habilitada con bloqueos reactivos, Mjolnir / Draupnir instalado pero sin usar hasta que sea necesario, términos de servicio publicados en el sitio web del homeserver con una política de uso aceptable clara. Esa postura cubre al 95% de los operadores sin esfuerzo adicional.