Conferencia virtual con open source: Jitsi + PeerTube + Matrix en 2026

octubre 3, 2026 Alfonso Moreno | Sysadmin Senior 25 Visitas 12 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué organizar tu propia conferencia virtual en 2026

Las conferencias y meetups técnicos siguen siendo el mejor sitio para que tu comunidad comparta lo que está aprendiendo. Después de la pandemia el formato virtual se normalizó, pero la mayoría terminó apoyándose en plataformas propietarias (Zoom, Hopin, Brevo) cuyo modelo de negocio depende de vender los datos de tus asistentes. Si tu comunidad es open source y tus valores incluyen soberanía tecnológica y privacidad, hay una contradicción difícil de defender.

El equipo de diseño de Fedora enfrentó exactamente esto cuando arrancó su propio summit en enero de 2023 (la primera edición del Creative Freedom Summit) y decidió correr todo sobre software libre. No porque fuera lo más fácil — fue lo más coherente. Tres años después, en 2026, las herramientas que usaron siguen vivas y son más fáciles de desplegar que nunca: Jitsi Meet, PeerTube, Matrix/Element, LimeSurvey, Etherpad/HackMD. Cada una por separado es trivial de instalar; combinadas forman una pila lista para un evento de 50 a 500 personas.

Este artículo toma esa receta como base y la actualiza para 2026, con las versiones vigentes de cada proyecto y comandos concretos para que puedas probarla en un homelab antes de animar a tu comunidad.

Las piezas del stack (y por qué encajan)

Una conferencia virtual open source necesita cubrir seis funciones críticas: transmisión en vivo, sala con oradores, sala social abierta, chat central con preguntas, sitio web público y encuesta post-evento. No todas las piezas resuelven una sola función — algunas hacen dos cosas a la vez — pero cada slot tiene que estar cubierto.

Función	Herramienta	Versión actual (2026)	Por qué esta pieza
Transmisión en vivo + replay automático	PeerTube	v8.2 (mayo 2026)	Federado, fediverso, replay cuasi-instantáneo sin subir manualmente
Sala de oradores (cerrada, con lobby)	Jitsi Meet	2.0.10888 (abril 2026, mensual)	Sin cuentas, lobby, livestream RTMP directo a PeerTube
Sala social (abierta a quien quiera encender)	Jitsi Meet (segunda sala)	mismo paquete	URL separado, sin lobby, sin password
Chat central, Q&A, anuncios	Matrix + Element	Matrix v1.19 (julio 2026)	Widgets embebidos (video, etherpad), persistente, archivable
Documento colaborativo / Q&A en vivo	Etherpad o HackMD	HackMD estable	Markdown colaborativo, exportable, embed como widget en Matrix
Sitio web del evento	WordPress (estático o dinámico)	cualquier versión actual	Schedule, información de acceso, página de aterrizamiento
Encuesta post-evento	LimeSurvey Community	7.5.0	Encuestas research-grade, export CSV, self-host
Edición y subtitulado post-evento	Kdenlive	v25.x	Editor no lineal, subtitulado automático speech-to-text

La gracia del stack es que todas las piezas son instalables con docker compose o paquetes nativos, y los puntos de fricción entre ellas están bien documentados: Jitsi sabe cómo empujar un stream a PeerTube vía RTMP, Matrix embebe widgets web (video, Etherpad, calendario) como si fueran paneles de un IDE.

Cómo montar PeerTube para la transmisión

PeerTube es la pieza más crítica porque hace dos cosas a la vez: transmite en vivo y entrega replay automático sin que nadie tenga que subir el video de vuelta. Configurarlo es lo que más asusta al principio, así que lo dejamos explícito paso a paso.

La forma rápida para probar es una instancia pública federada, como la que usó el Creative Freedom Summit (linuxrocks.online). Si quieres tu propia instancia en un VPS o en tu homelab, el camino más estable es la imagen OCI oficial vía docker compose.

# Crear un directorio de trabajo y bajar el compose oficial
mkdir -p ~/peertube && cd ~/peertube
curl -sLo docker-compose.yml https://raw.githubusercontent.com/Chocobozzz/PeerTube/master/support/docker/production/docker-compose.yml
curl -sLo .env https://raw.githubusercontent.com/Chocobozzz/PeerTube/master/support/docker/production/.env
# Editar .env: al menos PT_HOSTNAME, PT_EMAIL, PEERTUBE_DB_PASSWORD
# y generar los secretos que están en blanco:
sed -i 's/^PEERTUBE_SECRET=.*/PEERTUBE_SECRET='"$(openssl rand -hex 32)"'/' .env
sed -i 's/^PEERTUBE_PRIVATE_KEY=.*/PEERTUBE_PRIVATE_KEY='"$(openssl rand -hex 32)"'/' .env
# Levantar. La primera vez crea DB, migra schema y arranca nginx.
docker compose up -d
# Esperar a que el backend responda (puede tardar 1-2 min la primera vez)
until docker compose exec -T postgres pg_isready -U peertube; do sleep 2; done

