Hosting my own Jitsi video conferencing server

So I decided to host my own jitsi video conferencing server.

I started this project after searching for video conferencing solutions with privacy in mind. After someone made me aware of Jitsi I started doing some research into this software. Jitsi is a free an open source software which pretty much exactly does what I want. Driven by curiosity I wanted to try this myself.

Jitsi Landing Page English

The Software

Jitsi is free and open source software that uses WebRTC to establish the connections between endpoints. The Code is available here on GitHub. Jitsi consists basically of two main components, a SFU (selective forwarding unit) called the Jitsi Videobridge (JVB), and the Jitsi Meet Application.

If there are just two participants on the call the link is established via a P2P WebRTC session, which means that the server is not needed to do anything more than to connect the participants. In this case, the two endpoints communicate directly end-to-end encrypted via DTLS-SRTP.

WebRTC is (currently) not able to offer end-to-end encrypted connections for more than two participants. In this use case, the connection of all participants to the server is still encrypted with DTLS-SRTP. The JVB decrypts the video streams only while they are traversing it, however this data is never stored (except going through memory, of course, but not persistently). Jitsi have an article up about security, which I encourage everyone to read.

Jitsi can handle the switch between P2P and JVB seamlessly and automatically. Also, the JVB is able to detect connection quality and available bandwidth and adjust the video quality automatically.

Since Jitsi can be deployed on own servers (this is even encouraged), everyone can host their own instance which they can therefore trust.

A great thing about the JVB is that no transcoding of the video streams is necessary. This should reduce the load on the cpu significantly.

If needed, Jitsi can even be configured to use a SIP gateway (Jigasi) for phone connections.


I set up a new Linode server, hosted in Germany. Since I mainly was curious and wanted to test the software, and it is intended for my personal use only, I decided to go with a Linode Nano. This is the server: Ubuntu 18.04 LTS, Nanode 1GB: 1 CPU, 25GB Storage, 1GB RAM. The Nanode comes with 1 TB of monthly outbound traffic.

After the server got deployed by Linode I just made the A and AAAA DNS entries with the servers IPv4 and IPv6 addresses.

The installation itself is described in detail in the quick install document. They described the setup of the FQDN as optional. I made sure to update the /etc/hostname and /etc/hosts to contain my chosen domain name.
The same name has to be entered during the setup process.

Per default the firewall on the Ubuntu install is not enabled, so I enabled it and added the rules for Jitsi to work properly. Jitsi uses Port 10000 for a UDP session and 4443 (TCP) as fallback. Of course 443 should also be allowed, as well as SSH if needed.

After installation I once ran into the problem of not being able to access the landing page of Jitsi but only default nginx page. After searching online the simplest solution was to just deploy the server again with a fresh install of Ubuntu and run the setup process again. Everything is so fast and easy that this wasn’t a significant hurdle.

Jitsi, installed with default settings, creates it’s own self signed certificate. Optionally another certificate can be used. They also provide a handy script to obtain a Let’s Encrypt certificate. This is the option I used.
The renewal with certbot-auto can be automated with a cronjob. I didn’t bother with this at the moment (but will probably later) as I just wanted to try the software.

All in all Jitsi seems to work as promised. A few test calls using devices in my home were successful. Now I will continue to test Jitsi and use it for video calls.

Important details

  • The mobile clients (iOS/Android) need a connection with a valid certificate, otherwise they won’t connect to the server at all.
  • Firefox is (currently) not fully supported. Jitsi discourages the use of Firefox at the moment, as it may be detrimental to the connection quality, even for other participants. This is among other things due to a lack of multicast support in firefox (or their implementation thereof). The community seems to be working on this issue.
  • Safari doesn’t support WebRTC video (with H.264) at all (no matter the (video conferencing) software used).
  • Chrome (and derivatives like Chromium, Opera, etc.) work just fine.
  • There even exists a cross platform Electron App for Windows, macOS, and GNU/Linux. For this to work the external API needs to be activated. I didn’t bother with this.
  • Let’s Encrypt only issues certificates for Domains. If the Server is only reachable via an IP Address, Let’s Encrypt can’t be used for certificate generation.


2020-04-11: Cron

Turns out, certificate renewal for Let’s Encrypt is way easier than expected. It seems to me that the install script for the certificate didn’t install certbot. So I installed certbot with apt-get install certbot.

I let it run once with certbot-auto and told it to renew all available certificates and to let nginx redirect all http traffic to https.

Future renewals of the certificate should be easy with cerbot renew.

As it turns out, cerbot automatically creates a cronjob at /etc/cron.d/certbot.

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl$ -e 'sleep int(rand(43200))' && certbot -q renew

So this way there should be no more worry about manual certificate renewal.

These sites were helpful to me.