Self-hosting a video chat system

Since the pandemic began, I’ve been mostly unable to hang out with my friends in the real world. Everyone has switched to various video chat services, such as Zoom and Google Meet. I wanted to see what it would take to host my own video chat service, for privacy as well as just general interest in the subject.

What choices are out there?

  • Wire: open source, security-focused messenger system
  • eduMeet (and other mediasoup-based solutions): open source, web-based video chat system
  • Zipcall: open source, web-based P2P video chat system
  • Jitsi Meet: open source, web-based video chat system
  • Probably many others…

It certainly appears that there is no shortage of possible solutions to choose from, but I had specific hard and soft requirements that ultimately helped me to select one. I wanted a system that was easy to set up, which (at the time anyway) eliminated Wire. I needed to support more than two people in a video call, so Zipcall was not an option. I wanted some integration with an authentication/authorization system, so eduMeet was not a great fit. Thus, Jitsi Meet was chosen.

The hosting situation

I have a Virtual Private Server (VPS) hosted at TurnKey Internet (note: affiliate link). I personally prefer a VPS to cloud providers such as Azure and AWS for multiple reasons. First, there’s general ease of use: I essentially get a virtual machine to do with as I please. There are no complicated billing arrangements, no arcane codenames and barely-comprehensible descriptions for various services, and it’s generally a very streamlined setup. Second, there’s cost. While I can afford cloud hosted solutions, I don’t want to pay more than I have to. Additionally, if I accidentally start some heavy workload on the VPS, the worst that could happen is I get notified that I’m using too many shared resources, whereas I could get charged a significant amount of money on a cloud-hosted solution in a similar situation. Finally, VPSes are often offered by small businesses, rather than giant corporations, so I feel better about using them and supporting such small businesses.

Getting back on topic, I decided that I wanted to have as much as possible hosted in Docker on my VPS. I didn’t want to set up a complicated environment (certainly no Kubernetes), but I wanted some amount of isolation between the host system and the applications that would live in it, so a plain Docker system seemed like a good idea. To help with managing it, I installed Portainer. For accessing the management side of the system securely via SSH as well as the Portainer web interface, I chose to go with a ZeroTier virtual network, so that I don’t have to expose any unnecessary ports directly to the internet.

Installing and configuring a Jitsi Meet instance

Thankfully, Jitsi has official support for Docker. It’s almost trivial to get started with the docker-jitsi-meet project. Just clone the repo (or download the latest release), customize the .env file, and run docker-compose to bring up the services. More in-depth instructions are available from the linked GitHub repo.

Screenshot of Portainer web interface showing Jitsi Meet containers
Portainer’s view of the containers that make up Jitsi Meet

My changes to the .env file included the usual required ones, such as setting the URL, ports, and the config directory, in addition to enabling LDAP along with guest access: this way, an authorized user must start a meeting, but anyone can join it — assuming they know the meeting URL and, optionally, a meeting-specific password. I set the LDAP filter variable such that it would ensure the user is in the Jitsi Meet group before granting access, like so:

LDAP_FILTER=(&(cn=%u)(memberOf=cn=jitsimeet,ou=groups,dc=example,dc=net))

Once the Jitsi Meet instance has launched, the config directory will have a number of subdirectories and files under it. To customize the Jitsi web application, edit $CONFIG/web/config.js and $CONFIG/web/interface_config.js. The former file has server-centric configuration items, such as maximum resolution constraints and the ability to enable or disable P2P mode when there are only two users present. The latter file addresses more UI-centric concerns, such as whether to display the Jitsi logo and the layout and size of thumbnails. I modified these based on what I thought worked best, as well as some feedback from people using the system. To see interface changes, you can just reload the Jitsi web page. For the other file, you have to restart the web container. Once you have your instances running and customized, you can start using Jitsi Meet via a web browser or the Jitsi Meet phone apps!

Screenshot of Jitsi Meet welcome page with intro text and a textbox for starting a new named meeting
A Jitsi Meet welcome page

Final thoughts

Setting up a basic Jitsi Meet instance is pretty simple. I glossed over some details for my specific setup, such as Docker networking shenanigans to let Jitsi containers talk to the LDAP server container and VPS/hosting setup intricacies (firewall configuration, ZeroTier installation and usage), but those are ancillary topics. I could write up more detailed information on those subjects later on if people are interested.

Up next: self-hosting a video streaming system for virtual movie nights…