Docker vs Kubernetes for Self-Hosted Video Conferencing

Most Teams Already Know What They Want to Hear

If you run Kubernetes everywhere, you want video on Kubernetes. If you don't, you want to avoid it. The honest answer is more specific than that, because video isn't like the rest of your workloads.

A web app serves HTTP through an Ingress and scales by adding replicas. A video server moves UDP media straight from every participant's browser to a single videobridge, and holds state for the length of a call. That difference decides most of this comparison. This guide covers Jitsi mainly, with LiveKit as the second reference, and links to our step-by-step guides for the how-to detail.

How to Choose

Four questions decide it faster than a feature list:

1. Is Kubernetes already your platform? If yes, the cost of adding video is mostly the networking. If no, adopting it for one app is a poor trade.
2. How many meetings at once, and how big? Many meetings need more bridges. One huge meeting is a different problem, covered in our 1000-user write-up.
3. Who gets paged? Every option puts operations on your team.
4. Does it have to stay up during upgrades? That decides how much draining and automation you need.

The Real Problem: UDP Media

Two-person calls often work either way, because Jitsi uses peer-to-peer mode for them. So a broken bridge goes unnoticed until the third person joins. Always test with three browser profiles. Kubernetes Ingress exposes HTTP and HTTPS routes, so UDP needs another path in, which is why both Jitsi and LiveKit lean on host networking.

1. Docker Compose: One Host, One File

• Single host
• Simplest to run
• Jitsi has an official stack

Jitsi publishes an official Docker setup, docker-jitsi-meet. It splits the system into containers: the web UI on nginx, Prosody for XMPP, Jicofo as the conference focus, and the JVB videobridge, with Jigasi for SIP dial-in and Jibri for recording as optional extras. One compose file, one host, and you have a working server. Our Jitsi Docker Compose guide walks through it step by step.

• Containers for web, Prosody, Jicofo, and the videobridge, with Jigasi and Jibri when you need them
• Ports to open: 443/tcp for the web UI and 10000/udp for media, plus 20000-20050/udp only if you run Jigasi. UDP 10000 is the one that matters most, because calls simply won't work without it
• Configuration through an environment file, including JVB_ADVERTISE_IPS for NAT and cloud setups
• XMPP stays on an internal network and is not exposed

A note on current releases. Jitsi's Docker docs say that from release stable-11146 on, every service runs as an unprivileged user (uid and gid 1000) with a read-only container filesystem. The directory layout changed with it: you create the storage and tmp directories yourself before the first start, and the containers refuse to start if they are missing or not writable. A new unstable image is also built every day, so pin a release for production.

2. Kubernetes: When Video Is One Workload Among Many

• Cluster
• More moving parts
• Pays off with scale or an existing platform

Kubernetes gives you scheduling, self-healing, and a standard way to roll out upgrades across many nodes. For video it also gives you the hardest networking case in the platform, which we cover in scaling Jitsi videobridges on Kubernetes. LiveKit publishes an official Helm chart for the same reason: it's a common target, and it has sharp edges.

• LiveKit: a Helm chart for GKE, EKS, and DOKS, with host networking and one LiveKit pod per node. LiveKit needs direct access to its media ports (UDP 50000-60000 and TCP 7881, per its ports page), so only one LiveKit pod can run on a given node. It does not support serverless or private clusters, because extra NAT layers suit WebRTC badly
• Jitsi: a Helm chart deployment, with hostPort so the bridge binds UDP 10000 on its node. The jitsi-contrib/jitsi-helm chart is the practical starting point, and its defaults are conservative: replicaCount 1, useHostPort false, useHostNetwork false, useNodeIP false, and Octo disabled. Those are exactly the ones you have to change
• Autoscaling that has to respect live calls, so graceful draining and long termination grace periods
• Redis for multi-node LiveKit clusters that autoscale

A note on graceful restarts. LiveKit's Helm chart sets terminationGracePeriodSeconds to 5 hours, so Kubernetes gives pods enough time to drain active sessions before shutting down. That's an extreme number, and it's there because scale-down is the part that loses calls. The trade is worth stating plainly: draining makes scale-down slow and unpredictable, because you're waiting on people to leave meetings.

3. Plain Instances: The Option People Forget

• Virtual machines
• Autoscaling group
• No orchestrator

Between a single Docker host and a cluster sits a third option: plain virtual machines, with an autoscaling group for the videobridges. It's what our Jitsi scaling on AWS and Terraform autoscaling guides describe, and it's what Meetrix packages as pre-configured images for AWS and Google Cloud. We sell that option, so weigh our view accordingly.

• Each videobridge runs on its own instance, with a public address and direct UDP
• Scaling out and in through the autoscaling built into your cloud
• No container networking layer between the browser and the bridge

A note on scale-in. When an Auto Scaling group removes a bridge that still hosts a conference, that call breaks. The fix is a lifecycle hook that puts the bridge into graceful shutdown and waits for its conferences to end before terminating the instance, as described in our Jitsi scaling on AWS guide. It's the same idea as LiveKit's long grace period, just implemented in your cloud's autoscaling layer.

Docker vs Kubernetes: Side by Side

Descriptions come from Jitsi's and LiveKit's official docs and our own deployment guides. Your cloud, your team, and your traffic shape will change the details.

Scaling Without Dropping Calls

Two scaling ideas get mixed up. More videobridges lets you run more meetings at the same time. It does not make any single meeting bigger, because by default one conference lives on one bridge. In our Kubernetes article we found the usual mistake is scaling to a dozen bridges and still hitting the per-bridge participant cap in one room.

Scaling down is the part that loses calls. A busy bridge sits at high CPU for the whole meeting, which is normal, so a CPU-based autoscaler may remove a pod full of people. The fix is the same on every platform: scale on the bridge's own load signal, tell the bridge to stop taking new conferences, and wait for existing ones to end.

Jitsi exposes a stress metric that Jicofo uses to make allocation decisions. Its default stress threshold is 0.8, and there's an average-participant-stress value that estimates how much load each participant adds to the bridge. On AWS, you can publish that stress level as a CloudWatch custom metric and autoscale on it, which is more accurate than CPU alone. For the Jitsi version, with the configuration, see our Kubernetes scaling guide, Jitsi scaling on AWS, and Jitsi horizontal scaling.

The trade is worth stating plainly: draining makes scale-down slow and unpredictable, because you're waiting on people to leave meetings. You pay for some idle capacity to avoid dropping calls, so video autoscaling saves less money than it does for a stateless web service.

Where I'd Start