Image of an office conference room with empty chairs

Install Jitsi-Meet alongside ejabberd

Since the corona virus is forcing many of us into home office there is a high demand for video conference solutions. A popular free and open source tool for creating video conferences similar to Google’s hangouts is Jitsi Meet. It enables you to create a conference room from within your browser for which you can then share a link to your coworkers. No client software is needed at all (except mobile devices).

The installation of Jitsi Meet is super straight forward – if you have a dedicated server sitting around. Simply add the jitsi repository to your package manager and (in case of debian based systems) type

sudo apt-get install jitsi-meet

The installer will guide you through most of the process (setting up nginx / apache, installing dependencies, even do the letsencrypt setup) and in the end you can start video calling! The quick start guide does a better job explaining this than I do.

Jitsi Meet is a suite of different components that all play together (see Jitsi Meet manual). Part of the mix is a prosody XMPP server that is used for signalling. That means if you want to have the simple easy setup experience, your server must not already run another XMPP server. Otherwise you’ll have to do some manual configuration ahead of you.

I did that.

Since I already run a personal ejabberd XMPP server and don’t have any virtualization tools at hands, I wanted to make jitsi-meet use ejabberd instead of prosody. In the end both should be equally suited for the job.

Looking at the prosody configuration file that comes with Jitsi’s bundled prosody we can see that Jitsi Meet requires the XMPP server to serve two different virtual hosts.
The file is located under /etc/prosody/conf.d/

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

Component "" "muc"
    storage = "memory"
admins = { "" }

Component ""
    component_secret = "SECRET1"

VirtualHost ""
    ssl = {
    authentication = "internal_plain"

Component ""
    component_secret = "SECRET2"

Remember to replace SECRET1 and SECRET2 with secure secrets! There are also some external components that need to be configured. This is where Jitsi Meet plugs into the XMPP server.

In my case I don’t want to server 3 virtual hosts with my ejabberd, so I decided to replace with my already existing main domain which already uses internal authentication. So all I had to do is to add the virtual host to my ejabberd.yml and configure it to use anonymous authentication.
The ejabberd config file is located under /etc/ejabberd/ejabberd.yml or /opt/ejabberd/conf/ejabberd.yml depending on your ejabberd distribution.

    ## serves as main host, as well as for focus user
  - ""
    ## serves as anonymous authentication host for
  - ""
    auth_method: anonymous
    allow_multiple_connections: true
    anonymous_protocol: both

The syntax for external components is quite different for ejabberd than it is for prosody, so it took me some time to get it working.

    port: 5280
    ip: "::"
    module: ejabberd_http
      ## Not sure if this is needed, but by default jitsi-meet uses http-bind for bosh
      "/http-bind": mod_bosh
      "/bosh": mod_bosh
    tls: true
    protocol_options: 'TLS_OPTIONS'
    port: 5275
    ip: "::"
    module: ejabberd_service
    access: all
    shaper: fast
        password: "SECRET1"
    port: 5347
    module: ejabberd_service
        password: "SECRET2"

By re-reading the config files now, I wonder why I ended up placing the focus component under the host and not, but hey – it works and I’m too scared to touch it again 😛

The configuration of the modules was a bit trickier on ejabberd, as the ejabberd config syntax seems to disallow duplicate entries. In this case I had to configure mod_muc for my main domain different than for the domain, so I had to move the original mod_muc and mod_muc_admin configuration out of the modules: block and into an append_host_config: block with different settings per domain.

        ## This is the original muc configuration I used before
            - allow
            - allow: admin
          access_create: muc_create
          access_persistent: muc_create
            - allow
            allow_private_messages: true
            mam: true
            persistent: true
        mod_muc_admin: {}
      ## This is the config only for
      mod_muc_admin: {}

mod_pubsub, mod_ping and mod_bosh all have to be enabled, but can stay in the global modules: block.

Last but not least we have to add the focus user as an admin and also generate (not discussed here) and add certificates for the subdomain.

  - ...
  - "/etc/ssl/"
  - "/etc/ssl/"
  - "/etc/ssl/"
      - ""

That’s it for the ejabberd configuration. Now we have to configure the other Jitsi Meet components. Lets start with jicofo, the Jitsi Conference Focus component.

My /etc/jitsi/jicofo/config file looks as follows.
# Below can be left as is.

Respectively the videobridge configuration (/etc/jitsi/videobridge/config) looks like this:
## Leave below as originally was

Some changes had to be made to /etc/jitsi/videobridge/*<IP-OF-YOUR-SERVER><IP-OF-YOUR-SERVER>

Now we can wire it all together by modifying the Jitsi Meet config file found under /etc/jitsi/meet/

var config = {
    hosts: {
        domain: '',
        anonymousdomain: '',
        authdomain: '',
        bridge: '',
        focus: '',
        muc: ''
    bosh: '//',
    clientNode: '',
    focusUserJid: '',

    testing: {

Last but not least my nginx host configuration (/etc/nginx/sites-available/ where all I changed was the bosh configuration (went from http to https, I heard people say this is not necessary though).

server {
    listen 80;
    return 301 https://$host$request_uri;
server {
    listen 443 ssl;
    # BOSH
    location = /http-bind {
        proxy_pass      https://localhost:5280/http-bind;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;

Finally of course, I also had to register the focus user as an XMPP account:

ejabberdctl register focus SECRET3

Remember to use a safe password instead of SECRET3 and also stop and disable the bundled prosody! That’s it!

I hope this lowers the bar for some to deploy Jitsi Meet next to their already existing ejabberd. Lastly please do not ask me for support, as I barely managed to get this working for myself 😛

11 thoughts on “Install Jitsi-Meet alongside ejabberd”

  1. Thank you for this post, I think it will come in handy. Yesterday I tried the manual installation as I also wanted to integrate it with my existing xmppd (prosody) instead of using the all-in-one Debian package but I gave up when some piece of it required ancient openjdk-7-jre. Is your setup working with openjkd-11-jre?

    “Remember to […] stop and disable the bundled prosody! That’s it!”
    Do you know if I can prevent it from starting it after installation? I don’t want to risk f*ing up my prosody by installing jitsi.

    1. My machine (buster) has only openjdk-11 installed.
      As far as I know, the installation of jitsi-meet should detect your prosody and use that instead of installing another one. I also think that jitsi-meet should add its own configuration into /etc/prosody/conf.d/meet.your-domain.cfg.lua, so you probably don’t have to configure anything?

      1. It just used my existing prosody as I already had the virtual hosts and components configured due to my earlier approach with the manual set up.

        When you use your normal xmpp for authentication instead of, does it mean people can create conferences with their “normal xmpp account” credentials?

  2. @vanitasvitae I'm actually very interested to what extend it actually can "integrate" with the ejabberd XMPP server. Does it just use it silently in the background? Or is there some level of integration possible?F.e. it looks like your page looks quite exactly like the public Jisti Meet without any authentication or so.

  3. Hey! I was playing with this 2 days after you posted, so thank your for sharing your experience.
    I have a working setup now, but I have a problem. maybe you also have it: users losing connection abruptly (you can kill the browser to reproduce it) never leave the room until you send them a message or write in the chat. Are you also experiencing this?


    1. I don’t have said issue I guess. Maybe you don’t have the ping module enabled or some sort of connection timeout disabled?

Leave a Reply

Your email address will not be published.