Jitsi on Debian

I’ve just setup an instance of the Jitsi video-conference software for my local LUG. Here is an overview of how to set it up on Debian.

Firstly create a new virtual machine to run it. Jitsi is complex and has lots of inter-dependencies. It’s packages want to help you by dragging in other packages and configuring them. This is great if you have a blank slate to start with, but if you already have one component installed and running then it can break things. It wants to configure the Prosody Jabber server and a web server and my first attempt at an install failed when it tried to reconfigure the running instances of Prosody and Apache.

Here’s the upstream install docs [1]. They cover everything fairly well, but I’ll document the configuration I wanted (basic public server with password required to create a meeting).

Basic Installation

The first thing to do is to get a short DNS name like People will type that every time they connect and will thank you for making it short.

Using Certbot for certificates is best. It seems that you need them for and

apt install curl certbot
/usr/bin/letsencrypt certonly --standalone -d, -m
curl | gpg --dearmor > /etc/apt/jitsi-keyring.gpg
echo "deb [signed-by=/etc/apt/jitsi-keyring.gpg] stable/" > /etc/apt/sources.list.d/jitsi-stable.list
apt-get update
apt-get -y install jitsi-meet

When apt installs jitsi-meet and it’s dependencies you get asked many questions for configuring things. Most of it works well.

If you get the nginx certificate wrong or don’t have the full chain then phone clients will abort connections for no apparent reason, it seems that you need to edit /etc/nginx/sites-enabled/ to use the following ssl configuration:

ssl_certificate /etc/letsencrypt/live/;
ssl_certificate_key /etc/letsencrypt/live/;

Then you have to edit /etc/prosody/conf.d/ to use the following ssl configuration:

key = "/etc/letsencrypt/live/";
certificate = "/etc/letsencrypt/live/";

It seems that you need to have an /etc/hosts entry with the public IP address of your server and the names “ j”. Jitsi also appears to use the names “” but they aren’t required for a basic setup, I guess you could add them to /etc/hosts to avoid the possibility of strange errors due to it not finding an internal host name. There are optional features of Jitsi which require some of these names, but so far I’ve only used the basic functionality.

Access Control

This section describes how to restrict conference creation to authenticated users.

The secure-domain document [2] shows how to restrict access, but I’ll summarise the basics.

Edit /etc/prosody/conf.avail/ and use the following line in the main VirtualHost section:

        authentication = "internal_hashed"

Then add the following section:

