La gente se autoaloja un servidor Matrix para que una empresa deje de guardar sus conversaciones, y en eso funciona exactamente como promete. Lo que sorprende después es la forma de lo que has instalado: un homeserver no es una caja privada que además hace chat. Es un nodo de replicación dentro de una red pública, y la federación se comporta mucho más como un protocolo de publicación de lo que espera la mayoría de administradores novatos.
Nada de esto es un argumento en contra de montar uno propio: es el argumento a favor de montarlo a conciencia. La privacidad que ganas es real pero concreta: la custodia pasa a tus manos, nadie más puede cerrarte la cuenta, y las cuestiones legales aterrizan en la jurisdicción que tú elegiste y no en la que eligió una empresa. La privacidad que no ganas es igual de concreta, y casi toda ella vive en el hueco entre «los mensajes están cifrados» y «nadie puede saber quién habla con quién». Esta guía cubre las dos mitades, y después los detalles operativos que deciden si el servidor seguirá sano dentro de un año.
Qué cambia realmente tener tu propio homeserver
Empieza por separar las amenazas, porque un homeserver responde a algunas por completo, a otras solo en parte, y a otras nada en absoluto. La siguiente tabla es la versión honesta del discurso comercial, y conviene leerla antes de elegir el hardware, no después.
| Qué te preocupa | ¿Tu propio homeserver lo soluciona? |
|---|---|
| Que una empresa lea el contenido de tus mensajes | El cifrado de extremo a extremo ya cubre esto en las salas privadas — y sí, autoalojar también elimina a la empresa de la ecuación |
| Que una empresa perfile con quién hablas y cuándo | En parte. Dejas de alimentar a un operador central, pero ahora es tu propio servidor el que guarda ese registro |
| Que otro te cierre o suspenda la cuenta | Sí. La ganancia más clara de todo el ejercicio, y de la que menos se habla |
| Una solicitud legal sobre tus datos | Se traslada, no desaparece. Ahora la solicitud te llega a ti, bajo la ley del país que elegiste |
| Que terceros conozcan tu grafo social | No. Todos los servidores con un miembro en la sala reciben los mismos datos de pertenencia que tú |
| Ocultar que el servidor existe siquiera | No. La federación necesita un nombre público y un puerto accesible; es justo lo contrario de estar oculto |
Lee con atención las dos últimas filas, porque ahí es donde se rompen las expectativas. Si tu objetivo es que nadie pueda establecer siquiera que existe un servicio, Matrix es la herramienta equivocada y un servicio onion se acerca más a lo que buscas. Si tu objetivo es custodia, control y jurisdicción, un homeserver es un instrumento excelente, y el resto de esta guía trata de cómo llevarlo bien.
La federación es un protocolo de replicación disfrazado de protocolo de chat
Este es el mecanismo que explica la mayoría de sorpresas. Cuando uno de tus usuarios se une a una sala alojada en otro sitio, tu servidor no va pidiendo mensajes bajo demanda como un cliente de correo. Se une a la sala como participante en un grafo de eventos distribuido, y después descarga y guarda una copia de los eventos de la sala, su lista de miembros, y el historial de estado suficiente para validar lo que venga después. Desde ese momento tu máquina guarda una réplica, y cada uno de los demás servidores participantes guarda la suya.
Las consecuencias van en las dos direcciones, y ninguna es intuitiva. Los datos que generan tus usuarios — nombre visible, avatar, entradas y salidas, marcas de tiempo, reacciones — se copian a todos los servidores que tengan un miembro en esa sala, y siguen en sus bases de datos hagas lo que hagas después en la tuya. Una redacción es una petición a los demás servidores, no una orden. No existe un «deshacer envío» a través de una federación de servidores operados de forma independiente, y esperarlo es el malentendido más común sobre el protocolo.
En la otra dirección, unirte a salas públicas grandes significa importar el historial ajeno a tu propio disco. Por eso un homeserver recién estrenado con tres usuarios puede acabar con decenas de gigabytes de base de datos: no porque tus tres usuarios hayan escrito mucho, sino porque se unieron a salas con cincuenta mil miembros y años de estado acumulado. Elegir las salas con criterio es tanto una decisión de capacidad como de privacidad.
Qué cubre el cifrado, y qué queda a la vista
Matrix cifra el contenido de los mensajes con Megolm, y en las salas privadas viene activado por defecto. Eso protege la parte que más le importa a la gente, y funciona de verdad: tu servidor guarda texto cifrado que no puede leer, una propiedad real y útil cuando el servidor es hardware alquilado. El sobre que envuelve al mensaje es otra historia, y la diferencia es más amplia de lo que admiten la mayoría de resúmenes.
| Señal | ¿Cifrado? | Visible para |
|---|---|---|
| Texto del mensaje y contenido de los archivos | Sí | Solo los dispositivos verificados de los miembros de la sala |
| Quién está en la sala, y cada entrada o salida | No | Todos los homeservers con un miembro en esa sala |
| Marcas de tiempo, frecuencia de mensajes, horas de actividad | No | Todos los homeservers participantes |
| Nombres visibles, avatares, presencia y «escribiendo…» | No | Todos los homeservers participantes |
| Nombre de la sala, tema y avatar | No | Todos los homeservers participantes |
| Tamaño de los adjuntos y momento de la transferencia | No | Todos los homeservers participantes |
| El dominio de tu servidor y su dirección IP | No | Toda la federación — así está diseñado |
La lectura práctica: el cifrado protege el qué, la federación publica el quién, cuándo y con qué frecuencia. Para la mayoría de comunidades ese intercambio es perfectamente aceptable, y precisamente esa honestidad es el punto. Para un modelo de amenaza donde el grafo social en sí es lo sensible, un protocolo federado tiene la forma equivocada de raíz, y ningún parámetro de configuración lo cambia.
Synapse, Dendrite o Conduit: qué instalar en la práctica
En la práctica importan tres implementaciones, y la elección es sobre todo una decisión de recursos, no una cuestión filosófica.
- Synapse es el servidor de referencia, escrito en Python, y el único donde todas las funciones van bien desde el primer día. También es el más hambriento: la memoria crece con el número y tamaño de las salas a las que se unen tus usuarios, y un servidor con mucho tráfico acaba necesitando dividirse en procesos worker. Elígelo cuando necesites que spaces, herramientas de moderación, bridges y APIs de administración se comporten exactamente como está documentado.
- Dendrite es la reescritura en Go. Notablemente más ligero que Synapse y perfectamente usable para un servidor pequeño, a cambio de ir algo por detrás en funciones. Una opción intermedia razonable cuando Synapse se te queda pesado para la gente que realmente tienes.
- Conduit y su fork activamente mantenido
conduwuitestán escritos en Rust y se distribuyen como un único binario con base de datos embebida. Sacan adelante sin quejarse un servidor familiar o de comunidad pequeña en el plan más básico que vendemos. A cambio, el ecosistema es más reducido: algunas herramientas de administración y varios bridges dan por hecho que usas Synapse.
Para un primer servidor con un puñado de usuarios, el software de la familia Conduit sobre un VPS pequeño es el camino menos doloroso hacia algo que funciona y se mantiene barato. Para cualquier cosa que esperes que crezca — una comunidad pública, una empresa, un proyecto con bridges — empieza directamente en Synapse y ahórrate la migración, porque cambiar de implementación más adelante es un ejercicio de exportar y reconstruir, no un cambio de configuración.
La delegación que todo el mundo configura mal
Matrix separa el nombre que aparece en tus ID de usuario de la máquina que sirve el tráfico, y confundir esto es el error permanente más común al autoalojarse. Tu server_name es el dominio que aparece después de los dos puntos en cada ID de usuario de tu servidor. Pasa a formar parte de tu identidad en la federación en cuanto se firma el primer evento, y no se puede cambiar después sin abandonar todas las cuentas y salas de la máquina.
La configuración que casi siempre quieres: server_name es tu dominio desnudo, mientras que el software corre en un subdominio. Conectas los dos mediante delegación, de una de dos formas. La sencilla es un archivo JSON estático servido en /.well-known/matrix/server en el dominio desnudo, indicando el host y puerto reales. La alternativa es un registro DNS, _matrix._tcp, apuntando al mismo sitio. Sirve también el archivo del lado cliente en /.well-known/matrix/client, para que las apps encuentren el homeserver a partir de una sola dirección.
Decide el nombre antes de instalar nada. Poner server_name igual al subdominio solo porque ahí es donde corre el software es el error clásico, y es irreversible: cada ID de usuario, ID de sala y evento firmado lo lleva encima para siempre. Elige el dominio que te gustaría ver impreso en una tarjeta de visita, delega hacia donde realmente escuche el proceso, y mantén TLS válido en los dos nombres — un fallo de certificado en el host delegado tumba la federación aunque la app parezca funcionar bien en local.
Dimensionarlo con honestidad
En funcionamiento normal, Matrix no está limitado por la CPU, sino por la memoria y por el comportamiento de la base de datos. Las cifras publicadas para Synapse son un suelo útil: alrededor de 2 GB de RAM para empezar, unos 4 GB a partir de diez a cincuenta usuarios activos, y 8 GB o más superados los cien. Los servidores de la familia Conduit se quedan muy por debajo. Lo que esas cifras no dicen es que el consumo sigue las salas a las que te unes, no las cuentas registradas — cinco usuarios en cien salas públicas grandes cuestan mucho más que cincuenta usuarios en un puñado de salas privadas.
De ahí salen dos reglas prácticas. Pon la base de datos en almacenamiento rápido y dale espacio para crecer, porque el patrón de escritura es pequeño y constante, no a ráfagas. Y no dimensiones para el número de usuarios de hoy: dimensiona para las salas a las que esos usuarios se unirán en el primer mes, que es donde suele estar la sorpresa. Nuestro plan de entrada aguanta sin problema un servidor Conduit o Dendrite pequeño, mientras que una instancia Synapse para una comunidad real pertenece a un plan de gama media o superior — la página de hosting para chat enumera los planes que recomendamos para cada uno de esos casos.
El uptime importa aquí más que en la mayoría de cargas de trabajo, porque un servidor de chat caído no está simplemente no disponible: está perdiendo eventos en silencio que los demás servidores reintentarán durante un tiempo y luego dejarán de ofrecer. La federación perdona los minutos y castiga los días.
El almacén de multimedia es una bomba de disco a cámara lenta
Cualquier imagen, vídeo o archivo que pase por una sala en la que estén tus usuarios puede acabar cacheado en tu disco, incluido contenido remoto que tus propios usuarios nunca llegaron a abrir. La retención por defecto de Synapse lo guarda indefinidamente. El resultado es previsible y aun así sigue pillando a la gente: un servidor con base de datos estable y un directorio de multimedia que crece en silencio hasta llenar el volumen, momento en el que el síntoma no es «disco lleno» sino «el servidor se comporta raro».
Define una política de retención para el contenido remoto desde el primer día, no después del primer corte. Synapse expone ajustes de retención en homeserver.yaml, además de endpoints de administración para purgar historial antiguo y archivos cacheados; synapse-compress-state recupera una cantidad sorprendente de espacio de las tablas de estado en un servidor con tiempo. Vigila tanto la base de datos como la ruta de multimedia, y pon la alerta sobre el espacio libre en vez de sobre la caída del servicio — el segundo síntoma llega días después del primero.
Hay un ajuste que merece una decisión consciente y no un valor por defecto. Las vistas previas de enlaces hacen que tu servidor vaya a buscar cualquier link publicado en una sala, lo que significa que la dirección IP de tu servidor hace una petición saliente a un tercero en cuanto alguien pega un enlace — incluido un enlace elegido a propósito para ver quién pica. Si tu homeserver está detrás de un frontal y su dirección real importa, sopésalo con cuidado; nuestra guía sobre ocultar una dirección de origen cubre este mismo tipo de fuga con más detalle.
Registro, spam y la reputación que heredas
El registro abierto en un homeserver público es una invitación, y no de las que quieres. Las altas automatizadas convierten un servidor pequeño en fuente de spam en cuestión de días, y la consecuencia no se queda en local: otros homeservers añaden tu dominio a sus listas de control de acceso, y en cuanto tu nombre está en suficientes de ellas, tus usuarios legítimos dejan de poder participar en salas ajenas. Recuperar la reputación de un dominio quemado es mucho más difícil que evitarlo, igual que pasa con la entregabilidad de correo.
Los valores por defecto defendibles son sencillos. Mantén enable_registration desactivado en un servidor privado y da tú mismo las cuentas de alta. Si quieres dejar la puerta abierta, ponle un filtro: registration_requires_token convierte el registro en un sistema de invitación sin depender de ningún servicio externo, y un captcha ayuda contra la parte más burda del problema. Para las salas que administras, los bots de moderación de la familia Mjolnir y Draupnir te permiten aplicar listas de baneo y ACL de sala en toda una comunidad de una vez, en lugar de sala por sala.
Vale la pena saber también lo contrario: nuestros rangos de direcciones no aparecen en las listas de bloqueo ACL de Matrix que circulan entre homeservers, así que un servidor nuevo arranca con la reputación limpia. Lo que pase con esa reputación después depende de cómo gestiones el registro, no de dónde esté la máquina.
Los bridges, y la factura de metadatos que traen consigo
Los bridges son la razón honesta por la que mucha gente se queda en Matrix: un solo cliente para salas que viven en otras redes. También cambian la postura de seguridad de tu servidor de una forma fácil de pasar por alto. Un bridge guarda las credenciales de la cuenta remota y, en el punto exacto donde se encuentran los dos protocolos, necesariamente maneja los mensajes en una forma que pueda convertir — lo que significa que el proceso del bridge ve en claro un tráfico que está cifrado de extremo a extremo a ambos lados de él.
Eso no es motivo para evitar los bridges. Es motivo para tratar el host del bridge como infraestructura sensible: es la máquina que, si se ve comprometida, expone las cuentas que representa. Cada bridge dobla más o menos la huella de memoria de un servidor pequeño, así que planifica capacidad en consecuencia, y dedica al lugar donde lo alojas la misma reflexión que le dedicaste al propio homeserver — el razonamiento de nuestra guía de jurisdicción se aplica con más fuerza todavía a una máquina que guarda credenciales de varias redes a la vez.
Mantenerlo vivo: claves, copias de seguridad y actualizaciones
Un servidor Matrix tiene un archivo cuya pérdida es irrecuperable de una forma que no tiene nada que ver con el volumen de datos. La clave de firma — signing.key en Synapse — es lo que le permite a tu servidor demostrar que los eventos que dicen venir de tu dominio realmente vienen de ahí. Si la pierdes, dejas de poder ser creíblemente tu propio servidor; los demás rechazarán eventos firmados por un desconocido que tiene tu nombre. Haz una copia de seguridad de esa clave por separado de todo lo demás, y guárdala fuera de la máquina.
Haz copia de la clave y de la base de datos, y entiende por qué restaurar una sin la otra es peligroso. Volver una base de datos de Matrix a una instantánea anterior deja tu servidor en un estado que los demás ya han superado, y la divergencia resultante es mucho más difícil de reparar que una reconstrucción limpia. Haz volcados consistentes con pg_dump, guárdalos fuera de la máquina, y recuerda que en esta plataforma no hay copia del proveedor a la que recurrir — no se conserva nada tras la baja, que es precisamente el sentido de todo el planteamiento, y lo cubre nuestra guía de copias de seguridad.
Las actualizaciones son rutina, pero no son opcionales. Cada versión del homeserver trae migraciones de esquema, y saltarte muchas versiones convierte una actualización de cinco minutos en toda una tarde. Lee las notas de versión antes de saltar, actualiza con la frecuencia suficiente para que cada paso sea pequeño, y aplica la higiene básica de host de la checklist de la primera hora — un servidor de chat es un servicio de larga vida expuesto a internet con una base de datos detrás, y merece el mismo trato que cualquier otro.
Dónde vive el servidor sigue decidiendo el resultado
Todo lo anterior es configuración. Lo que la configuración no puede tocar es qué sistema legal recibe una solicitud sobre tus usuarios, y para un servidor de comunicaciones esa pregunta pesa más que para una web cualquiera. Un homeserver guarda registros de pertenencia, marcas de tiempo y datos de grafo social en claro incluso cuando el cuerpo de los mensajes está cifrado — así que la jurisdicción que lo aloja es la jurisdicción que gobierna el acceso a ese registro.
Ese es el argumento práctico para elegir una ubicación a propósito y no solo por latencia. Nosotros operamos en siete, y las ventajas y desventajas entre ellas están explicadas en la guía de jurisdicción y en la página de ubicaciones. La otra mitad de la misma pregunta es quién sabe el proveedor que eres tú: una cuenta sin identidad asociada no puede entregar documentos de identidad que nunca recogió, que es la razón sencilla por la que el hosting sin KYC y las comunicaciones autoalojadas siguen apareciendo en la misma conversación. Ninguna de las dos es defensa frente a un tribunal que ya tiene tu nombre, y nuestra guía de OpSec es clara sobre dónde está esa línea.
La versión corta
Si te llevas seis cosas de esta página, que sean estas:
- Elige el
server_nameantes de instalar nada — es la única decisión que nunca podrás revisar. - Delega con
/.well-known/matrix/servero un registro SRV, y mantén TLS válido en los dos nombres. - Dimensiona pensando en las salas a las que se unirán tus usuarios, no en cuántos usuarios tienes.
- Fija la retención de multimedia desde el primer día, y decide sobre las vistas previas de enlaces en lugar de heredar el valor por defecto.
- Mantén el registro cerrado o con token; deshacer una reputación de dominio quemada sale caro.
- Haz copia de
signing.keypor separado, y nunca retrases la base de datos por detrás de tus pares.
Haz eso y el servidor será de lo más anodino, que es exactamente lo que debe ser un servidor de chat. Lo que ganas a cambio merece verse con claridad: no invisibilidad, ni un protocolo que oculte quién habla con quién, sino conversaciones cuyo contenido es tuyo, una cuenta que nadie más puede cerrar, y una máquina bajo un sistema legal que elegiste a conciencia. Pon un homeserver donde tú decidiste, y deja que la federación venga a él.