Cómo montar tu propio servidor Matrix (homeserver)

Instala Synapse desde la documentación de Element, publica la delegación .well-known y dimensiona la RAM por salas y multimedia. En Core desde $6/mes.

La federación mueve el buzón, no la audiencia

Lo contraintuitivo de montar tu propio homeserver de Matrix es que la federación mantiene pública, por diseño, la mayor parte de la topología. Los homeservers se replican entre sí las salas compartidas, de un modo parecido a cómo los relés SMTP pasan correo entre dominios: una sala a la que se une tu servidor también vive en los homeservers de todos los demás participantes. Autoalojarte traslada los metadatos —quién habla con quién y cuándo— a una base de datos que administras tú. Lo que no hace, por sí solo, es aislar el listado de la sala del resto de la red.

La mecánica se divide en dos canales con funciones distintas. El homeserver de referencia, Synapse, habla la API de servidor a servidor definida en la especificación de Matrix a través del puerto 8448, mientras que las apps de cliente como Element se conectan a tu dominio por el 443. Un ID de usuario como @you:example.com es una declaración de que example.com ejecuta un homeserver, y los pares remotos verifican los eventos que emites contra la clave de firma generada en la instalación. El cifrado protege el contenido de los mensajes dentro de las salas, lo cual es un asunto aparte de quién está presente en ellas.

Ahí es donde se rompen las expectativas. En una sala cifrada, los cuerpos de los mensajes siguen siendo ilegibles para terceros, pero el hecho de la pertenencia, las direcciones de las salas y los nombres de servidor implicados cruzan igualmente las federaciones en las que participa tu máquina. Un servidor doméstico para doce personas y un servidor comunitario público de diez mil salas obedecen a las mismas reglas del protocolo; la diferencia es cuánta superficie expones al unirte a salas. Decide tu postura antes de enviar la primera invitación, no después.

El fallo típico empieza aquí: tratar una sala privada como si fuera invisible y descubrir luego el listado de miembros dentro de la base de datos de un servidor remoto. Ni el método de pago, ni la ubicación, ni el nivel de hosting cambian la semántica de la federación — solo la configuración lo hace: salas restringidas, listas de permitidos de federación y una elección cuidadosa de las salas en un despliegue que quieras mantener pequeño. Si lo sensible es la audiencia, mantén el servidor fuera de las salas públicas por completo y avisa a cada miembro de que las invitaciones propagan la dirección. Resuelve esa postura primero, y el resto del montaje se convierte en una lista de tareas en lugar de un debate.

La RAM se dimensiona por salas y multimedia, no por la etiqueta de vCPU

El número de vCPU es la cifra que el marketing pone en la etiqueta; la RAM es el eje que de verdad decide si un homeserver se siente ágil. Synapse mantiene en memoria el estado de las salas, la presencia y la contabilidad multimedia para responder con rapidez, y su conjunto de trabajo crece con las salas a las que te unes, los usuarios activos y el repositorio multimedia. Una máquina con muchos núcleos y poca memoria se degrada antes de lo que sugieren sus especificaciones — normalmente primero como uniones de sala lentas y peticiones de sincronización que agotan el tiempo de espera bajo carga.

La lógica de dimensionamiento sigue la carga de trabajo. Un servidor doméstico con una docena de salas ligeras funciona sin despeinarse en un plan con 8 vCPU y 32 GB DDR5 ECC, con la base de datos y el almacén multimedia en NVMe local — unos 320 GB a ese nivel — donde los picos de escritura de las subidas y las resincronizaciones de estado se absorben en lugar de encolarse. Las salas federadas con multimedia activa, o los puentes hacia otras redes, son las cargas que superan ese suelo, porque cada imagen y cada clip de voz aterrizan en el repositorio multimedia y allí se quedan.

Postgres vive en la misma máquina a esta escala, lo cual sorprende a quienes lo gestionan como servicio administrado en el trabajo. Colocar la base de datos y el repositorio multimedia en almacenamiento local mantiene corto el camino de cada petición: una sincronización toca la memoria, después el disco local, y nunca da un salto por la red. Vigila el almacén multimedia con intención — max_upload_size, las opciones de retención y un vacuum periódico deciden si el crecimiento se mantiene aburrido o se convierte en una alarma de disco a medianoche.

