Self-hosted Jitsi setup

Dear community,

I am having issues trying to get my self-hosted Jitsi server established. My setup is somewhat complex but not uncommon perhaps. With that said, in the aspect of taking baby steps, even the most basic setup deployed on a private network does not work correctly.

Following the instructions laid out on Jitsi website I am able to get Jitsi installed and running, however no one can connect to a room. In the most basic form my setup consists of…

  1. Ubuntu 20.04-LTS server (NAT’d). There is an Apache2 Proxy server in front.
    • Tried using just IP address
    • Tried setting a FQDN
    • Have not setup Let’s Encrypt on the Jitsi server itself since the goal will be to let Proxy handle it. Elected to use self-signed option until working setup was complete. Then plan on switch to Let’s Encrypt later.
  2. I do see Warnings/Errors in Prosody logs about not binding to Port due to certificate error.
    • Since Jitsi server is behind a proxy, how can I get Let’s Encrypt to install a certificate if port 80 is being used by Proxy server?
  3. With the basic install, navigating to https://192.168.x.x from within my LAN, renders the Jitsi page, however when starting a meeting room, a second party cannot join the established room.
    • There are continuous disconnection and re-connection messages within the meeting room.
  4. I would imagine at this point in early setup, I should be able to test a meeting room?

Ultimately the diagram below is what I’m shooting for. However I’ve installed, removed, re-installed enough to where I’m losing hope on getting a function Jitsi server up even without the Reverse Proxy setup. Hopefully someone may suggest a solution to my setup woes. Much appreciated.

  • a NAT rule is needed for UDP/10000 too
  • external and internal clients must use the same FQDN
  • probably you will need an internal DNS server to resolv the internal Jitsi IP in the local network or edited host file for all internal clients
  • HARVESTER lines are needed for internal clients to access to JVB
  • a custom config for websocket on Apache proxy

Having your TLS connexions terminated outside of the Jitsi server - managing it with Let’sEncrypt for example at your Apache proxy server - is very much doable.
However trying to use 2 different addresses to access the system, one private and one public, don’t seem doable for me. I don’t know how to do it at least. IMO all clients including internal ones must access through the public IP of your router. If your router don’t allow it you are out of luck.

IMO changing apache proxy with nginx which redirects the traffic at stream layer can solve the TLS termination issue

Thank you for all the replies and suggestions. In light of taking baby steps and forgetting about the end goal of Reverse Proxy, after installing Jitsi-meet to a clean Ubuntu 20.04LTS server on my private network, without having done anything else, shouldn’t I be able to at least start a meeting room when presented with Jitsi page? Without having to post links to articles, it appears I’ve read/watched countless tutorials that seem very straight forward. However it doesn’t seem to be the case in my situation. I’m going to blow the whole VM away and again start from scratch. The below parameters will be what I’ll use. Please chime in and make suggestions if you feel the need.

  1. Ubuntu 20.04-LTS Server (clean)
  2. Hostname: jitsi-vm
  3. /etc/hosts
  4. At the Jitsi-meet install host prompt:
    • Enter: jitsi-vm
  5. At the Certificate prompt:
    • Enter: Top choice, use self-signed certificate and setup Let’s Encrypt later ( or something to that effect)
  6. Go to new install by entering in the browser https://IPAddress OR after adding hostname and IP to my desktop’s host file, I can use: OR https://jitsi-vm on within my local network.

This seems to be the overwhelming way the articles and videos have seem to use for a basic no frills install. This should get me a functioning Jitsi server with the ability to create a meeting room and have more than 1 person join, right?

Thanks in advance!

