Alojar Matrix Synapse y Element en tu propio VPS

Las herramientas de mensajería de equipo clásicas — Slack, Teams, e incluso las alternativas auto-alojadas — comparten un límite: solo puedes hablar con miembros del mismo servidor. Matrix invierte esto. Es un protocolo FEDERADO: tu servidor habla con todos los demás servidores Matrix del mundo, exactamente como una dirección de correo llega a cualquier otro dominio. Tus usuarios conservan una identidad ligada a ti (@alice:your-domain.com) mientras charlan con personas alojadas en otro lugar. A eso se suma el cifrado de extremo a extremo, por sala: incluso tú, como administrador del servidor, no puedes leer los mensajes de una sala cifrada. Eso es lo que distingue a Matrix de la mensajería simplemente auto-alojada — la soberanía no depende de la confianza en el alojador, sino de la criptografía.

Element Web es una aplicación web de código abierto — puedes alojarlo en tu propio dominio en lugar de usar app.element.io. Esta elección a menudo se pasa por alto, pero importa. Cuando tus usuarios abren app.element.io, su navegador carga JavaScript desde los servidores de Element HQ: esto no afecta la confidencialidad de los mensajes (el cifrado permanece local), pero crea una dependencia externa.

Alojar Element Web tú mismo — típicamente detrás de chat.your-domain.com — elimina esa dependencia. Controlas la versión desplegada, puedes personalizar config.json para que la interfaz esté preconfigurada con tu servidor, y tus usuarios solo tienen una URL que recordar.

Punto importante: Element Web lee config.<dominio>.json ANTES que config.json. Si tu configuración no se sirve correctamente, la interfaz se muestra perfectamente — y conecta a tus usuarios con el servidor público en lugar del tuyo. Verifica que ambos archivos respondan con tu configuración antes de invitar usuarios.

Esta es la particularidad de Matrix, y la fuente de error más costosa. El server_name de tu servidor — tu nombre de dominio — no es un ajuste de visualización: está inscrito DENTRO de la identidad de cada objeto que produce el servidor. Cada identificador de usuario (@alice:your-domain.com), cada identificador de sala, cada evento firmado lo contiene. Cambiarlo después no es posible: hay que partir de un servidor en blanco y recrear las cuentas. Elige el subdominio definitivo desde la instalación, y vincúlalo cuando instales la aplicación — no después. En ServOrbit, la instalación se niega deliberadamente a arrancar si no hay dominio vinculado: mejor un fallo inmediato y claro que un servidor que habrá que rehacer una vez creadas las cuentas.

La pila completa — Synapse, PostgreSQL, Element Web y el reverse proxy — consume alrededor de 300 MB en reposo, medido en una instalación nueva. Un VPS con 2 GB de RAM y 2 vCPUs es más que suficiente para un equipo, una asociación o una familia.

El consumo depende principalmente de las salas PÚBLICAS a las que te unes: Synapse conserva el historial y el estado de cada sala federada, y unirse a varias salas comunitarias grandes puede hacer crecer la base de datos varios gigabytes. Para ese caso de uso, apunta a 4 GB de RAM y monitorea el espacio en disco.

PostgreSQL es indispensable — Synapse acepta SQLite, pero no lo recomienda más allá de un servidor de prueba. También prevé un certificado TLS válido: sin HTTPS, la federación y las apps móviles se niegan a conectar.

Synapse expone una API de administración en /_synapse/admin/v1 — reservada para cuentas marcadas como admin. A través de esta API, puedes desactivar una cuenta, purgar el historial de una sala, forzar el cierre de sesión de todos los dispositivos de un usuario o consultar estadísticas de federación.

Synapse Admin (interfaz web de código abierto, desplegable como contenedor separado) utiliza esta misma API y ofrece una vista gráfica: lista de usuarios, salas, dispositivos registrados y tamaño de la base de datos por sala. Útil para detectar una sala federada que está haciendo crecer la base de datos varios gigabytes.

Para las actualizaciones, Synapse publica sus imágenes en ghcr.io/element-hq/synapse. Revisa las notas de lanzamiento antes de cada actualización mayor: algunas migraciones de base de datos son irreversibles, y Synapse documenta explícitamente las versiones mínimas requeridas para pasar de una rama a otra.

Un servidor federado acumula el historial de todas las salas a las que se une — incluidas las grandes salas públicas. Sin purgas regulares, la base de datos PostgreSQL puede alcanzar decenas de gigabytes en pocos meses.

Synapse ofrece dos mecanismos. La purga de historial vía la API de administración (POST /_synapse/admin/v1/purge_history) elimina eventos anteriores a una fecha en una sala concreta — sin afectar a otras salas ni a mensajes que aún no has leído. El comando synapse_auto_compressor comprime después los grupos de state_groups en PostgreSQL, lo que puede reducir a la mitad el tamaño de la base en un servidor activo desde hace varios meses.

Activa también gc_thresholds en homeserver.yaml para controlar el recolector de basura de Python de Synapse: en un servidor federado activo, el GC por defecto raramente es óptimo para la memoria residente.

Una de las ventajas distintivas de Matrix es su ecosistema de bridges — servicios que enlazan tu servidor con otras redes. Matterbridge, Beeper o los bridges oficiales del proyecto Matrix retransmiten mensajes entre una sala Matrix y un grupo de Telegram, un canal de Slack o una conversación de WhatsApp.

Cada bridge se despliega como un servicio adicional (un contenedor extra en tu compose.yml) y se registra con Synapse a través de un archivo registration.yaml. El bridge recibe una porción del espacio de identificadores (@telegram_*:your-domain.com) y traduce los mensajes en ambas direcciones.

Para Telegram, mautrix-telegram es el bridge más mantenido. Para Signal, mautrix-signal. Ambos bridges requieren una cuenta en la red objetivo. WhatsApp y Meta Messenger pasan por mautrix-meta, que usa la API no oficial: su funcionamiento depende de las decisiones de Meta y puede interrumpirse.