Jitsi Meet is a free video-conferencing package
of which I have been hosting an instance since 2020. Here's how I have
it set up.
I use the Debian packages. You can do it via Docker instead.
deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/
I'm already running Apache on that machine, and have it set up as a
virtual host (PUBLICNAME replaces the public DNS name in the
configuration below). mod_ssl and mod_proxy are needed. I'm using
Let's Encrypt SSL certificates, which get renewed via the standard
mechanisms that everything else uses.
<VirtualHost *:80>
ServerName PUBLICNAME
Redirect permanent / https://PUBLICNAME/
</VirtualHost>
<VirtualHost *:443>
ServerName PUBLICNAME
# enable HTTP/2, if available
Protocols h2 http/1.1
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/letsencrypt/live/PUBLICNAME/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/PUBLICNAME/privkey.pem
Header always set Strict-Transport-Security "max-age=63072000"
DocumentRoot "/usr/share/jitsi-meet"
<Directory "/usr/share/jitsi-meet">
Options Indexes MultiViews Includes FollowSymLinks
AddOutputFilter Includes html
AllowOverride All
Order allow,deny
Allow from all
</Directory>
ErrorDocument 404 /static/404.html
Alias "/config.js" "/etc/jitsi/meet/PUBLICNAME-config.js"
<Location /config.js>
Require all granted
</Location>
Alias "/external_api.js" "/usr/share/jitsi-meet/libs/external_api.min.js"
<Location /external_api.js>
Require all granted
</Location>
ProxyPreserveHost on
ProxyPass /http-bind http://localhost:5280/http-bind
ProxyPassReverse /http-bind http://localhost:5280/http-bind
ProxyPass /xmpp-websocket ws://localhost:5280/xmpp-websocket
ProxyPassReverse /xmpp-websocket ws://localhost:5280/xmpp-websocket
ProxyPass /colibri-ws/default-id ws://localhost:9090/colibri-ws/default-id
ProxyPassReverse /colibri-ws/default-id ws://localhost:9090/colibri-ws/default-id
RewriteEngine on
RewriteRule ^/([a-zA-Z0-9]+)$ /index.html
</VirtualHost>
There's no authentication required: I just pass out a suitable long
meeting URL beforehand, and I haven't had any trouble with outsiders
jumping into conversations. (Obviously I could apply basic auth in the
standard ways.)
The only problem I have found, which doesn't seem to be a standard
error, is that sometimes when the second person connects to a
meeting both will get an error message (this is the point at which the
video bridge should be fired up automatially). Restarting the
background daemons gets the job done.