Ejemplo ilustrativo: Imaginemos un pequeño grupo de voluntarios que desea tener su propio servidor Matrix en chat.example.com. Esta es una configuración hipotética, no un informe de un servidor probado. Los mismos pasos se pueden adaptar a un dominio real, pero elija el nombre del servidor Matrix con cuidado: Synapse lo utiliza en los identificadores de usuario y no se puede cambiar posteriormente.
Esta guía crea un servicio Synapse y una base de datos PostgreSQL con Docker Compose. La imagen oficial de Docker de Synapse comienza con SQLite por defecto, lo cual es conveniente para una prueba puntual; la documentación de Docker de Synapse recomienda PostgreSQL para producción. Por lo tanto, el ejemplo genera primero la configuración de Synapse, cambia la configuración de la base de datos a PostgreSQL y luego inicia ambos contenedores. La imagen oficial es ghcr.io/element-hq/synapse. Las instrucciones y los detalles de la imagen se verificaron con la documentación oficial vigente el 6 de octubre de 2026; las etiquetas de la imagen y las versiones de software compatibles pueden cambiar, así que revise la documentación vinculada antes de una implementación a largo plazo.
docker compose version. Siga las instrucciones de instalación oficiales de Docker para su sistema operativo.chat.example.comes el nombre del servidor Synapse, por lo que los ID de usuario locales se verán así @alex:chat.example.com: . Reemplácelo con un dominio que usted controle antes de generar la configuración.8008no es un punto final HTTPS accesible desde Internet. Este ejemplo de Compose vincula ese puerto a la interfaz de bucle invertido del host para que un proxy inverso en la misma máquina pueda acceder a él.El nombre SYNAPSE_SERVER_NAMEno es necesariamente la URL de cada conexión de cliente. Si desea identificadores más cortos, como @alex:example.comal atender a clientes desde chat.example.com, esto requiere una configuración específica de dominio y descubrimiento. Decida esto antes de crear las cuentas.
En el servidor, cree un directorio para el proyecto Compose y los archivos Synapse persistentes:
mkdir -p ~/matrix-synapse/data
cd ~/matrix-synapse
Crea un archivo local .envque Docker Compose leerá. Genera una contraseña larga y aleatoria usando un gestor de contraseñas o un generador seguro local, y colócala después de POSTGRES_PASSWORD=. Usa letras y números para este ejemplo para evitar problemas de comillas en YAML más adelante. No subas este archivo a un repositorio público y restringe sus permisos:
umask 077
nano .env
El archivo debe contener una línea, por ejemplo POSTGRES_PASSWORD=replace-with-a-long-random-value: . El texto es un marcador de posición, no una contraseña para reutilizar. Guarde la contraseña para la configuración de la base de datos Synapse en el paso 3.
Crear compose.yamlen el directorio del proyecto:
services:
postgres:
image: postgres:16
restart: unless-stopped
environment:
POSTGRES_USER: synapse
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?Set POSTGRES_PASSWORD in .env}
POSTGRES_DB: synapse
POSTGRES_INITDB_ARGS: "--encoding=UTF8 --locale=C"
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U synapse -d synapse"]
interval: 10s
timeout: 5s
retries: 5
start_period: 20s
synapse:
image: ghcr.io/element-hq/synapse:latest
restart: unless-stopped
depends_on:
postgres:
condition: service_healthy
environment:
SYNAPSE_SERVER_NAME: chat.example.com
SYNAPSE_REPORT_STATS: "no"
volumes:
- ./data:/data
ports:
- "127.0.0.1:8008:8008"
volumes:
postgres_data:
Reemplaza chat.example.comcon el nombre final del servidor que elegiste. La comprobación de estado de PostgreSQL permite que Compose espere a que la base de datos indique que está lista antes de iniciar Synapse. El volumen de base de datos con nombre y el ./datadirectorio montado en el host se conservan tras el reemplazo de contenedores; eliminar solo los contenedores no los borra. Evita hacerlo docker compose down -va menos que quieras eliminar intencionadamente el volumen de la base de datos.
El ejemplo sirve :latestpara simplificar la primera actualización. Para un servidor con mantenimiento, seleccione y registre una etiqueta de versión o resumen de imagen de Synapse específica y, a continuación, actualícela mediante un proceso de actualización planificado tras revisar las notas de la versión. No dé por sentado que la latestetiqueta mutable conservará la misma versión.
Ejecute la imagen oficial una vez en su modo de generación de configuración. Dado que Compose se monta ./dataen /data, la configuración generada y la clave de firma permanecen en el host:
docker compose run --rm synapse generate
Este comando utiliza el nombre del servidor y la opción de estadísticas anónimas del entorno Compose. Synapse también crea una clave de firma; guárdela junto con el directorio de datos e inclúyala en las copias de seguridad protegidas. No la regenere ni la deseche durante una actualización normal del contenedor.
Abra data/homeserver.yamly reemplace la database:sección generada con la siguiente configuración. Use la contraseña exacta en .envlugar del marcador de posición:
database:
name: psycopg2
args:
user: synapse
password: 'replace-with-the-same-random-value'
dbname: synapse
host: postgres
port: 5432
cp_min: 5
cp_max: 10
Mantenga la indentación YAML circundante y asegúrese de que solo haya una database:sección activa. El nombre de host postgreses el nombre del servicio Compose, que los contenedores pueden resolver en su red predeterminada compartida. La configuración utiliza el nombre del motor PostgreSQL documentado de Synapse, psycopg2y nombres de argumentos de base de datos que incluyen dbname.
En este ejemplo sencillo, la contraseña de la base de datos aparece tanto en la configuración de Synapse como en el .envarchivo protegido. Trate ambos archivos como secretos, limite el acceso del host y utilice un método específico de gestión de secretos si su entorno de implementación lo requiere. No copie la contraseña real en registros, capturas de pantalla ni solicitudes de soporte.
Iniciar la pila en segundo plano:
docker compose up -d
Compruebe el estado del servicio y lea los registros de inicio:
docker compose ps
docker compose logs --tail=100 synapse
Espere a que Synapse complete la configuración inicial de la base de datos. Un contenedor en ejecución solo significa que su proceso está activo; revise los registros en busca de errores de configuración, base de datos o permisos antes de continuar. Para ver los registros a medida que llegan, use docker compose logs -f synapsey presione Ctrl+Cpara dejar de seguirlos sin detener el contenedor.
Desde el host de Docker, solicite el punto final de versiones de la API del cliente de Synapse:
curl -fsS http://127.0.0.1:8008/_matrix/client/versions
Una respuesta exitosa es un JSON que describe las versiones de la API del cliente Matrix compatibles. Esto confirma que el receptor HTTP está respondiendo localmente; no prueba que DNS, HTTPS o la federación estén configurados correctamente.
Configure el proxy inverso del host para reenviar las solicitudes del dominio elegido http://127.0.0.1:8008y obtener un certificado TLS válido. Conserve la ruta de solicitud de Matrix al usar el proxy. Luego, verifique el punto final público:
curl -fsS https://chat.example.com/_matrix/client/versions
Sustituya el nombre de host de ejemplo por el suyo. Si los clientes necesitan descubrir el servidor principal desde un dominio de ID de usuario independiente, publique los registros de descubrimiento conocidos de Matrix correspondientes a ese diseño. La federación también requiere un enrutamiento público y un DNS correctos; abrir un puerto local 8008por sí solo no proporciona una implementación pública completa. Consulte la guía de Synapse sobre proxy inverso y federación antes de exponer el servicio.
Synapse desactiva el registro público por defecto. Para un servidor privado, mantenga esa configuración predeterminada y cree cuentas desde la línea de comandos. Añada temporalmente un registration_shared_secretvalor fuerte a data/homeserver.yaml, y luego reinicie Synapse para que lea el cambio:
docker compose restart synapse
Ejecute la herramienta de registro dentro del contenedor. Le pedirá un nombre de usuario y una contraseña; la configuración --admincrea el primer administrador:
docker compose exec synapse register_new_matrix_user \
http://localhost:8008 \
-c /data/homeserver.yaml \
--admin
Una vez creada la cuenta, elimínela registration_shared_secretde la configuración y reinicie Synapse. Dejar la clave secreta configurada permite que cualquiera que la obtenga registre cuentas estándar o de administrador a través de la interfaz de registro. Inicie sesión mediante un cliente Matrix compatible con servidores privados personalizados, utilizando la URL del servidor proporcionada por su proxy inverso.
./data, incluyendo la configuración, los medios y la clave de firma. Una copia de PostgreSQL por compose.yamlsí sola no puede restaurar el servidor principal. Almacene las copias de seguridad en un lugar separado del servidor y confirme periódicamente que puede leerlas./data: inspeccione la propiedad del host y los permisos en ./data. El usuario de tiempo de ejecución de la imagen oficial necesita permiso para leer la configuración y escribir datos. Ajuste la propiedad del host con cuidado en lugar de hacer que el directorio sea escribible por todos.host: postgres, que la contraseña coincida .envy que docker compose logs postgresmuestre una base de datos en buen estado. La condición de preparación de Compose depends_onreduce las condiciones de carrera al inicio, pero no corrige las credenciales incorrectas.docker compose pullseguido de docker compose up -d. Mantenga el mismo directorio de datos, volumen de base de datos, nombre del servidor y clave de firma.En la configuración ilustrativa del grupo de voluntarios, la instalación se completa solo cuando el punto final de las versiones locales responde, el punto final HTTPS responde a través del proxy y el administrador puede iniciar sesión con el dominio Matrix ID previsto. Estas comprobaciones son indicadores prácticos de una primera implementación exitosa; no sustituyen la revisión de la seguridad, las copias de seguridad, la federación y los requisitos operativos antes de invitar a una comunidad más amplia.
Compara 10 herramientas de escaneo de ping para la detección rápida de redes LAN, el escaneo multiplataforma y la gestión de direcciones IP. Descubre qué puede (y qué no puede) revelarte un escaneo.
Compare seis herramientas de gestión de red para la monitorización del rendimiento, incluyendo la cobertura SNMP, la asignación de mapas, las alertas, los modelos de implementación y las ventajas y desventajas en cuanto a costes.
Compara las mejores aplicaciones de análisis Wi-Fi para Windows, iPhone y Android, incluyendo herramientas para la congestión de canales, la cobertura de la señal, los mapas de calor y la resolución de problemas de red.
Compara siete monitores de ping gratuitos y de código abierto, desde suites de red completas hasta sondas de latencia específicas, y elige el que mejor se adapte a tus necesidades en cuanto a disponibilidad, pérdida de paquetes e historial.
Aprenda qué significa QoS en redes, cómo las marcas DSCP y las colas de tráfico priorizan las aplicaciones de voz, vídeo y empresariales, y qué problemas no puede solucionar la QoS.
Compare siete herramientas de administración de direcciones IP para el descubrimiento de subredes, la coordinación de DNS y DHCP, el inventario de red y la gestión de direcciones IP de código abierto.
Compara software de servidor SFTP fiable para Windows y Linux, incluyendo OpenSSH, Bitvise, SolarWinds y SFTPGo. Encuentra la solución ideal para tus necesidades de seguridad y transferencia de archivos.
Cree un sistema práctico de monitorización de red con una cobertura clara de los dispositivos, métricas de rendimiento útiles, alertas procesables y una comparación de SolarWinds NPM, PRTG y OpManager.
Compare las herramientas de escaneo de red para la detección rápida de dispositivos, escaneos de IP multiplataforma y gestión de direcciones IP (IPAM) empresariales, con orientación sobre cómo adaptar cada opción a su red.
Utilice la opción --traceroute de Nmap para asignar saltos a un host autorizado, comprender la salida de saltos y RTT, y solucionar problemas de respuestas faltantes sin realizar un escaneo excesivo.