El fallo habitual es comprar ancho de banda y núcleos mientras se deja el proceso hambriento de memoria, y luego culpar a la federación de las sincronizaciones lentas. El segundo fallo es poner Postgres en almacenamiento en red, donde los picos de latencia aparecen justo cuando una sala se resincroniza. Dimensiona por los dos ejes de crecimiento — salas unidas y multimedia almacenado — y deja fuera de la decisión la etiqueta de CPU. Ante la duda, sobredimensiona la RAM un escalón; a los homeservers les perdona mucho más la memoria sobrante que los núcleos sobrantes.

Instala Synapse por el camino documentado

La instalación tiene una única ruta canónica, y desviarse de ella es como nacen los hilos de soporte. La guía de instalación de Synapse recorre el montaje por paquete o virtualenv, la ejecución con --generate-config que crea homeserver.yaml y la clave de firma, y el registro del server_name que elijas. Síguela tal cual la primera vez; el archivo de configuración es donde vivirá cada decisión posterior, y quieres que nazca correcto y no parcheado hasta funcionar.

Dos valores merecen atención sin prisas. El server_name se convierte en la parte de dominio de todos los ID de usuario de la máquina y es efectivamente permanente, y el public_baseurl es lo que los clientes copian en los enlaces y los endpoints de federación. Renombrar el servidor más adelante deja huérfanas todas las cuentas y referencias de salas que mencionen el dominio antiguo — el protocolo no tiene operación de renombrado. Elige el dominio como si fueras a conservarlo una década, porque operativamente será así.

Crea los primeros usuarios con register_new_matrix_user y conecta un cliente como Element a través de tu propio dominio para confirmar que la API de cliente responde. En una máquina de pruebas, el ciclo completo — pedido, imagen, instalación, primer inicio de sesión — cabe en una tarde. Levanta la instancia en Core a $6/mes de lista — $4,80 en el plazo anual — y deja la migración de datos de producción para después de haberla ensayado una vez.

Dónde se tuerce la instalación: mezclar fuentes de paquetes — el Synapse más antiguo de una distribución con un esquema de configuración más nuevo — y leer los tracebacks resultantes como si fueran problemas de disco o de red. Fija un único canal de instalación, anota su versión en tu archivo de notas y actualiza siempre por ese mismo canal. El centro de documentación del proyecto mantiene al día las rutas de configuración de clientes, mientras que la documentación del servidor sigue siendo la referencia para las claves de configuración. Aburrido y reproducible gana al ingenioso y frágil, sobre todo en algo de lo que tu familia depende a diario.

La delegación es fontanería DNS antes que cómputo

La federación falla en la capa de resolución de nombres mucho más a menudo que en la de cómputo, algo que parece al revés hasta que rastreas una unión a una sala. El nombre de servidor de tus ID de usuario tiene que resolverse, los archivos /.well-known/matrix/client y /.well-known/matrix/server tienen que apuntar la delegación a los sitios correctos, y el 8448 tiene que responder TLS con un certificado que el dominio posea de verdad. Acierta con esos tres hechos y los homeservers remotos te encuentran; falla uno y rechazan el handshake en silencio, sin dejar nada útil en tus registros.

La delegación existe para que el dominio de cara al usuario y el nombre de servidor puedan ser distintos. El documento en /.well-known/matrix/server lleva un campo m.server que nombra el endpoint real de federación, que puede vivir en otro hostname o incluso en otra máquina, mientras que la delegación de cliente vía /.well-known/matrix/client apunta las apps a la API de cliente. Sirve ambos como JSON plano por el 443 con el content type correcto, y mantén unas vidas de caché modestas mientras sigas moviendo endpoints.

Prueba la delegación desde fuera de tu propia red, porque los resolutores locales te halagan con sus cachés. Descarga ambas rutas well-known con curl, inspecciona la cadena de certificados con openssl s_client, y solo entonces esperes que las uniones remotas funcionen. Una CDN delante de los endpoints es aceptable siempre que deje pasar el JSON sin tocarlo y se aleje del puerto de federación, donde sus hábitos de certificados y buffering suelen hacer más daño que bien.

El fallo clásico es publicar delegación para un nombre de servidor que nunca aprovisionaste, o dejar que un servidor web genérico responda en el 8448 con el certificado equivocado. Los homeservers remotos no te mandan correos por nada de esto; simplemente dejan de llamar a tu puerta. La federación es trabajo de corrección, y premia una configuración DNS aburrida y documentada antes que una ingeniosa. Escribe el bloque de delegación una vez y reutilízalo al pie de la letra en el próximo servidor que montes.

