When I asked my friends and family which video chat service we should connect on, the most common suggestion I got was Zoom. But many people have been writing about all the security and privacy issues with Zoom, and when I tried to used it for board games via video I was limited by the 40 minute meeting maximum for free accounts. So I started looking for alternatives.

My search criteria mostly involved something that I could host myself, and not worry about bandwidth issues at times of high traffic, or what another company might be doing with my video chat data.

I discovered there’s an open source solution called Jitsi. They describe themselves as “Multi-platform open-source video conferencing”, which is pretty much what I was looking for. They also have free service where you can start a meeting with an autogenerated, easy to dictate phrase, which should make it simple for people to join. They also specifically call out their security in a recent blog post.

Self-hosting Woes

So you want to host your own video chat app? Well I hope you have some really fast home internet that can handle many video streams. My ISP only supports 3-4 megabits per second upload, which will not be enough for multiple high quality video streams. Also, for the last few years I don’t really have a machine sitting around that I can serve from, I’ve been exclusively laptop based for awhile now.

So I knew that I would have to look to one of the many cloud providers to do my hosting. For Jitsi, I found some instructions for AWS but the instructions didn’t really come across as something I could be up and running quickly with, even as a professional software engineer. I also found a quickstart for Docker which was very easy to follow considering I use Docker in my day-to-day job.

I also was trying to get the pricing right, close to the cost of paying a third party video chat service, and I perceive AWS as more expensive than other providers. However, I might be wrong on this, I didn’t want to spend too much time optimizing pricing, which is very complicated for cloud hosting. I can’t imagine an individual would use this as it costs more than many solutions out there and requires more work, but it seems reasonable for a privacy conscious organization with an IT department to spin up their own cost effective version in house or in the cloud.

I ended up choosing Google Cloud Platform because I had some experience with it on a side project, and also because they have an “always free tier” where you can freely host low resource web applications. For Jitsi, the video bridge needs more resources but the rest of the components’ requirements were low. I should be able to get away with f1-micro for web/xmpp/focus, and n1-standard for the video bridge.

Jitsi on Google Cloud Quickstart

So I decided to take the Docker instructions, and get them running on Google Cloud Platform using their Deployment Manager configuration tool. The documentation is generally good, but it requires lots of trial and error to get everything configured correctly for single-command deployment.

Step 1. Get It Running

The first step in the process was just to get it running in the cloud. I spent a few hours creating instances in their console UI, configuring it just right, mostly fighting with communication between the 4 servers that make up a baseline Jitsi installation. One of the goals here was to minimize cost, so I tried to do it without adding DNS or load balancing cost overhead.

Step 2. Convert to Deployment Manager

After I got it running then I had to take that configuration and translate it to YAML files for Google Deployment Manager to run. This took another several hours over several days to get just right. Even though there is a link to see the configuration in JSON format it’s not always clear what is default/required/important that deployment manager will choke on. The feedback loop was also really slow because bringing up and taking down machines takes a few minutes of time. I discovered the “preview” mode pretty late in the process which saved me a bunch of debugging time. Trickiest part was trying to get the container yaml config to work as a template, which I couldn’t figure out with pure yaml so I had to write that in Python.

Step 3. Profit Expenses!

Once I got it working then I had to remove all traces of my personal information and put it up on Github for all to enjoy.

End Result

The end result is a project you can pull down from Github and get running in a few minutes. I spent the time configuring this thing so you don’t have to.

Check it out if you’re so inclined:

Jitsi on Google Cloud Platform

The grand total estimate if you run it 24/7 turned out to be $22.26. But since the command to take it down is just a one line in deployment manager, you can spin it up when you need it and take it down just as easily. Since everything is container based and configured to delete the drives when taking down the VMs, nothing will be saved.