Alojar Jitsi en su propio VPS

Los servicios de videoconferencia de consumo (Zoom, Google Meet, Teams) imponen límites de duración en los planes gratuitos, cuotas de participantes, y conservan sus grabaciones en sus propios servidores. Jitsi Meet, autoalojado, elimina estas restricciones: salas sin límite, duración sin límite, ninguna cuenta requerida para unirse a una reunión, flujos de video que permanecen en su infraestructura. Es especialmente pertinente para una organización preocupada por la confidencialidad de sus reuniones, para un despacho que trata datos sensibles, o para integrar la videoconferencia en una aplicación de terceros (Jitsi ofrece una API iframe estable). El coste de funcionamiento se reduce a la factura del VPS — ninguna suscripción por puesto, ningún sobrecoste de software.

Jitsi se dimensiona por el ancho de banda, no por la CPU. Para reuniones de hasta 10 participantes: 2 vCPU, 4 GB de RAM como mínimo, tráfico saliente generoso (100 Mbps recomendados). Por encima de 20 participantes simultáneos, cuente con 8 GB de RAM y vigile la carga de red del JVB. Tres puertos deben ser accesibles desde internet: TCP 443 (HTTPS y TURN/TLS), TCP 80 (renovación de Let's Encrypt), UDP 10000 (medios JVB). Añada TCP 3478 si expone coturn en su puerto nativo. Se necesitan Docker 24+ y Compose V2, un nombre de dominio meet.sudominio.com con un registro A que apunte a la IP pública del VPS, y una IP pública dedicada y estable — una IP compartida complica seriamente la configuración de coturn.

Grabación de las reuniones. Jitsi integra Jibri para la grabación local o el streaming RTMP. Jibri requiere un segundo VPS o, como mínimo, 4 vCPU adicionales, ya que captura el renderizado del navegador en tiempo real. Active ENABLE_RECORDING=1 en .env y despliegue un contenedor Jibri separado que apunte a su Jicofo. Autenticación de los organizadores. Por defecto, cualquiera puede crear una sala. Active AUTH_TYPE=internal para exigir una cuenta del lado del organizador dejando que los invitados se unan libremente. Cree las cuentas de anfitrión con docker exec <prosody-container> prosodyctl --config /config/prosody.cfg.lua register admin meet.sudominio.com contrasena. Limitar los participantes anónimos. Añada ENABLE_LOBBY=1 para que un moderador valide cada entrada antes de acceder a la sala. Combinado con AUTH_TYPE=internal, esto da un control completo sobre quién accede a qué.

Sin sonido o video bloqueado en «connecting» — coturn + UDP 10000. Es la avería más frecuente. Compruebe en este orden: (1) ufw status — ¿están abiertos los puertos TCP 443 y UDP 10000? (2) docker compose logs coturn | grep -i error — ¿arranca coturn sin error de certificado? (3) Desde una máquina externa: curl -v telnet://meet.sudominio.com:3478 — ¿responde coturn? (4) En los logs del navegador (F12 → Consola): ¿ve ICE failed o failed to gather candidates? Si es así, coturn no es accesible desde el exterior. Compare TURN_HOST en .env con la IP real del VPS. Conexión rechazada en TCP 443. Si el certificado Let's Encrypt no pudo emitirse (puerto 80 cerrado en el primer arranque), el contenedor web intenta servir en HTTPS con un certificado autofirmado que el navegador rechaza. Solución: abra el puerto 80, elimine el volumen ~/.jitsi-meet-cfg/web y vuelva a lanzar docker compose up -d. Compartir pantalla rechazado por el navegador. Compartir la pantalla exige un contexto seguro (HTTPS válido). Si ve getUserMedia is not supported, el certificado no es válido o el dominio no está en HTTPS. Compruebe PUBLIC_URL — debe empezar por https:// con un dominio cuyo certificado sea válido, no una IP en bruto. Error «ICE failed» persistente pese a un coturn operativo. Compruebe la variable DOCKER_HOST_ADDRESS: debe contener la IP pública del VPS, no la IP interna del contenedor Docker (172.17.x.x). Si su VPS está detrás de un NAT cloud (raro pero existente), necesita la IP NAT externa, no la IP de la interfaz de red.

El puente de video JVB expone una API de estadísticas en tiempo real en http://localhost:8080/colibri/stats. Este endpoint JSON informa del número de conferencias activas, participantes, ancho de banda entrante y saliente en bits/s, y pérdida de paquetes. Para una vigilancia continua, active el soporte de Prometheus en .env (JVB_ENABLE_STATS=1, PROSODY_ENABLE_METRICS=1) y conecte una pila Prometheus + Grafana: hay un panel oficial de Jitsi disponible en Grafana Labs (ID 11925) que cubre CPU, memoria, ancho de banda y métricas de calidad de video.

Sin Prometheus, una vigilancia mínima se logra con un cron que consulta /colibri/stats y alerta cuando el rendimiento supera un umbral: docker exec jvb curl -s http://localhost:8080/colibri/stats | python3 -c "import json,sys; s=json.load(sys.stdin); print(s.get('bit_rate_download',0), s.get('bit_rate_upload',0))".

Para estimar la capacidad antes de la saturación: un JVB maneja cómodamente 200 a 250 participantes interactivos a calidad de video moderada en un VPS bien conectado. A partir de ahí, las métricas packet_loss_fraction y rtt_aggregate suben y la calidad percibida cae antes de que la CPU sature — esa es la señal para añadir otra instancia JVB.

Jitsi funciona en modo SFU: el puente de video (JVB) retransmite cada flujo hacia cada participante, por lo que el ancho de banda saliente crece proporcionalmente al número de participantes multiplicado por el número de flujos. Para 10 participantes a 720p, cuente con 20 a 40 Mbps salientes en continuo. Active lastN=5 (últimos N videos activos) para limitar los flujos del lado del cliente en las reuniones grandes, y vigile docker stats jvb para anticipar la saturación. Por encima de una veintena de participantes simultáneos regulares, despliegue varias instancias JVB en VPS distintos detrás de un único Jicofo: es la arquitectura de escalado horizontal nativa de Jitsi. Para despliegues multi-organización o multidominio, Jitsi admite múltiples entradas PUBLIC_URL mediante el mecanismo de tenant de Prosody: cada organización dispone de su propio espacio de salas aislado en la misma instalación, sin infraestructura adicional.