How to setup a self-hosted Jitsi video chat server

Based on the current situation video chat systems are becoming more and more popular. There are a lot of different solutions on the market. Some of them are free to use. Some of them need a paid subscription plan. Some of them are encrypted and guarantee a certain level of data privacy. Some others don’t have that.

I would like to show you how to setup your self-hosted video chat server with the Open Source software Jitsi. There are a lot of tutorials online and everything seems to be super easy. I would like to focus on a few more topics so we end up with a usable, production ready system that you can deploy for one of you customers for example.

Since Jitsi is under active development and some of the settings may change please keep in mind that I recorded this video in April 2020 and even though I try to keep it as general as possible some details might have changed depending on when you are watching this.

Installing Jitsi

First off, you need to setup a dedicated or virtual server that hosts the Jitsi video chat software. There are a lot of providers and I will not go into the details of setting this up. Make sure to setup a domain name that points to your server. I also do not want to reiterate what the Jitsi quick install guide already tells you. Have a look this at the website.

Setting up the firewall

When it comes to setting up the firewall the Jitsi quick start guide only states which ports you need to open but does not exactly tell you how to do this. I’m using ufw the uncomplicated firewall for this so let’s have a look at the details.

aptitude install ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow http
ufw allow https
ufw allow 10000/udp
ufw enable

You install the Debian package ufw and issue the following commands to setup the firewall rules. This opens the SSH port and HTTP and HTTPS ports. Furthermore it will open port 10.000 UDP (not TCP) for Jitsi. In some older tutorials you will see that the whole range from port 10.000 to 20.000 was opened which is not necessary anymore.

TLS certificate addition

At the end of the installation process you will get the hint to install a Let’s Encrypt TLS certificate using the script It also states that you should rerun the script to renew the certificate but this is generally a bad idea and you should automate this process of course.

Simply create a file in /etc/cron.daily/ named certbot and add the following content to it:

certbot-auto renew -n &>/dev/null

Save and close the file and make it executable like so:

chmod 755 /etc/cron.daily/certbot

If you’re using Nginx – which is the default dependency on Debian right now – you need to tell the webserver that it should reload its configuration when a new certificate is deployed. Add a file 01-reload-nginx to the directory /etc/letsencrypt/renewal-hooks/deploy with the following content:

service nginx reload

And again, make the file executable with this command:

chmod 755 /etc/letsencrypt/renewal-hooks/deploy/01-reload-nginx

Placing the script in the deploy hook makes sure that it only runs after a successful renewal. If you would use the post hook instead it would run after each attempt to renew it. This might not be really bad but the deploy hook just seems to fit better. You can read about more details in the Certbot documentation.

Hardening Nginx

By default the Nginx configuration and the Jitsi virtual host configuration get a B score when you test your Jitsi domain with Let’s improve this with a few simple steps.

First off, set server_tokens to off in the nginx.conf to hide the exact version number of the webserver. Then run the following openssl command to generate custom parameters for the Diffie-Hellman (DH) key exchange.

openssl dhparam -out dhparams.pem 4096

Finally add or change the following settings both in the nginx.conf and your specific virtual host file under sites-avalable in /etc/nginx.

ssl_protocols TLSv1.2;?
ssl_dhparam /etc/nginx/dhparams.pem;

Depending on where you generated the dhparams.pem file please make sure to move it to /etc/nginx.

Optional Nginx changes

The following steps are completely optional and you do not have to do this.

Clear the default homepage of Nginx:

cp /dev/null /var/www/html/index.nginx-debian.html

Disallow web robots to crawl the Jitsi website:

echo -e "User-agent: *\nDisallow: /" > \/usr/share/jitsi-meet/robots.txt

Depending on what you are trying to archive with regard to data privacy you might want to disable the logging of the Nginx webserver altogether with this in the nginx.conf:

access_log off;
error_log off;

Customizing Jitsi

The default Jitsi website already looks pretty neat but your can easily customize the look if it. If you are hosting such a website in Germany for example you definitely want to include links to the imprint and to a page with the data privacy information.

Change the logo in /usr/share/jitsi-meet:

sed ’s/..\/images\/watermark.png/yourlogo.png/‘ \css/all.css > tmp.txt
mv tmp.txt css/all.css

And yourlogo.png should be something like: https:\/\/\/path\/to\/logo.png .

Then you might want to edit the file interface_config.js (example for German translation given) in /usr/share/jitsi-meet/:

+  JITSI_WATERMARK_LINK: 'https:///'

The last one („generate room names“) is just a matter of your personal preference. Since most of the not so tech-savvy users may get confused with this random typing in the input field I disabled the feature.

Change welcome text in /usr/share/jitsi-meet/lang/main-de.json

"welcomepage": {
  "appDescription": " ",
  "title": "Your corporation"

It depends on your situation and it’s just my personal preference to clear the standard description that comes with Jitsi.

Again, if you are required to link to certain information by law you should change the footer and include those links there. It involves changing the following two files:


You can find a nice description how to do this in the community forum:

Monitoring Jitsi

You can have a look at the log files jicofo.log and jvb.log in /var/log/jitsi/ but unfortunately it’s not that easy to get a hold of the number of active meeting rooms or the number of participants in those rooms.

The jitsi-videobridge comes with a REST API that has endpoints for common stats and the conference rooms. You can activate the webservice by editing /etc/jitsi/videobridge/config and adding the following:


Then run “service jitsi-videobridge2 restart” and after that you can access stats and conference details here:


If you ssh into your server you can forward the port 8080 to your local machine so you can easily access the webservice with your local browser:

ssh -L8080:localhost:8080 <your-server>

You can check out the following links for more details:

Securing Jitsi

By now you have a Jitsi installation that allows everybody to start a new conference. If you are seeing a lot of abuse on your server or want to restrict this to users with a username and password right away you can configure something called a “Secure domain” in Jicofo. More details can be found here:

I will not go into the details of setting this up because there are other possibilities for you and it depends on what you’re trying to archive. For example you could simply use HTTP authentication to protect your whole Jitsi website as well.


Setting up your own video chat server with Jitsi is very straight forward. I hope this post helps you to get it production ready for your clients.