Cómo instalar Jitsi Meet en un VPS

Qué es Jitsi Meet y qué piezas instala

Jitsi Meet no es un solo programa: el paquete jitsi-meet instala cuatro componentes que trabajan juntos. Entender qué hace cada uno ahorra horas de diagnóstico.

• Jitsi Meet: la interfaz web que abre el participante en el navegador.
• Prosody: el servidor XMPP que gestiona las salas, la señalización y la autenticación.
• Jicofo: el conferencista, que decide quién habla con quién y asigna recursos.
• Jitsi Videobridge (JVB): el que mueve el audio y el vídeo. Es el componente que consume ancho de banda y el que limita la capacidad.

Jitsi funciona como SFU (Selective Forwarding Unit): no mezcla los vídeos en el servidor, los reenvía. Cada participante manda un flujo y recibe los de los demás. Ese detalle explica por qué el consumo crece tan rápido con el tamaño de la sala.

Cuánta gente aguanta un VPS: la cuenta real

El límite de Jitsi es el ancho de banda de salida, no el procesador. La evaluación de rendimiento publicada por el propio proyecto lo demuestra con cifras medidas en un servidor de cuatro núcleos Xeon E5-1620 v2:

Mil flujos consumían apenas una quinta parte de la CPU pero más de medio gigabit por segundo. La memoria del proceso Java nunca superó los 1.500 MB.

La fórmula para estimar tu caso es sencilla. En una sala de N participantes con vídeo activo, el servidor reenvía aproximadamente N × (N − 1) flujos:

• Sala de 4 personas: 12 flujos. A ~600 kbps cada uno, unos 7 Mbps de salida.
• Sala de 10 personas: 90 flujos, unos 54 Mbps.
• Sala de 20 personas: 380 flujos, unos 200 Mbps.

Por eso una reunión de 20 personas con todas las cámaras encendidas es un problema de red, no de CPU. Jitsi mitiga esto con last N (solo envía el vídeo de los últimos que hablaron) y con capas de calidad, pero la aritmética manda.

Punto de partida razonable: 2 vCPU y 4 GB de RAM para uso interno de un equipo pequeño; 4 vCPU y 8 GB si esperas varias salas simultáneas. Y comprueba el ancho de banda incluido en tu plan, porque el vídeo consume tráfico de verdad.

Requisitos y preparación del servidor

Necesitas Ubuntu 22.04 o superior (o Debian 11+), un dominio con registro A apuntando a la IP pública, OpenJDK 17 y los puertos correctos abiertos. Un servidor detrás de NAT complica la configuración; lo limpio es un VPS con IP pública propia.

El puerto 10000/UDP es el que más veces se olvida. Sin él la sala carga, dos personas pueden verse por conexión directa y todo se rompe al entrar la tercera: ese es el síntoma clásico.

sudo apt update && sudo apt upgrade -y
sudo hostnamectl set-hostname meet.ejemplo.com
sudo apt install -y gnupg2 curl apt-transport-https ca-certificates
dig +short meet.ejemplo.com A

Configura el firewall antes de instalar:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 22/tcp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable
sudo ufw status verbose

Si tu proveedor tiene firewall externo, replica las reglas ahí también; la guía de configurar firewalls en Linux explica por qué una sola capa no basta.

Instalar Jitsi Meet desde el repositorio oficial

El proyecto publica paquetes propios; instalar desde ahí evita versiones desactualizadas de los repositorios de la distribución. Primero el repositorio de Prosody, que Jitsi necesita en una versión reciente:

sudo curl -sL https://prosody.im/files/prosody-debian-packages.key \
  -o /usr/share/keyrings/prosody-debian-packages.key
echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" \
  | sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list
sudo apt install -y lua5.2

Después el repositorio de Jitsi:

curl -sL https://download.jitsi.org/jitsi-key.gpg.key \
  | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" \
  | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install -y jitsi-meet

El instalador pregunta dos cosas:

1. 1 Nombre de host: escribe meet.ejemplo.com, exactamente el dominio que resuelve a este VPS.
2. 2 Certificado TLS: elige generar uno nuevo autofirmado; después lo cambiaremos por Let's Encrypt.

