Hosting a Jitsi

∞ 2021-03-07

After having a few times of not-quite-working video in the main https://meet.jit.si instance, I had a try at hosting it myself.

(I am always on a mobile 4G connection, which… makes such things interesting.)

My server runs Caddy for the web server, which then proxies to a little congregation of services running behind it.

Originally I looked at the jitsi-meet AUR package, but it seemed a bit too cumbersome, so I went with docker-compose.

Following the instructions at https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker mostly worked, but there were a few snags:

ENABLE_LETSENCRYPT=1 did not work for me, so I used Caddy to handle that part

I thus did not want to expose port 8443, so I hid it:

diff --git a/docker-compose.yml b/docker-compose.yml
index 23340cd..88f9815 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -7,7 +7,7 @@ services:
         restart: ${RESTART_POLICY}
         ports:
             - '${HTTP_PORT}:80'
-            - '${HTTPS_PORT}:443'
+            #- '${HTTPS_PORT}:443'
         volumes:
             - ${CONFIG}/web:/config:Z
             - ${CONFIG}/transcripts:/usr/share/jitsi-meet/transcripts:Z

In addition, I enabled authentication so an account and password is required to start new meetings.

As for Caddy, I am using the following configuration:

your-domain-here {
  header /libs/*.js Cache-Control "public, max-age=604800, immutable"

  request_header -Cache-Control

  reverse_proxy localhost:8000
}

Note the Cache-Control header manipulation: I could not get Jitsi to enable caching for everything on its own, so I am having Caddy do it. I could probably cache more resources, but the JavaScript files are the heavy ones (>1mb) and make things fast enough for now.

And that’s it! You now have a working Jitsi setup!

Is it working better though?

Maybe. Subjectively yes, but the video will still not update sometimes for a bit while it catches up to the network.