Postgres y el almacén multimedia deciden las actualizaciones

SQLite llega como base de datos por defecto porque hace que la primera ejecución sea fluida, y es lo último amable que alguien dirá de ella bajo carga real. En cuanto el servidor guarda salas de verdad con multimedia de verdad, pásate a PostgreSQL — su documentación cubre la instalación, y la de Synapse cubre el esquema. La herramienta de migración synapse_port_db traslada una instancia SQLite existente, idealmente en una franja tranquila y con el proceso detenido.

El repositorio multimedia es el segundo crecedor silencioso. Cada avatar, imagen y archivo compartido en las salas a las que te unes aterriza en tu disco, y los valores por defecto son generosos a propósito: max_upload_size limita los archivos individuales, mientras que las opciones de media_retention deciden cuánto tiempo sobrevive el multimedia remoto antes de la limpieza. Configura ambos con intención desde el primer día y revisa el crecimiento cada mes — un homeserver que parece diminuto puede albergar 50 GB de diapositivas de conferencias ajenas en un solo trimestre.

Dos diales del lado de la base de datos merecen un vistazo cada trimestre. Los valores por defecto de autovacuum asumen una carga web, no una donde una sola sala concurrida puede remoler miles de filas entre latidos, así que ajusta los límites de coste hasta que la gráfica de hinchazón se mantenga plana. El número de conexiones se comporta igual: cada hilo worker abre su propia sesión de base de datos, y una instancia viva multiplica esas sesiones más rápido de lo que los recién llegados esperan — vigílalas en pg_stat_activity, y pon un pooler delante cuando el número deje de contarse de un vistazo.

Las copias de seguridad siguen sin ser glamurosas y siguen siendo decisivas: un pg_dump nocturno más copias de la clave de firma y de la configuración devuelve a la vida una máquina muerta en menos de una hora, y el propio capítulo de copias de seguridad de PostgreSQL es la referencia para ese baile de volcado y restauración. Cuando el conjunto de trabajo supere una porción compartida, alquila Forge a $49/mes de lista — $39,20 en el plazo anual — y dale a la base de datos y al almacén multimedia su propia pareja de discos NVMe locales.

El error frecuente es acumular años de actualizaciones sin leer las notas sobre la base de datos y descubrir que un salto de versión mayor incluye una migración de esquema que corre durante horas sobre tu volumen de datos. Programa las actualizaciones, haz una instantánea antes de cada una y deja que las notas de la versión guíen la secuencia en lugar de las prisas. Una ventana de mantenimiento ensayada un domingo por la mañana vence a un apagón emocionante un martes por la noche, siempre.

Elige la bandera por la ley, y luego por la latencia

Un único precio de lista cubre las 12 ubicaciones de datacenter, lo que convierte la jurisdicción de una pregunta de presupuesto en una pregunta de criterio. Los recargos publicados son las excepciones: Islandia y Noruega al +20%, Suiza al +35%, Luxemburgo al +15%. Todo lo demás — Ámsterdam, Fráncfort, Tokio, Singapur, Hong Kong, Taipéi, Estocolmo, Helsinki — se factura al precio base de lista, así que la bandera que elijas no cuesta nada o cuesta el recargo, nunca un esquema de precios distinto.

Las diferencias legales son reales pero estrechas, y cada carga de trabajo las pondera de forma distinta. Reikiavik combina un rack fuera de la UE sin retención obligatoria de datos; Zúrich opera bajo el proceso suizo FADP, fuera del alcance directo de la UE; Ámsterdam y Fráncfort quedan bajo el RGPD con los mejores tiempos de ida y vuelta del continente; los cuatro emplazamientos de APAC responden ante sus propios ordenamientos. La guía que elige primero la jurisdicción ordena esa decisión, la guía de VPS offshore mapea las contrapartidas, y la explicación de los 14 Eyes cubre el shorthand de intercambio de inteligencia si forma parte de tu modelo de amenazas.