Use FQDN ( during the installation

The address should be


So I started from a clean install. I used FQDN where available and all seem to work! I can access and create meeting rooms on my internal network. Now that I have that up and running, I’ll work on Apache2 Reverse Proxy. I have my Let’s Encrypt Cert in place on my Proxy. I can reach the Jitsi server, just cannot create meeting rooms. Baby steps…:slight_smile:

Is it possible to change apache proxy with nginx in your setup?
This is needed to redirect traffic before TLS handshaking and to terminate TLS at upstreams

hmmm…I suppose it would be possible but I rather not since Apache proxy is being used for other web apps as well. I find Apache to be better for my other apps.

I don’t know if there is a way to do this on Apache. This redirection run before the TLS handshaking

I can’t believe there is no one out there that has been successful in putting Jitsi-meet behind an apache2 proxy. I think I’ve gone 10 pages deep on google looking for a solution. Nothing.

I’m not sure Nginx is an option for me. I’ve got too many resources sitting behind Apache2 proxy to switch now. So close, yet so far away.

So with Nginx, you’re saying this is all I would need on my reverse proxy for a working Jitsi?

Network management is hard. It should be easy maybe, but fact is, it’s not.

FTR I have tried to do something just a bit less difficult (an internet server sharing other servers with Jitsi-meet) and given up on nginx doing the proxying. I use haproxy, and it proxies the basic nginx server on the host and Jitsi-meet installed in a container with other servers in other containers (so I have kind of a NAT too since these containers have only private addresses) . Everything goes through Haproxy except the port 10000/UDP . A web server is not as versatile as a true proxy like haproxy.

if this apache config works (I never tried it) you can put jitsi behind apache proxy after some minor customizations

Okay, I’ve tapped out. I’ve tried for a week for various configurations and just cannot get Jitsi to work with either Apache Reverse Proxy and/or Samba 4 Active Directory LDAP.

Here’s what I did manage to get working…

  1. Jitsi-meet on a dedicated server directly exposed to internet via domain name provider, with an A record DNS setting and Let’s Encrypt cert configured. Basically similar to how it would be set up if I were to use Digital Ocean or similar.
  2. Was able to configure a Secure Domain Jitsi setup with using internal_hash or internal_plain authentication.

I like Jitsi enough to where I’ll have to deal with what I have. With that said, it would be nice to have features so users can manage their own credentials. So when a user would need to change their own password they would be able to do so without and Admin’s intervention. Also, have user profiles persists. So if a user returns to the same meeting room, they don’t have to put in room settings all over again.

I’ve scoured the internet and Jitsi is by far one of the best TRULY Open Source projects available. Most of these social media platform so called Open Sourced initiatives are wolves in sheep clothing only using the term Open Source as a marketing ploy and scheme to attract the unaware. So Kudos to the people behind Jitsi-meet and community for producing such a promising alternative to Zoom, Teams, and the like. From the bottom of my heart, thank you all who contribute to this project..

You should be able to accomplish this with LDAP and AD.

Yes. I know, however I am unable to get it working with my Samba 4 AD controller with TLS. I’ve followed pretty much every source out there and I cannot get it to work. So as mentioned in my previous post, I gave up. I’ve spent the better part of a week trying to configure it. The closest I get is the Authentication screen presents a login. But when putting in credentials it just stalls out with everything grayed out at the login screen.

I can get a working Jitsi with Samba 4 using these steps

Okay, I’ll give this version a try.

Still not working…

So here are my changes taken from the steps provided.


# LDAP Defaults

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE	dc=example,dc=com
#URI	ldap:// ldap://

#DEREF		never

# TLS certificates (needed for GnuTLS)
#TLS_CACERT	/etc/ssl/certs/ca-certificates.crt


VirtualHost ""
    -- enabled = false -- Remove this line to enable this host
    authentication = "ldap2"
    -- Properties below are modified by jitsi-meet-tokens package config
    -- and authentication above is switched to "token"


ldap = {
    hostname = ',
    bind_dn = 'cn=useradmin,cn=users,dc=redacted,dc=redacted,dc=net',
    bind_password = 'redacted',
    use_tls = true,
    user = {
        usernamefield = 'sAMAccountName',
        basedn = 'OU=UF,dc=redacted,dc=redacted,dc=net',
        filter = '(objectClass=User)',

A little about my Active Directory tree.

My users are listed in an Organizational Unit called UF. So I changed my basedn to be reflected of where to find my users.

My results are the same. A authentication page that sits at authentication screen.
Screenshot from 2021-12-10 13-00-14