loading . . . How To Self-Host Jitsi Meet For Audio (or Video) Calls If you just want to have video chat (and optionally a text chatbot helper), then using the public instance of Jitsi is easy to set up and has plenty of features. The big advantages of using the public instance of Jitsi are that it’s EXTREMELY simple, allows telephone call-ins, and that you don’t have to worry about total upstream bandwidth.
The downside is that because of the way the public instance does load balancing, that these simpler bots may (and probably will not) work on the public instance. On a public instance, adding in a separate audio stream for music or a soundboard or recording streams requires (effectively) running a whole other headless browser session for _each_ stream.
It’s possible to use virtual microphones (or OBS) to mix in a soundboard or music stream on top of an existing speaker’s audio stream. However, OBS is not a _lightweight_ application, and dumping extra audio into an existing speaker’s audio means that others cannot independently adjust it, problems with sound “ducking” from noise cancellation, and more.
My use case — audio-only calls and recordings for preservation and to use when writing recaps — happens to work well within the resource limits that I (and probably you) have. And because Jitsi Meet itself is just a forwarder, I can run it on the laptop already running NextCloud. Not only does this give us more control over everything, but it allows the usage of those lighter javascript bots.
Estimated time: Approximately 30-45 minutes, mostly cut-and-paste into configuration files. More if you need to install and configure a reverse proxy before beginning.
## Before You Begin
Take a look at my bandwidth comparisons/estimates for audio and video _egress_ for Jitsi and make sure your upload speed can handle the demands. This is the **single most important consideration** … unless you add on other optional services. Because of my bandwidth and how my group works, I’m restricting it to audio-only. If you want the default video options, I’ll tell you what NOT to change below as well.
## Getting Started
### Get A Separate Subdomain
The other big consideration is that you will need to be able to route traffic to the right place. You will need to obtain a separate subdomain name — the same process as you used for getting a DNS name from the NextCloud guide will work perfectly — regardless of which solution applies to you below.
I am going to presume for this _that you already have a reverse proxy_ set up, but I will also show how to configure things if you do not use or want one.
Here’s an explainer about what a reverse proxy is, and a quickstart for nginx and caddy.
See also Weekend Project: How To Replace Discord With Free Software And An Old PC
#### If you already have a reverse proxy
If you have a reverse proxy already in place, this is relatively trivial and I’m assuming you know how to add a forwarder to whatever you’re using. An example nginx config is available. Continue to “Setting up Jitsi Meet” below.
#### I don’t have a reverse proxy, and I now want one.
This is medium-difficulty, but is the cleanest and best way.
You’ll need to switch some things about your NextCloud AIO setup. From the Administration settings inside NextCloud, first click `Open Nextcloud AIO Interface` and then `Stop Containers`. Let that finish.
Open a terminal where your `docker-compose.yaml` file lives. If following my guide: `cd $HOME/apps/nextcloud`. Now stop and purge the mastercontainer (which will NOT delete your data):
sudo docker stop nextcloud-aio-mastercontainer
sudo docker rm nextcloud-aio-mastercontainer
In your docker-compose.yaml file, open your editor and add these under `environment:`:
APACHE_PORT: 11000
APACHE_IP_BINDING: 0.0.0.0
APACHE_ADDITIONAL_NETWORK: ""
You can also optionally remove **ONLY** the _entire_ lines under `ports:` that begin with:
- 80:80
- 8443:8443
Close your editor, and bring everything back up: `sudo docker compose up -d`
While all the containers spin back up, take that time to set up your reverse proxy to point at port 11000 for NextCloud. I personally use nginx, and there is an example config in my guide ready to have Let’s Encrypt run on it, as well as the example nginx config for Jitsi Meet here.
Continue to “Setting up Jitsi Meet” below.
#### I don’t have a reverse proxy, and I don’t want one.
This is the quick-and-dirty-but-it-is-running-NOW solution.
If you do _not_ have a reverse proxy and do not _want_ a reverse proxy, that can work by specifying a port for Jitsi to use. We are going to assume `8444` here. Separate guides may suggest using `8443`, but that is already being used by NextCloud AIO. **You will still need that separate subdomain.**
Continue to “Setting up Jitsi Meet” below.
## Setting Up Jitsi Meet With Docker
Because we already have Docker set up and running from setting up NextCloud, the official instructions work pretty much out of the box, although we’re going to tweak them and the order we do them in for clarity.
Back to the terminal! We are going to change to our user’s apps directory, create required directories, and download the program files for Jitsi Meet:
cd $HOME/apps
wget $(wget -q -O - https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep zip | cut -d\" -f4) -O latest_jitsi_meet.zip
unzip latest_jitsi_meet.zip
rm latest_jitsi_meet.zip
ls -d /*
The last shows you what directories exist here; there should be your `nextcloud` directory and one that begins with `jitsi-docker-jitsi-meet`, for example `jitsi-docker-jitsi-meet-35879bb`. Move into that directory: `cd jitsi-docker-jitsi-meet-35879bb`
We’ll create some mandatory directories:
mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}
We will also copy the example configuration: `cp env.example .env`
And then we will let a helper script generate some strong internal passwords for the .env file: `./gen-passwords.sh`
### Editing Jitsi Meet’s Configuration
Use your editor of choice to open `.env`. These are the entries to change, **and why** :
See also Comparing Jitsi Meet And NextCloud Talk For Replacing Discord's Calls
#### If using a reverse proxy
# If you are using a reverse proxy, alter these lines:
# We are going to use 8444 so the port forward instructions
# are the same
HTTP_PORT=8444
# Comment out this line with a hash mark like so:
# HTTPS_PORT=8443
# Your PUBLIC_URL line should NOT have the specified port
# at the end, like so:
PUBLIC_URL=https://meet.example.com
# Turn off Let's Encrypt certificate generation, HTTPs, etc. That is all handled
# by the proxy.
ENABLE_LETSENCRYPT=0
DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
Continue to “Everybody Change these”
#### If NOT using a reverse proxy
# If you are NOT using a reverse proxy,
# put a hash sign in front of the HTTP_PORT line.
# If Jitsi complains that it is commented out,
# change it to something random you
# are not going to use.
# HTTP_PORT=8000
# Change HTTPS_PORT 8444
HTTPS_PORT=8444
# For the PUBLIC_URL line,
# put your domain, but also make sure
# it has the ${HTTPS_PORT} at the end.
PUBLIC_URL=https://meet.example.com:${HTTPS_PORT}
# Change these lines to enable Let's Encrypt, have HTTPS working, and
ENABLE_LETSENCRYPT=1
DISABLE_HTTPS=0
ENABLE_HTTP_REDIRECT=0
Continue to “Everybody Change these”
#### Everybody change these
> **IMPORTANT** : If your public IP address changes, for example, if your modem resets, you will need to change the public IP address in this file manually, then bring the containers down _and rebuild them_.
> `docker compose down && docker compose up -d --force-rebuild`
We are going to fill in our public and LAN IP settings:
# Media IP addresses and ports to advertise by the JVB
# This setting deprecates DOCKER_HOST_ADDRESS, and supports a comma separated list of IPs
# PUT BOTH YOUR PUBLIC AND LAN IP ADDRESS HERE.
# JVB_ADVERTISE_IPS=74.111.11.111,192.168.1.5,
JVB_ADVERTISE_IPS=
We will use the TURN server from NextCloud AIO. The TURN_HOST is the domain of your NextCloud AIO instance, you get the TURN_CREDENTIALS from the Turn Server Secret in NextCloud Talk’s settings.
# Enable Turn
TURN_HOST=example.com
TURN_PORT=3478
TURN_TRANSPORT=udp,tcp
TURN_CREDENTIALS=biglongstringofstuff
Jitsi is set up to be open by default. Which I don’t have a problem with, except for that whole _bandwidth_ thing… so we’re going to require authorization to _create_ a room, but anybody can join an existing room as long as there’s an authorized user already in it.
# Enable authentication
ENABLE_AUTH=1
# Enable guest access
ENABLE_GUESTS=1
# Select authentication type: internal, jwt, ldap or matrix
AUTH_TYPE=internal
These are some changes to hide video user interface elements, since we are only doing voice calls. If that is not your use case, save the configuration file and skip to “Port Forwards.”
TOOLBAR_BUTTONS=microphone,hangup,chat,participants-pane,invite,profile
HIDE_PREMEETING_BUTTONS=camera,select-background,invite
ENABLE_LOBBY=0
ENABLE_PREJOIN_PAGE=1
ENABLE_WELCOME_PAGE=1
Save the configuration file.
See also Use Your Homelab and Selfhosting Skills For Good
We’re going to _also_ define those same restrictions elsewhere for redundancy. I also put in a resolution restriction of 320px just in case someone still turned on their camera so it won’t immediately clobber the bandwidth. Create and edit the file `${HOME}/.jitsi-meet-cfg/web/custom-config.js` and put this in it:
config.startAudioOnly = true;
config.startWithVideoMuted = true;
config.resolution = 320;
config.toolbarButtons = [
'microphone',
'camera',
'chat',
'invite', // invite button explicitly enabled
'profile',
'participants-pane',
'hangup'
];
Save that file as well.
### Port Forwards
This is going to be radically different depending on the make, model, and software your modem/router is using. Here’s an existing guide which covers many varieties.
You will need to forward port 10000/udp to the computer you’re installing Jitsi Meet on, regardless if you are using a reverse proxy. If you are using a reverse proxy, it will handle everything else.
If you are _not_ using a reverse proxy, additionally forward port 8444 tcp/udp (or whatever port if you chose something different above).
### Bring It Up And Secure It
Change back to the directory where your `docker-compose.yml` file is, and type `docker compose pull && docker compose up -d && docker compose logs -f` to let you see the logs. It should reach a steady state without errors; once it has, press Ctrl-C to get out of the logs.
I only created myself as an authorized user; _you only need to have the people who are creating or moderating rooms to be authorized._
> _IMPORTANT_ : TheDesiredUsername should be JUST a username; for example, `bob` instead of `bo*@*****le.com`
The commands below will enter the loaded Docker container, create `TheDesiredUsername` with password `TheDesiredPassword`, then show you a list of all registered users, then exit. Do **NOT** change `meet.jitsi` in the block below.
docker compose exec prosody /bin/bash
prosodyctl --config /config/prosody.cfg.lua register TheDesiredUsername meet.jitsi TheDesiredPassword
find /config/data/meet%2ejitsi/accounts -type f -exec basename {} .dat \;
exit
You’re done! If you’re using a reverse proxy, you should see the Jitsi welcome screen if you go to just the URL. If you chose to not use a reverse proxy, you will always need to put the port at the end: `https://meet.example.com:8444`
You probably noticed that there are quite a few other features that you can enable here: a recording component, a transcribing component, a whiteboard, collaborative documents, and so on. I have _not_ enabled them because we have them handled through NextCloud already or they put a non-trivial load on the system. Recording and transcription, _especially_ if you are using video, will require much beefier hardware than the decade-old laptop everything else is running on.
Next I’ll do a full overview of the bots — including how to get per-speaker split recording — with your self-hosted Jitsi instance.
Featured Image by Alexandra_Koch from Pixabay https://ideatrash.net/2026/03/how-to-self-host-jitsi-meet-for-audio-or-video-calls.html