Una vez arriba, abrir el panel, ir al canal donde quieres transmitir, click en Publish → Go live. PeerTube genera una URL RTMP y una clave. Esa URL es exactamente lo que conectarás con Jitsi.

Detalle importante que ahorra horas el día del evento: PeerTube genera UNA URL persistente por canal, no una por transmisión. Eso significa que el documento compartido entre los voluntarios puede tener la misma URL durante toda la conferencia — no hay que regenerar claves cada vez que un orador distinto abre Jitsi.

Cómo montar Jitsi Meet y conectarlo a PeerTube

Jitsi Meet es la sala donde están los oradores. La gracia es que cualquier persona con la URL entra a una sala limpia sin cuenta, sin instalar nada, y desde el navegador puede activar cámara y compartir pantalla. Para el evento necesitas dos salas: una cerrada (con lobby o password) donde solo ellos se vean, y otra abierta para el evento social.

El camino rápido es usar el meet.jit.si público que mantiene el proyecto. Para auto-hospedaje, el patrón más estable es docker con prosody como backend XMPP.

# Clonar el repo oficial de quick-install
git clone https://github.com/jitsi/docker-jitsi-meet.git ~/jitsi
cd ~/jitsi
# Copiar el env de ejemplo y generar secretos
cp env.example .env
./gen-secret.sh .env
# Levantar. Por defecto abre 443/10000 UDP (media).
docker compose up -d
# Verificar que el bridge WebRTC responde
docker compose ps
curl -skI https://localhost/ | head -3

Una vez arriba, crear dos salas con URLs distintas (por ejemplo nombre-evento-stage y nombre-evento-social). Para evitar interrupciones, activa el lobby en la sala de oradores: una vez dentro de la reunión, menú → Settings → Lobby, y solo deja pasar al orador siguiente cuando la sala esté libre.

Para conectar la sala de oradores a PeerTube, dentro de Jitsi ir al menú → Start live stream, copiar la URL RTMP + stream key de PeerTube (separados por una barra /), y pegar. Jitsi confirma con una voz de “Live streaming is on” cuando el stream está al aire. Esto NO reemplaza tu propia pantalla — es una capa encima que recibe la mezcla de audio/video de la sala.

Cómo evitar los bugs que vimos en vivo

El equipo de Fedora documentó dos problemas que aparecen tarde si no los pruebas antes. El primero es el feedback de audio: si la persona que monitorea el stream tiene una pestaña abierta de PeerTube con el stream sonando, ese audio vuelve a entrar a Jitsi y se retroalimenta. El segundo es el corte entre charlas: si dejás el stream de Jitsi corriendo toda la mañana, el replay automático de PeerTube graba todas las charlas como un solo video y nadie puede saltar a la suya.

Para ambos, la solución es la misma: separación de roles y disciplina operativa.

# Test 1: feedback audio. Dos máquinas distintas.
# Máquina A: abre Jitsi como host + monitorea PeerTube en navegador distinto.
# Máquina B: speaker A comparte pantalla y habla.
# Si máquina A escucha su propia voz con delay, hay loop. Mute inmediato.
# Test 2: corte entre charlas.
# Una vez confirmada la conexión, en Jitsi: menú → Stop live stream.
# Volver a Start live stream antes de la siguiente charla.
# Cada replay en PeerTube queda como video separado.

Consejo operativo: no hagas al emcee responsable del monitoreo del stream. Si tienes una persona extra, dedicate al monitoreo en una máquina y al hosting en otra. Si no, el emcee tiene que silenciar manualmente cualquier pestaña de PeerTube que tenga abierta antes de cada charla, y esa distracción es lo que genera los retrasos.

Cómo montar Matrix + Element como chat central

Matrix es la pieza que mantiene a toda la conferencia en un solo lugar: chat, Q&A, anuncios, y como contenedor de los widgets que muestran el video y el documento colaborativo. La imagen Element se conecta al host, conserva el historial, archivable, y permite widgets embebidos que se renderizan dentro del chat como paneles.

Para auto-hospedaje en 2026, la opción menos fricción es Element Server Suite (ESS) Community, que empaqueta Synapse + Element + bridges en un solo appliance docker. Si quieres serverlizar más fino, la receta clásica sigue siendo Synapse + element-web + coturn para voz/video.

# Rápido: matrix-docker-ansible-deploy (recomendado oficial)
git clone https://github.com/spantaleev/matrix-docker-ansible-deploy.git ~/matrix-ansible
cd ~/matrix-ansible
# Copiar y editar inventario
cp examples/hosts homeserver.yml
# Editar: matrix_domain, matrix_server_fqn_hosts, etc.
# Generar config base:
ansible-playbook -i hosts setup.yml --tags=setup-all
# Configurar:
ansible-playbook -i hosts setup.yml

