[Inicio](https://servhidden.com/es) / [Guías de Alojamiento Privado](https://servhidden.com/es/guides) / Autoalojar un servidor Matrix: federación, metadatos y qué no cifra el E2EE Operaciones # Autoalojar un servidor Matrix Un homeserver no es una caja privada que hace chat: es un nodo de replicación en una red pública. Qué arregla de verdad autoalojar Matrix, qué deja a la vista el cifrado de extremo a extremo, qué implementación instalar, y qué decisiones operativas no tienen vuelta atrás. [Leer la guía](#guide-body) [Preguntas frecuentes](#guide-faq) ## En esta página - [Guía](#guide-body) - [Preguntas frecuentes](#guide-faq) - [Guías relacionadas](#guide-related) - [Páginas recomendadas](#guide-cta) Sin KYC Solo cripto Sin registros DMCA ignorado Root completo NVMe SSD 18 min de lectura Actualizado Aug 2026 En esta página [01Qué cambia realmente tener tu propio homeserver](#qué-cambia-realmente-tener-tu-propio-homeserver) [02La federación es un protocolo de replicación disfrazado de protocolo de chat](#la-federación-es-un-protocolo-de-replicación-disfrazado-de-p) [03Qué cubre el cifrado, y qué queda a la vista](#qué-cubre-el-cifrado-y-qué-queda-a-la-vista) [04Synapse, Dendrite o Conduit: qué instalar en la práctica](#synapse-dendrite-o-conduit-qué-instalar-en-la-práctica) [05La delegación que todo el mundo configura mal](#la-delegación-que-todo-el-mundo-configura-mal) [06Dimensionarlo con honestidad](#dimensionarlo-con-honestidad) [07El almacén de multimedia es una bomba de disco a cámara lenta](#el-almacén-de-multimedia-es-una-bomba-de-disco-a-cámara-lent) [08Registro, spam y la reputación que heredas](#registro-spam-y-la-reputación-que-heredas) [09Los bridges, y la factura de metadatos que traen consigo](#los-bridges-y-la-factura-de-metadatos-que-traen-consigo) [10Mantenerlo vivo: claves, copias de seguridad y actualizaciones](#mantenerlo-vivo-claves-copias-de-seguridad-y-actualizaciones) [11Dónde vive el servidor sigue decidiendo el resultado](#dónde-vive-el-servidor-sigue-decidiendo-el-resultado) [12La versión corta](#la-versión-corta) [FAQPreguntas frecuentes](#guide-faq) [→Páginas recomendadas](#guide-cta) 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](https://servhidden.com/es/guides/how-to-host-a-tor-hidden-service) 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. Un homeserver es un participante en una red pública, no una caja privada: cada servidor con un miembro en tu sala guarda su propia copia de quién se unió, cuándo, y con qué frecuencia habla. ## 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 conduwuit está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](https://servhidden.com/es/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](https://servhidden.com/es/use-cases/matrix-xmpp-hosting) 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](https://servhidden.com/es/guides/hiding-your-origin-server-ip) 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](https://servhidden.com/es/guides/offshore-mail-server-setup). 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](https://servhidden.com/es/guides/choosing-an-offshore-jurisdiction) 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](https://servhidden.com/es/guides/vps-backup-strategy). 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](https://servhidden.com/es/guides/first-hour-vps-hardening-checklist) — 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](https://servhidden.com/es/guides/choosing-an-offshore-jurisdiction) y en la [página de ubicaciones](https://servhidden.com/es/locations). 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](https://servhidden.com/es/no-kyc-hosting) 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](https://servhidden.com/es/guides/server-opsec-staying-anonymous) 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_name antes de instalar nada — es la única decisión que nunca podrás revisar. - Delega con /.well-known/matrix/server o 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.key por 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](https://servhidden.com/es/use-cases/matrix-xmpp-hosting), y deja que la federación venga a él. Preguntas frecuentes ## Matrix autoalojado — preguntas frecuentes ### 01 ¿Autoalojar Matrix hace mis mensajes más privados? Cambia la custodia, no la criptografía. El contenido de los mensajes en salas privadas ya está cifrado de extremo a extremo antes de llegar a cualquier servidor, incluido uno comercial, así que autoalojarte no cifra nada que no estuviera ya cifrado. Lo que cambia es quién tiene los metadatos, quién puede cerrarte la cuenta, y qué sistema legal recibe una solicitud sobre ella. Son ganancias reales, pero distintas de la que la gente suele dar por hecho. ### 02 ¿Los administradores de otros homeservers pueden leer mis salas? No pueden leer el contenido de los mensajes cifrados, pero pueden ver muchísimo más. Cualquier homeserver con un usuario en tu sala recibe y guarda el estado de la sala: quién es miembro, cuándo entró o salió cada persona, nombres visibles, marcas de tiempo, reacciones, y el tamaño y momento de las transferencias de archivos. Esos datos viven en su base de datos, en sus términos, y borrarlos en tu lado no los elimina del suyo. ### 03 ¿Synapse o Conduit — cuál instalo? Conduit o conduwuit para un servidor privado pequeño, porque un único binario en Rust con base de datos embebida funciona sin problemas en un plan de entrada y necesita muy poca atención. Synapse para cualquier cosa que esperes que crezca, sobre la que corras bridges, o que moderes de forma pública, porque es la implementación de referencia y cada función y herramienta de administración se piensa primero para ella. Migrar entre implementaciones más adelante significa exportar y reconstruir, así que elige pensando en el segundo año. ### 04 ¿Cuánta RAM necesita un servidor Matrix? Para Synapse, unos 2 GB para empezar, alrededor de 4 GB con diez a cincuenta usuarios activos, y 8 GB o más pasados los cien. Los servidores de la familia Conduit se quedan muy por debajo de esas cifras. La corrección importante es que la memoria sigue el número y tamaño de las salas a las que se unen tus usuarios, no el número de cuentas que alojas — pocos usuarios en muchas salas públicas grandes cuestan más que muchos usuarios en salas privadas pequeñas. ### 05 ¿Por qué mi homeserver usa tanto disco? Dos causas, normalmente juntas. Unirte a salas federadas grandes trae a tu disco el historial y el estado de otros servidores, así que un servidor pequeño puede acabar con una base de datos grande de forma completamente honesta. Y el contenido remoto se cachea indefinidamente por defecto, así que las imágenes y archivos de salas en las que tus usuarios simplemente están presentes se acumulan para siempre. Define pronto una política de retención para el contenido remoto, purga el historial antiguo de forma periódica, y vigila el espacio libre en lugar de esperar a los síntomas. ### 06 ¿Debería dejar el registro abierto? No en un servidor que te importe. El registro abierto atrae altas automatizadas que convierten tu dominio en fuente de spam, y otros homeservers responden añadiéndolo a listas de control de acceso compartidas — momento en el que tus usuarios legítimos quedan bloqueados en salas ajenas. Mantén el registro desactivado y da tú mismo las cuentas de alta, o protégelo con tokens de registro para que la puerta solo se abra a quien tú hayas invitado. ### 07 ¿Correr un bridge rompe el cifrado de extremo a extremo? Desplaza la frontera. Un bridge tiene que convertir entre dos protocolos, así que en ese punto necesariamente maneja los mensajes en forma legible, y guarda las credenciales de la cuenta remota. El tráfico sigue cifrado en el lado de Matrix y en la otra red, pero el propio bridge es un lugar donde ambos se pueden leer. Trata la máquina que lo ejecuta como infraestructura sensible, y ten en cuenta que cada bridge dobla más o menos la huella de memoria de un servidor pequeño. ### 08 ¿Puedo cambiar mi server_name más adelante? No, y merece la pena leer esto dos veces antes de instalar nada. El server_name queda grabado en cada ID de usuario, ID de sala y evento firmado que produce tu servidor, así que cambiarlo significa abandonar las cuentas y salas, no renombrarlas. Elige el dominio desnudo que realmente quieres, y después usa delegación .well-known o un registro SRV para apuntarlo al host que sea donde corra el software. Guías relacionadas ## Seguir leyendo [### Cómo Elegir una Jurisdicción de Alojamiento Offshore en 2026 Compra Un marco práctico de decisión para elegir una jurisdicción offshore: legislación de retención de datos, exposición al MLAT, postura ante DMCA, velocidad judicial y aplicación real — país por país. FAQ de 6 preguntas](https://servhidden.com/es/guides/choosing-an-offshore-jurisdiction) [### VPS vs Servidor Dedicado para Cargas de Trabajo Críticas de Privacidad Compra Cuándo un VPS es suficiente, cuándo la tenencia compartida es un riesgo y cuándo el bare metal es la única respuesta honesta. Aislamiento de hardware, riesgo de hipervisor y coste frente a modelo de amenazas. FAQ de 6 preguntas](https://servhidden.com/es/guides/vps-vs-dedicated-for-privacy) [### VPN Autogestionada en un VPS Sin KYC: WireGuard vs OpenVPN Operaciones Por qué una VPN autogestionada supera a los proveedores comerciales, y cómo WireGuard y OpenVPN se comparan realmente en privacidad, rendimiento y riesgo operativo en 2026. FAQ de 6 preguntas](https://servhidden.com/es/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 para inferencia IA (y dónde encaja la RTX 5090) Compra Guía de decisión de compra: qué GPU NVIDIA elegir para LLM, imagen, video, voz y cargas de trabajo de fine-tuning autoalojadas en 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, rendimiento, $/token, cuándo gana cada una. FAQ de 6 preguntas](https://servhidden.com/es/guides/rtx-4090-vs-h100-for-ai-inference) [### RDP Windows Offshore para Trading Forex con MT4 / MT5 / cTrader Operaciones Guía completa: por qué usar un RDP Windows para trading forex, cómo elegir una jurisdicción offshore de baja latencia, configuración de MT4 / MT5 / cTrader / Expert Advisor, latencia a servidores de broker, y el proceso de checkout sin KYC. FAQ de 6 preguntas](https://servhidden.com/es/guides/offshore-windows-rdp-for-forex-trading) [### Alojamiento Ignorado por DMCA: Lo Que Realmente Significa en 2026 Compra Qué ofrece realmente el alojamiento «ignorado por DMCA», qué jurisdicciones lo respaldan de verdad, para qué cargas de trabajo es necesario, y las trampas sobre derechos de autor que el término no cubre. FAQ de 6 preguntas](https://servhidden.com/es/guides/dmca-ignored-hosting-explained) [### Registro Anónimo de Dominios con Cripto: Privacidad WHOIS en 2026 Privacidad Una guía práctica de 2026 para registrar dominios sin revelar tu identidad: regímenes WHOIS por TLD, elección de registrador, opciones de pago en cripto, y los errores operativos que te delatan igualmente. FAQ de 6 preguntas](https://servhidden.com/es/guides/anonymous-domain-registration-with-crypto) [### Pagos Cripto para Alojamiento: Monero vs Bitcoin vs USDT Privacidad Cómo la elección de la moneda afecta lo que tu proveedor aprende sobre ti. Privacidad, comisiones, finalidad y exposición al análisis de cadena para XMR, BTC y USDT — con una recomendación clara. FAQ de 6 preguntas](https://servhidden.com/es/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### ¿Es realmente anónimo el hosting offshore? Una respuesta honesta Privacidad El hosting offshore sin KYC elimina la identidad que un proveedor normal recopila, pero «anónimo» depende del pago, del registro de logs del proveedor y de tu propia opsec. Esto es lo que realmente se puede rastrear. FAQ de 6 preguntas](https://servhidden.com/es/guides/is-offshore-hosting-truly-anonymous) [### La primera hora de hardening de un VPS: una checklist Operaciones Una checklist concreta y ordenada para asegurar un VPS nuevo en menos de una hora: claves SSH, un firewall, fail2ban, actualizaciones automáticas y la reducción de superficie de ataque que detiene la mayoría de los ataques oportunistas. FAQ de 6 preguntas](https://servhidden.com/es/guides/first-hour-vps-hardening-checklist) [### ¿Qué es el Hosting sin KYC? Definición, Legalidad y Cómo Funciona Privacidad El hosting sin KYC te permite alquilar un servidor sin ninguna verificación de identidad: sin nombre, sin correo electrónico, sin identificación. Aquí encontrarás exactamente qué significa, cómo funciona técnicamente, si es legal y cómo elegir un proveedor genuino. FAQ de 6 preguntas](https://servhidden.com/es/guides/what-is-no-kyc-hosting) [### ¿Es Legal el Hosting Offshore? La Respuesta Honesta para 2026 Compra El hosting offshore es legal, tanto para ti como para el proveedor. Aquí explicamos qué significa realmente el término, dónde está la línea legal, los mitos que vale la pena descartar y cómo utilizarlo de forma responsable. FAQ de 6 preguntas](https://servhidden.com/es/guides/is-offshore-hosting-legal) [### Cómo pagar el alojamiento con Monero (XMR) — Guía paso a paso Privacidad Guía paso a paso para pagar un VPS o servidor dedicado con Monero (XMR): por qué XMR es la opción más privada, cómo adquirirlo y cómo funciona el proceso de pago — desde la factura hasta un servidor en funcionamiento en minutos. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-pay-for-hosting-with-monero) [### Cómo alojar un sitio web de forma anónima — Guía práctica 2026 Privacidad Una guía práctica y por capas para alojar un sitio web sin revelar tu identidad: la cuenta, el pago, el dominio, la jurisdicción, la conexión y el contenido — cada capa explicada en detalle. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-host-a-website-anonymously) [### Cómo configurar una VPN WireGuard en un VPS — Guía paso a paso Operaciones Crea tu propia VPN privada en un VPS con WireGuard: por qué una VPN autoalojada supera a una comercial, la configuración completa desde la instalación hasta el primer cliente conectado, y cómo reforzar la seguridad. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### Cómo alojar tu propio LLM en un servidor GPU — Guía 2026 Operaciones Ejecuta tu propio modelo de lenguaje en un servidor GPU alquilado: por qué el autoalojamiento supera a una API, qué GPU y modelo elegir, la configuración con Ollama o vLLM, y cuánto cuesta. FAQ de 6 preguntas](https://servhidden.com/es/guides/self-host-an-llm-on-a-gpu-server) [### Hosting Bulletproof vs Hosting Offshore — ¿Cuál es la diferencia? Compra El hosting bulletproof y el hosting offshore se confunden constantemente, pero no son lo mismo. Aquí encontrarás la diferencia real, por qué importa y cuál es el que verdaderamente necesitas. FAQ de 6 preguntas](https://servhidden.com/es/guides/bulletproof-vs-offshore-hosting) [### Cómo comprar un VPS con Bitcoin — paso a paso (2026) Compra Una guía accesible para comprar un VPS con Bitcoin: cómo obtener BTC, elegir un plan, pagar la factura y lo que obtienes a cambio — un servidor en funcionamiento sin tarjeta y sin nombre vinculado. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-buy-a-vps-with-bitcoin) [### Los mejores países para hosting ignorado por DMCA en 2026 Compra Dónde alojar cuando necesitas servidores fuera del alcance de las órdenes de retirada al estilo estadounidense: las jurisdicciones que funcionan, qué significa realmente «ignorado por DMCA» y cómo elegir. FAQ de 6 preguntas](https://servhidden.com/es/guides/best-countries-for-dmca-ignored-hosting) [### Cómo alojar un servicio oculto de Tor (sitio .onion) — Guía 2026 Operaciones Configura un servicio onion de Tor en un VPS: qué es un servicio oculto, por qué es la forma más sólida de alojamiento anónimo, el proceso completo de configuración y cómo mantener el anonimato real. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-host-a-tor-hidden-service) [### Configuración de un servidor de correo offshore — Aloja tu propio email privado en 2026 Operaciones Ejecuta tu propio servidor de correo privado en un VPS offshore: por qué alojar el email tú mismo, qué necesitas, la configuración práctica con una solución todo-en-uno y cómo garantizar la entregabilidad. FAQ de 6 preguntas](https://servhidden.com/es/guides/offshore-mail-server-setup) [### Guía de alojamiento de nodos cripto — Ejecuta un nodo blockchain en un VPS Operaciones Cómo alojar un nodo blockchain en un servidor: por qué ejecutar tu propio nodo, cómo dimensionar el servidor para Bitcoin, Ethereum, Monero y otras redes, la configuración inicial y cómo mantenerlo privado. FAQ de 6 preguntas](https://servhidden.com/es/guides/crypto-node-hosting-guide) [### Hosting GPU para Stable Diffusion — Monta tu propio servidor de imágenes Operaciones Ejecuta Stable Diffusion en tu propio servidor GPU: por qué autoalojar la generación de imágenes, qué GPU elegir, la configuración con una interfaz web y qué cuesta frente a un servicio alojado. FAQ de 6 preguntas](https://servhidden.com/es/guides/gpu-hosting-for-stable-diffusion) [### OpSec para servidores — Mantener el anonimato cuando gestionas un servidor Privacidad Seguridad operacional para quien gestiona un servidor anónimo: los errores que desvelan identidades, los hábitos que los previenen y cómo mantener las identidades verdaderamente separadas. FAQ de 6 preguntas](https://servhidden.com/es/guides/server-opsec-staying-anonymous) [### Guía de configuración de seedbox — Crea tu propio seedbox privado en 2026 Operaciones Cómo construir tu propio seedbox en un servidor: qué es un seedbox, cómo dimensionarlo, instalar un cliente torrent con interfaz web y mantenerlo privado y seguro. FAQ de 6 preguntas](https://servhidden.com/es/guides/seedbox-setup-guide) [### Cómo eludir la censura DPI con tu propio VPS (guía 2026) Privacidad ¿Tu VPN dejó de funcionar? Cómo eludir la censura DPI con tu propio VPS: qué detecta realmente la inspección profunda de paquetes, cuál de los cinco protocolos de 2026 vence a cada tipo de bloqueo, y una guía completa de VLESS+REALITY paso a paso. FAQ de 6 preguntas](https://servhidden.com/es/guides/bypass-dpi-censorship-with-your-own-vps) [### Cifrado de disco completo en un VPS: configurar LUKS y qué protege Operaciones Cómo cifrar un VPS con LUKS: volúmenes cifrados, cifrado de raíz completa con desbloqueo remoto por SSH, los ajustes que importan en un servidor pequeño, y qué detiene realmente el cifrado de disco. FAQ de 8 preguntas](https://servhidden.com/es/guides/full-disk-encryption-on-a-vps) [### Ocultar la IP de origen: CDN, proxy inverso y qué se filtra Privacidad Si conviene poner un CDN delante de un servidor offshore: qué oculta, el servicio de abuso que heredas, las seis formas en que la IP de origen se filtra igualmente, y cómo auditar la tuya. FAQ de 8 preguntas](https://servhidden.com/es/guides/hiding-your-origin-server-ip) [### Backup de VPS: cifrado, fuera del sitio y que realmente restaura Operaciones Tu proveedor no guarda copias. Qué destruye realmente un servidor, por qué el backup por push muere con él, restic vs Borg, y cómo probar que restaura de verdad. FAQ de 8 preguntas](https://servhidden.com/es/guides/vps-backup-strategy) [### Cómo migrar un sitio web a alojamiento offshore sin inactividad Operaciones El orden que convierte una migración de servidor en algo aburrido: baja el TTL de DNS con días de antelación, mantén los dos servidores en paralelo, congela las escrituras solo minutos, no horas, y limpia el rastro de DNS pasivo, Certificate Transparency y WHOIS que deja el traslado. FAQ de 8 preguntas](https://servhidden.com/es/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operaciones Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. FAQ de 8 preguntas](https://servhidden.com/es/guides/self-host-a-crypto-payment-gateway) ## Monta tu homeserver donde tú decidas Siete jurisdicciones, root completo, ISO personalizada y ancho de banda ilimitado en todos los planes — desde $7.50/mes para un servidor pequeño de Conduit o Dendrite. Sin KYC, sin email, solo cripto. [Ver planes VPS](https://servhidden.com/es/vps) [Todas las ubicaciones](https://servhidden.com/es/locations) [Hosting offshore](https://servhidden.com/es/anonymous-hosting) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "VPS y servidores dedicados offshore en 7 jurisdicciones privacy-friendly. Sin KYC, sin registros, solo criptomonedas. Privacidad por arquitectura.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Autoalojar un servidor Matrix: federación, metadatos y qué no cifra el E2EE", "description": "Qué cambia autoalojar tu propio servidor Matrix: Synapse frente a Conduit, el server_name que no puedes cambiar y lo que la federación sigue revelando.", "image": "https://servhidden.com/assets/img/guides/self-host-a-matrix-server.webp?v=1787253905", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-20T00:00:00+00:00", "dateModified": "2026-08-21T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/self-host-a-matrix-server", "inLanguage": "es", "keywords": "autoalojar servidor Matrix, servidor de chat propio, instalar Synapse, Synapse vs Conduit, servidor Matrix privado, montar tu propio homeserver, federación Matrix privacidad, hosting Matrix sin KYC", "articleSection": "Operaciones", "wordCount": 3541 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "¿Autoalojar Matrix hace mis mensajes más privados?", "acceptedAnswer": { "@type": "Answer", "text": "Cambia la custodia, no la criptografía. El contenido de los mensajes en salas privadas ya está cifrado de extremo a extremo antes de llegar a cualquier servidor, incluido uno comercial, así que autoalojarte no cifra nada que no estuviera ya cifrado. Lo que cambia es quién tiene los metadatos, quién puede cerrarte la cuenta, y qué sistema legal recibe una solicitud sobre ella. Son ganancias reales, pero distintas de la que la gente suele dar por hecho." } }, { "@type": "Question", "name": "¿Los administradores de otros homeservers pueden leer mis salas?", "acceptedAnswer": { "@type": "Answer", "text": "No pueden leer el contenido de los mensajes cifrados, pero pueden ver muchísimo más. Cualquier homeserver con un usuario en tu sala recibe y guarda el estado de la sala: quién es miembro, cuándo entró o salió cada persona, nombres visibles, marcas de tiempo, reacciones, y el tamaño y momento de las transferencias de archivos. Esos datos viven en su base de datos, en sus términos, y borrarlos en tu lado no los elimina del suyo." } }, { "@type": "Question", "name": "¿Synapse o Conduit — cuál instalo?", "acceptedAnswer": { "@type": "Answer", "text": "Conduit o conduwuit para un servidor privado pequeño, porque un único binario en Rust con base de datos embebida funciona sin problemas en un plan de entrada y necesita muy poca atención. Synapse para cualquier cosa que esperes que crezca, sobre la que corras bridges, o que moderes de forma pública, porque es la implementación de referencia y cada función y herramienta de administración se piensa primero para ella. Migrar entre implementaciones más adelante significa exportar y reconstruir, así que elige pensando en el segundo año." } }, { "@type": "Question", "name": "¿Cuánta RAM necesita un servidor Matrix?", "acceptedAnswer": { "@type": "Answer", "text": "Para Synapse, unos 2 GB para empezar, alrededor de 4 GB con diez a cincuenta usuarios activos, y 8 GB o más pasados los cien. Los servidores de la familia Conduit se quedan muy por debajo de esas cifras. La corrección importante es que la memoria sigue el número y tamaño de las salas a las que se unen tus usuarios, no el número de cuentas que alojas — pocos usuarios en muchas salas públicas grandes cuestan más que muchos usuarios en salas privadas pequeñas." } }, { "@type": "Question", "name": "¿Por qué mi homeserver usa tanto disco?", "acceptedAnswer": { "@type": "Answer", "text": "Dos causas, normalmente juntas. Unirte a salas federadas grandes trae a tu disco el historial y el estado de otros servidores, así que un servidor pequeño puede acabar con una base de datos grande de forma completamente honesta. Y el contenido remoto se cachea indefinidamente por defecto, así que las imágenes y archivos de salas en las que tus usuarios simplemente están presentes se acumulan para siempre. Define pronto una política de retención para el contenido remoto, purga el historial antiguo de forma periódica, y vigila el espacio libre en lugar de esperar a los síntomas." } }, { "@type": "Question", "name": "¿Debería dejar el registro abierto?", "acceptedAnswer": { "@type": "Answer", "text": "No en un servidor que te importe. El registro abierto atrae altas automatizadas que convierten tu dominio en fuente de spam, y otros homeservers responden añadiéndolo a listas de control de acceso compartidas — momento en el que tus usuarios legítimos quedan bloqueados en salas ajenas. Mantén el registro desactivado y da tú mismo las cuentas de alta, o protégelo con tokens de registro para que la puerta solo se abra a quien tú hayas invitado." } }, { "@type": "Question", "name": "¿Correr un bridge rompe el cifrado de extremo a extremo?", "acceptedAnswer": { "@type": "Answer", "text": "Desplaza la frontera. Un bridge tiene que convertir entre dos protocolos, así que en ese punto necesariamente maneja los mensajes en forma legible, y guarda las credenciales de la cuenta remota. El tráfico sigue cifrado en el lado de Matrix y en la otra red, pero el propio bridge es un lugar donde ambos se pueden leer. Trata la máquina que lo ejecuta como infraestructura sensible, y ten en cuenta que cada bridge dobla más o menos la huella de memoria de un servidor pequeño." } }, { "@type": "Question", "name": "¿Puedo cambiar mi server_name más adelante?", "acceptedAnswer": { "@type": "Answer", "text": "No, y merece la pena leer esto dos veces antes de instalar nada. El server_name queda grabado en cada ID de usuario, ID de sala y evento firmado que produce tu servidor, así que cambiarlo significa abandonar las cuentas y salas, no renombrarlas. Elige el dominio desnudo que realmente quieres, y después usa delegación .well-known o un registro SRV para apuntarlo al host que sea donde corra el software." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Inicio", "item": "https://servhidden.com/es/" }, { "@type": "ListItem", "position": 2, "name": "Guías de Alojamiento Privado", "item": "https://servhidden.com/es/guides" }, { "@type": "ListItem", "position": 3, "name": "Autoalojar un servidor Matrix: federación, metadatos y qué no cifra el E2EE", "item": "https://servhidden.com/es/guides/self-host-a-matrix-server" } ] } ```