Mudarse después sale más barato que equivocarse para siempre, pero no es gratis: el nombre de servidor va soldado al DNS, así que un cambio de bandera suele significar un montaje nuevo y una migración de cuentas consciente de la federación. Planifica el primer despliegue como si el rack fuera definitivo, y trata cualquier reubicación posterior como una reconstrucción con copias de seguridad, no como un lift-and-shift. Las salas con años de historial son la parte dolorosa — una década de conversaciones no comprime bien, y re-descargar el multimedia desde decenas de servidores remotos puede llevar días.

La latencia sigue decidiendo la experiencia de usuario: un hogar en el centro de Europa nota Ámsterdam o Fráncfort mucho antes de enterarse de qué código rige el rack. La federación multiplica el efecto, porque tu servidor habla continuamente con decenas de homeservers remotos — un sitio con buen peering como Ámsterdam en el AMS-IX o Reikiavik en el FICIX mantiene esas conversaciones cortas y el retardo de sincronización invisible.

Dónde se rompe la elección: escoger la ley para la carga de trabajo y la latencia para nadie — una máquina en Zúrich sirviendo un listado de salas con predominio de la UE compra distancia procesal al precio de idas y vueltas que nadie pidió. La tabla de ubicaciones lista nivel, uplink y ley aplicable por emplazamiento, y leerla una vez reduce la elección a dos candidatas. Deja esas dos en la lista corta, mide ambas y deja que las cifras cierren el argumento en lugar del folclore.

Puertos: 8448 para federación, 443 para clientes

La federación necesita exactamente un puerto de entrada más que un servidor web normal: 8448/tcp para el tráfico de servidor a servidor, junto al 443/tcp para clientes. Ambos están abiertos por defecto en todos los planes, así que el trabajo del firewall consiste sobre todo en no romperlos después. El ancho de banda no tiene medición en todo el catálogo, así que el techo práctico es la velocidad del puerto — 1 Gbps en la línea VPS de entrada — y no ninguna cuota que el tráfico federado pudiera agotar.

Verifica desde fuera hacia dentro. Una comprobación remota de openssl s_client -connect matrix.example.com:8448 debe completar un handshake TLS mostrando el certificado de tu dominio, y un inicio de sesión de cliente por el 443 debe comportarse como cualquier otro servicio HTTPS. Un firewall que permite el 443 pero descarta el 8448 produce el clásico servidor medio vivo: el cliente web funciona perfecto mientras las uniones remotas se quedan misteriosamente colgadas.

Dale a esa vista exterior un hogar permanente en tu monitorización. Una pequeña tarea programada desde otra red que intente una conexión TLS al puerto de federación cada cinco minutos te dice lo que experimentan los desconocidos, que es la única perspectiva que importa aquí. Combínala con avisos de caducidad de certificado que salten a los 30 días de la expiración, porque un certificado caducado vacía en silencio tus salas de participantes remotos mientras el cliente local sigue funcionando, y nada dentro del datacenter se queja jamás de ello.

Cuando añadas un firewall — ufw allow 8448/tcp es la expresión habitual en Debian — recuerda que las reglas con estado sobreviven a los reinicios aunque tu memoria de ellas no siempre, así que documenta los dos puertos abiertos junto a las notas de delegación. IPv4 y un /64 de IPv6 vienen de serie en cada VPS, lo que significa que la federación puede correr en pila doble desde el primer día sin comprar direcciones extra ni renumerar nada después.

El incidente recurrente es un sprint de endurecimiento que cierra el 8448 de pasada; la federación se degrada en silencio porque nada dentro de la máquina nota que lo exterior dejó de llegar. Genera alertas cuando se detenga la actividad federada saliente, no solo con tus comprobaciones HTTP propias, y el error se queda en un arreglo de cinco minutos en lugar de una semana de informes confusos sobre salas. Dos puertos, ambos documentados, ambos vigilados — esa es toda la superficie.

Dendrite y Conduit ejecutan la misma lógica con menos peso

Synapse es la implementación de referencia, no la única. Dendrite, un homeserver de segunda generación del ecosistema Matrix, y Conduit, un servidor ligero escrito en Rust, corren en el mismo VPS con huellas menores — los binarios se instalan como dendrite y conduit y responden al mismo protocolo. La lógica de dimensionamiento de las secciones anteriores sobrevive intacta a la migración: RAM por salas y multimedia, Postgres en NVMe local, 8448 accesible, delegación correcta.

