Installing a Jitsi Server – Apt vs. Docker

Before I installed my first Jitsi server I thought that it must be quite a complicated affair. I searched around a bit and found a simple way to install it via a docker-compose script. The Docker script sets up a couple of Docker containers that encapsulate the different programs required to run the Jitsi-meet server such as the web server, the xmpp server and other stuff. Neat. However, there were two problems that prompted me to search for another solution in a hurry.

Dry-Runs for a Demo

The need for an alternative emerged out of the blue. To give back to the community, I wanted to do a live demo on how to install Jitsi-Meet on a server at the first Divoc conference “Hidden Service”. As lots of things can go wrong in a live demo I really wanted to be prepared so I did a couple of dry-runs. In the last dry run the day before, the installation procedure started to royally fail. I turned out that Jitsi was updated which in turn broke the Docker container setup. And nobody noticed before Easter. That really ruins your day if that happens during a live demo.

A Different Method is Better Than a Fix

But I had a day to find a fix. In the end, my solution was not to use Docker containers at all but to install Jitsi-meet from Jitsi’s own apt repository. Even simpler than using containers! This makes me wonder why there’s a dockerized version of the installation when it is even easier to install it via an apt repository!? Beats me…

The second reason I wasn’t too happy with the Docker version is that adapting things like adding an imprint and a privacy policy to the front page is not straight forward in the dockerized Jitsi installation approach. There are no environment variables and no shared directories where to put such things. Also, I didn’t manage to get performance logging working as this also has to be done inside one of the containers. Much easier in the standard installation.

Not that I’m against dockerized installations in general. Collabora online office as part of a Nextcloud instance, for example, runs happily in a container. But the decision which way to go is not straight forward. Another interesting thing I’ve learnt in the past couple of weeks.