Una vez con tu homeserver, crear el canal público del evento con un topic fijo (URLs de PeerTube, etherpad, código de conducta) y crear un canal Backstage privado solo para oradores y voluntarios. Matrix widgets (la pestaña ⋮ → Manage widgets) permiten embeber un iframe de PeerTube (URL del live) y un iframe de HackMD (documento del día) como si fueran paneles del canal — el asistente entra al canal y ve todo lo que necesita sin abrir más pestañas.

Cómo correr la encuesta con LimeSurvey

Una semana después del evento, mandá una encuesta para medir qué funcionó y qué no. LimeSurvey Community 7.5.0 es research-grade, exporta a CSV/R/PDF, soporta lógica de branching, y corre self-hosted con docker o en un LAMP estándar.

# Levantar LimeSurvey Community
docker run -d --name limesurvey 
  -p 8080:80 
  -e LIMESURVEY_DB_HOST=db 
  -e LIMESURVEY_DB_USER=lime 
  -e LIMESURVEY_DB_PASS=$(openssl rand -hex 16) 
  -e LIMESURVEY_DB_NAME=limesurvey 
  mariadb:11 &
  limesurvey/limesurvey:7.5.0-apache
# Crear DB
docker run -d --name limesurvey-db 
  -e MARIADB_ROOT_PASSWORD=$(openssl rand -hex 16) 
  -e MARIADB_DATABASE=limesurvey 
  -e MARIADB_USER=lime 
  -e MARIADB_PASSWORD=secreto_secret 
  mariadb:11
# Instalar via web en http://localhost:8080/

Una vez con LimeSurvey arriba, crear el cuestionario, agregar las preguntas clave (cómo se enteraron del evento, qué herramienta usaban para asistir, qué charla les sirvió, qué mejorarían), activarlo, y mandar el link por el canal Matrix del evento + el canal PeerTube de la grabación.

Subtitulado y republicación con el post-evento

Cuando las grabaciones están disponibles, automáticas (editar + subtitular). Kdenlive desde la versión 25.x trae speech-to-text integrado en su motor de efectos: genera subtítulos a partir del audio, los pone en la línea de tiempo, y los exporta a SRT. Fedora Design Team mantiene un tutorial abierto sobre esto, vale la pena leerlo antes.

# Instalar Kdenlive (Debian/Ubuntu)
sudo apt install kdenlive
# O con flatpak (versión más nueva)
flatpak install flathub org.kde.kdenlive
# Una vez con Kdenlive, importar el .mp4 del replay,
# ir a Effects → Speech to Text, seleccionar idioma,
# Kdenlive coloca los subtítulos automáticamente.
# Exportar → Render → MP4 + SRT separado.

Subir el video editado a PeerTube (canal principal) o un canal privado de voluntarios, generar subtítulos con Kdenlive, y subir el SRT junto al MP4 al canal principal. El ciclo completo desde la grabación cruda hasta el video subtitulado tomó 4-6 semanas a los voluntarios de Fedora; planificar en consecuencia si tu comunidad es pequeña.

¿Vale la pena para tu comunidad?

Si tu comunidad es de 20 personas y solo necesitas una reunión, usa meet.jit.si y listo — el stack self-hosted es overkill. Si tu comunidad es de 50+ y quieres evento serio con sponsor booths, networking, y material grabable, el stack completo vale la pena: las piezas son todas open source, federadas o self-hostables, y funcionan bien en hardware modesto (un VPS de 4 vCPU + 8 GB RAM aguanta todo el stack excepto PeerTube, que necesita 2-4 GB RAM adicionales por instancia).

Lo que NO vale la pena: pretender que toda conferencia open source tiene que correr en open source. Si tu presupuesto es ajustado, tu equipo técnico limitado, y tu prioridad es llegar a gente rápido, una plataforma propietaria bien elegida (Zoom Events, Hopin si todavía existe) es perfectamente legítimo. Lo que el Creative Freedom Summit demostró es que el argumento “no se puede correr una conferencia decente solo con open source” es falso — pero la decisión sigue siendo tuya según presupuesto y capacidad técnica.

Resumen

La receta Creative Freedom Summit sigue vigente tres años después con cambios mínimos: Jitsi Meet 2.0.x mensual, PeerTube v8.2 con catch-up live, Matrix v1.19 con widgets, LimeSurvey 7.5. Lo que cambió es la madurez: instalación con autosuites, docker compose para todo, y suficiente material comunitario como para que un sysadmin con 2 días libres arme un stack funcional. El próximo paso natural es probarlo en tu homelab con un evento de prueba de 5 personas — el resto escala solo cuando lo necesite.

Preguntas frecuentes

¿Por qué Conferencia virtual con open source: Jitsi + PeerTube + Matrix en 2026 es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Conferencia virtual con open source:?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Conferencia virtual con open source:?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Conferencia virtual con open source: y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Conferencia virtual con open source:?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.