VirtualHost ""
        authentication = "anonymous"
        c2s_require_encryption = false
        modules_enabled = {

Edit /etc/jitsi/meet/ and add the following line:

        anonymousdomain: '',

Edit /etc/jitsi/jicofo/ and add the following line:

Then run commands like the following to create new users who can create rooms:

prosodyctl register admin

Then restart most things (Prosody at least, maybe parts of Jitsi too), I rebooted the VM.

Now only the accounts you created on the Prosody server will be able to create new meetings. You should be able to add, delete, and change passwords for users via prosodyctl while it’s running once you have set this up.


Once I gave up on the idea of running Jitsi on the same server as anything else it wasn’t particularly difficult to set up. Some bits were a little fiddly and hopefully this post will be a useful resource for people who have trouble understanding the documentation. Generally it’s not difficult to install if it is the only thing running on a VM.

6 comments to Jitsi on Debian

  • Derek

    While they look like hostnames, the auth.$HOSTNAME and such do NOT need to be on the certificate.

  • Derek: I didn’t test with a certificate that doesn’t have as a CN, but there is a Prosody VirtualHost section for with ssl defined. It could be that the part of Jitsi which connects isn’t doing certificate hostname checks, but it seems like a good practice to use a valid certificate anyway. Even if it could work now without the extra CN makes it work in future.

  • Anonymous

    Great info Russell – thanks for taking the time – I might have a go…

  • Aces, Russell! A miscellany of items you might wish to review:

    [Hmm, I wish this blog software offered preview mode. Here’s hoping.]

    1. It’s an extremely good idea to make sure the FQDN is not merely in DNS but also appended to the localhost line in /etc/aliases, and that you’ve done “hostnamectl set-hostname [FQDN]”

    2. Update /etc/systemd/system.conf to have:


    Implement those changes:

    # systemctl daemon-reload

    After installing packages including Jitsi Videobridge, check system limits to verify:

    # systemctl status jitsi-videobridge2 | grep Tasks
    Tasks: 39 (limit: 65000)
    # cat /proc/`cat /var/run/jitsi-videobridge/`/limits | grep -e processes -e open
    Max processes 65000 65000 processes
    Max open files 65000 65000 files

    3. FYI, after you install Jitsi Project third-party repo’s packages for Debian plus either Apache HTTPd or nginx (I used nginx0, the Jitsi Meet packages provide a very robust post-installation script, /usr/share/jitsi-meet/scripts/, that can be run take care of all conversion work to use Let’s Encrypt, with minimal fuss. Recommended.

    4. Don’t forget to edit /etc/jitsi/videobridge/ to add two new lines, if behind NAT (as was I):[LOCAL IP][PUBLIC FACING IP]

    and comment out line

    5. I find it desirable to edit /etc/jitsi/meet/[FQDN]-config.js to set:

    startWithAudioMuted: true,
    startWithVideoMuted: true,

    This is extremely helpful towards conserving both bandwidth and CPU capacity on (especially) the Jitsi Videobridge 2 (“JVB2”) component and (to a degree) client machines, and permits per-room scaling well past the ‘soft’ performance- and WebUI-efficiency-related limit of 36 persons and even the ‘hard’ limit of 75 persons per room. As you and I discussed last night, having a large number of persons per room all running streaming video at each other is almost never useful, anyway. Generally, if you’re worrying about hitting either the soft or hard limit on room capacity and seriously are considering 100+ users in a Jitsi Meet room, it mean you’re trying to solve the wrong problem: You should either have users keep outbound video muted unless/until needed, or be using live-streaming, e.g., to YouTube.

    Scaling out to greater numbers of rooms to pretty much arbitrary site sizes can be accomplished by connecting in more JVB2 instances, as required.

    6. FYI: Example services restart (SysVInit style):

    # /etc/init.d/jitsi-videobridge2 restart
    [ ok ] Restarting jitsi-videobridge2 (via systemctl): jitsi-videobridge2.service.
    # /etc/init.d/jicofo restart
    [ ok ] Restarting jicofo (via systemctl): jicofo.service.
    # /etc/init.d/prosody restart
    [ ok ] Restarting prosody (via systemctl): prosody.service.
    # /etc/init.d/nginx restart
    [ ok ] Restarting nginx (via systemctl): nginx.service.

    7. In my deployment, we needed Zabbix monitoring, which turned out to require the zabbix-agent 5.x package provided by backports, since Debian-stable at this date provides 4.0.4, which is [eye-roll] incompatible.

    Create /etc/apt/sources.list.d/buster-backports.list containing

    deb buster-backports main

    # apt-get update
    # apt-get -t buster-backports install zabbix-agent

    # dpkg -l | grep zabbix
    ii zabbix-agent 1:5.0.1+dfsg-1~bpo10+1 amd64 network monitoring solution - agent

    In /etc/zabbix create psk.conf containing
    [key hash]

    Edit /etc/zabbix/zabbix_agentd.conf to have

    Server=[FQDN of Zabbix server]
    ServerActive=[FQDN of Zabbix server]
    Hostname=[FQDN of Jitsi Meet host]

    Edit /etc/nginx/sites-available to add in the port 80 section:

    location = /basic_status {
    allow [Zabbix server IP];
    deny all;

    Add in the port 4444 section:

    location = /basic_status {
    allow [Zabbix server IP];
    deny all;

    systemctl restart nginx.service
    systemctl start zabbix-agent.service
    systemctl enable zabbix-agent.service

  • On the matter of Jitsi Meet scaling, an acquaintance asked me:

    So meetings with more than perhaps 30 participants are a bad idea?

    My reply:

    Well, Jitsi Project says that there’s a hard limit of 75 participants per conference (room), set in the software. They are intending to soon
    raise that, probably to around 100. 35 is a soft limit, where they say ‘the experience will suffer’. Part of that is that the UI is not optimised for that many simultaneous video participants, and also scaling that large a multiple-video-streams load across multiple servers but still having them be in the same conference is difficult, and they’re still working on how to best handle that. (Scaling to more rooms on the other hand is in the bag, and can be done by adding more Jitsi Video Bridge instances, way up into thousands and thousands of participants.)

    Some fine points about that, though:

    1. There’s no problem to adding a whole lot of audio-only participants (calling in to a VoIP telephone number) to the conference. That lets you effortlessly scale to 50 or even 100 participants.

    This averts most of the problem, since the fundamental reason for both the soft and hard limits us that the intensive -video- demands of cross-connecting so many simultaneous users tend to peg CPU usage on even pretty beefy server machines running Jitsi Video Bridge — but no video for a bunch of additional conference-joiners means no pegging.

    2. Another way to finesse the soft limit is to have participants default upon conference entry to video turned off & audio muted. This
    was how I set the Jitsi Meet instance run by Exhibits. Nobody ever loaded one of its conferences down with dozens of participants, though, so I can’t say we tested my sense of things, but FWIW, I’m pretty confident that performance would remain good all the way up to 75 participants, as long as most remained video off and muted.

    3. There’s no point in telling people they shouldn’t want 50-70 full-video, full-audio simultaneous participants in a conference
    (‘room’), because people want what they want, and, 41 years after VisiCalc, people are still insisting on using their spreadsheet programs for use-cases crying out for a database. However….

    Let me put it this way: This year, my wife and I were supposed to go back to my college for my first reunion ever, my 40th: I’m an alumnus of Princeton, class of 1980. We got all ready to go, all paid up, and then the world fell apart, Princeton cancelled, and suddenly all 1,000 of us were invited to have a virtual reunion on Zoom, instead. About 200 of us actually did, and a Zoom conference with that many participants is truly ridiculous. The possibility for interaction was almost nil, though I did get the schadenfreude of letting my classmates see that I look great at age 62 and for me to see that most of them really don’t. Aside from that, all that saved it from being utter madness was the Zoom breakout-room feature, where I could mingle with 10 long-lost classmates instead of 200.

    Jitsi Meet doesn’t have breakout rooms (though a subset of members can just decide move to a different room). But it does have livestreaming, a variant of what Zoom calls the webinar feature, where participants who don’t aspire to interact can see the conference, e.g., via a livestream to YouTube or a similar video streaming service.

    But I’ll bet that even without resorting to livestreaming, you can scale up a Jitsi Meet room (with a beefy machine powering Jitsi Video Bridge) to 120 participants if the default is video-off, audio muted, and only a modest number of people, primarily the panelists, switched their cameras on.

    Somehow, because the distribution default of Jiti Meet is that everyone enters a conference with video running, and because evinces that default, almost everyone fails to realise you can trivially reverse that default by changing /etc/jitsi/meet/$FQDN-config.js from

    startWithVideoMuted: false,


    startWithVideoMuted: true,

    Anyway, personally, I think wanting to run a room with over 35 simultaneously active video participants is kind of nuts — but I’m
    aware that people think they need that because it doesn’t occur to them that there’s any different way. People want what they want.

    [He asked me about performance of the server I constructed for the 2020 World Science Fiction convention in Wellington. I replied:]

    To my surprise, CoNZealand’s Jitsi Meet instance (for Exhibits) ran with an extremely light load at all times — even though I never needed to even think of adding in more Jitsi Video Bridge instances (which I was prepared to do if we needed that for scaling). Getting the Zabbix stats would be enlightening, but every time I looked it was barely kicking over. (I’m sure ‘startWithVideoMuted: true,’ helped.)

  • I meant /etc/hosts, not /etc/aliases. Sorry about that.