Ese dominio queda escrito en media docena de archivos de configuración. Cambiarlo más tarde significa reinstalar en la práctica, así que decídelo antes.

Ahora el certificado real:

sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

El script pide un correo para los avisos de caducidad y configura la renovación automática. Abre https://meet.ejemplo.com y crea una sala de prueba con dos dispositivos en redes distintas.

Comprueba que los servicios están arriba:

sudo systemctl status prosody jicofo jitsi-videobridge2 nginx --no-pager
sudo ss -lunp | grep 10000

Cerrar el servidor: autenticación de salas

Recién instalado, cualquiera que conozca tu dominio puede crear una sala con el nombre que quiera y consumir tu ancho de banda. Es el comportamiento por defecto y hay que cambiarlo en cualquier despliegue empresarial.

La solución oficial es el "dominio seguro": crear una sala exige autenticación, unirse a una sala existente no. Edita /etc/prosody/conf.avail/meet.ejemplo.com.cfg.lua y cambia el método del dominio principal:

VirtualHost "meet.ejemplo.com"
    authentication = "internal_hashed"

Añade al final del archivo el dominio de invitados:

VirtualHost "guest.meet.ejemplo.com"
    authentication = "anonymous"
    c2s_require_encryption = false

En /etc/jitsi/meet/meet.ejemplo.com-config.js descomenta y define:

anonymousdomain: 'guest.meet.ejemplo.com',

Y en /etc/jitsi/jicofo/jicofo.conf, dentro del bloque authentication:

authentication {
  enabled = true
  type = XMPP
  login-url = "meet.ejemplo.com"
}

Crea los usuarios y reinicia:

sudo prosodyctl register juan meet.ejemplo.com 'CLAVE_LARGA'
sudo systemctl restart prosody jicofo jitsi-videobridge2

Comprueba el resultado: al abrir una sala nueva debe pedir credenciales, y un invitado con el enlace debe poder entrar solo cuando el anfitrión ya está dentro.

Como capa adicional, dentro de cada reunión puedes activar contraseña de sala y sala de espera. Ninguna de las dos sustituye a la autenticación del servidor: la contraseña se pone después de crear la sala, y el momento vulnerable es antes.

Ajustes que mejoran la experiencia real

Tres cambios en /etc/jitsi/meet/meet.ejemplo.com-config.js resuelven la mayoría de las quejas de calidad.

Limita la resolución que envían los participantes, para bajar el consumo de todos:

constraints: {
  video: {
    height: { ideal: 720, max: 720, min: 240 }
  }
},
startWithAudioMuted: true,
startWithVideoMuted: false,
channelLastN: 6,

channelLastN: 6 indica que cada participante recibe vídeo solo de las seis personas más activas. En una sala de 20 personas, esto convierte 380 flujos en unos 120: la diferencia entre una reunión fluida y una que se congela.

Silenciar el micrófono al entrar (startWithAudioMuted) parece cosmética, pero evita el ruido acumulado de salas grandes.

Tras cada cambio:

sudo systemctl restart jitsi-videobridge2 jicofo
sudo journalctl -u jitsi-videobridge2 -n 100 --no-pager

Jitsi frente a Zoom y Teams

Ser justo aquí importa: Zoom y Teams manejan mejor las conexiones inestables y traen transcripción, grabación en la nube e integración de calendario sin trabajo extra. Jitsi gana cuando el requisito es control de los datos, coste fijo o reuniones internas frecuentes que no justifican licencias por usuario. Si ya pagas Microsoft 365, Teams está incluido y montar Jitsi para lo mismo es duplicar esfuerzo.

Operación y problemas frecuentes

Vigila el consumo durante una reunión real, no en reposo:

sudo systemctl status jitsi-videobridge2 --no-pager
vnstat -l -i eth0

Actualiza con el ciclo normal de apt y prueba una llamada después de cada actualización; nuestra guía de monitoreo de CPU y RAM en Linux sirve para tener el punto de comparación.