Los recursos difieren lo suficiente como para importar en planes pequeños: las versiones ligeras se mantienen estables cerca de unos pocos cientos de megabytes donde el proceso de referencia prefiere varios gigabytes de margen, y su reinicio tras un fallo tarda segundos en lugar de los minutos que necesita para calentar una base de datos grande. En una máquina de usos mixtos — un túnel aquí, una raíz web allí — esa diferencia decide qué proyectos llegan a alojarse. Prueba con tu lista real de salas, eso sí; los benchmarks sintéticos halagan a todas las implementaciones, y solo el tráfico real de tu comunidad dice la verdad.

Lo que cambia es la superficie de funcionalidades y el historial operativo. El largo historial de despliegues de Synapse significa que la mayoría de las guías de puentes, herramientas de administración y flujos de moderación lo asumen, mientras que los servidores ligeros cambian parte de ese peso de ecosistema por un uso de recursos más magro — lo cual importa en una máquina que además aloja otras cosas. Para un servidor doméstico, probar primero la opción ligera es razonable; para un servidor comunitario cargado de puentes, la madurez de la implementación de referencia suele ganar el argumento por sí sola.

Migrar entre homeservers no es un renombrado: los ID de usuario llevan el nombre de servidor, así que el dominio dentro de @you:example.com sobrevive a un cambio solo si la nueva implementación responde por el mismo nombre. Planifica el cambio como un cutover — detén el servidor antiguo, mueve los datos, repunta la delegación — y conserva copias de seguridad restaurables de ambos lados hasta que el nuevo haya funcionado una semana completa sin sorpresas.

La trampa es elegir un servidor ligero por el ahorro de recursos y descubrir que algún puente o herramienta de moderación imprescindible no lo soporta. Haz inventario de las funciones que usas de verdad antes de decidir, porque la RAM que ahorras no vale nada frente a un flujo de trabajo que deja de funcionar. Sea cual sea el servidor que corras, los deberes a nivel de protocolo — nombres, puertos, claves — se mantienen idénticos, así que nada de las secciones anteriores es esfuerzo perdido.

El homeserver de Matrix, en el orden en que hay que montarlo

Ejecuta el montaje en este orden y cada paso validará el anterior. Primero fija la postura: modelo de audiencia, federado o cerrado, salas públicas o solo privadas. Segundo, elige la bandera — la ley para la carga de trabajo, la latencia para los usuarios — y el tamaño, RAM por salas y multimedia en lugar de por cualquier etiqueta. Tercero, pide la máquina y configura las claves SSH antes de que nada más toque la red.

Cuarto, DNS: el nombre de servidor, los dos documentos /.well-known/matrix/, los destinos de delegación y luego los certificados para el 8448 y el puerto de cliente. Quinto, instala Synapse por el camino documentado, genera la clave de firma, fija server_name y public_baseurl exactamente una vez, y registra al primer usuario con register_new_matrix_user. Sexto, pasa la base de datos a PostgreSQL y programa el pg_dump nocturno antes de que el almacén multimedia tenga algo que perder.

Séptimo, abre y verifica los puertos — 8448/tcp y 443/tcp — desde fuera de tu propia red, no desde el sofá. Octavo, prueba una unión federada real con una cuenta remota y observa el handshake completarse de punta a punta; solo entonces empieza a invitar gente. El aprovisionamiento en la plataforma tarda alrededor de un minuto tras acreditar la factura, así que el ciclo de DNS e instalación puede empezar la misma hora en que pides.

Noveno, publica las normas de la casa donde los usuarios de verdad las lean: quién puede crear salas, cuál es la política multimedia, cómo consigue una invitación quien llega nuevo. Las comunidades derivan hacia sus valores por defecto, y los valores por defecto que no están escritos los decide quien grite primero. Una hora dedicada a esa página en la primera semana tranquila evita los argumentos que de otro modo llegan en el mes seis, cuando las costumbres ya se han endurecido y cambiarlas cuesta una buena voluntad que no puedes acuñar de nuevo.

Décimo, escribe el ritmo de mantenimiento: revisiones mensuales del almacén multimedia, actualizaciones trimestrales después de leer las notas de la versión, una restauración ensayada al año. Un homeserver es equipamiento de grado infraestructura-de-correo para tu familia u organización, y tratado así funciona durante años sin nada más dramático que un diff de configuración. Guarda juntas las notas de delegación y la copia de la clave de firma, porque entre ambas son la identidad del servidor.