Jitsi Meet Setup Guide: Self-Hosted Webinars

Jitsi Meet is one of the best-known self-hosted video conferencing platforms because it offers a practical balance of openness, usability, and control. For organizations that want to run meetings or webinar-style sessions on infrastructure they manage, Jitsi is often the first serious option to evaluate.

The appeal is obvious. You get browser-based video meetings under your own domain, without locking the whole experience to a commercial vendor. That matters for privacy-sensitive teams, educational organizations, community groups, and technical operators who want more control over branding, access, and data boundaries.

The first thing to understand is that “webinar” on Jitsi usually means using a meeting platform in a webinar-like way, not necessarily replicating every feature of a dedicated enterprise webinar product. Jitsi can absolutely support presentations, moderated sessions, internal events, and many audience-facing calls. But your success depends on matching the setup to the size and style of the event.

A practical Jitsi deployment plan should cover:

• domain, DNS, and HTTPS
• CPU, memory, and network capacity for expected participant counts
• authentication or room access controls
• moderation rules for presenters and attendees
• recording or streaming requirements if needed

The infrastructure question is the one most people underestimate. Video is not like hosting a wiki or dashboard. Real-time media is sensitive to bandwidth, latency, and scaling behavior. A tiny VPS may work for small internal meetings, but not for a public event with many attendees. If your webinar matters, capacity planning matters too.

Jitsi’s architecture includes components for signaling and media routing, and that architecture rewards operators who actually read the deployment guide instead of guessing. The software is approachable, but it is still a real communications system. NAT behavior, firewall rules, TLS, and relay configuration can all affect quality.

Installing Jitsi Meet with Docker

The fastest reliable path is the official docker-jitsi-meet stack. It packages the four core services in one Compose project: the web front end, Prosody (XMPP signaling), Jicofo (the conference focus that assigns rooms to bridges), and the Jitsi Videobridge (JVB), which routes the actual media. The same habits that apply to any production Compose stack apply here, so it is worth following Docker Compose best practices from day one.

Point a DNS A record like meet.example.com at your server, then grab the latest stable release:

git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet
cp env.example .env
./gen-passwords.sh   # writes strong internal service secrets into .env
mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}

Open .env and set the values that matter. For a webinar-style deployment where hosts authenticate and attendees join as guests:

PUBLIC_URL=https://meet.example.com
HTTP_PORT=80
HTTPS_PORT=443
ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.com
LETSENCRYPT_EMAIL=you@example.com

# Hosts log in, attendees join as guests
ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

# Required if the server sits behind NAT
JVB_ADVERTISE_IPS=203.0.113.10

Start the stack, then register at least one host account inside the Prosody container:

docker compose up -d
docker compose exec prosody prosodyctl --config /config/prosody.cfg.lua \
  register host meet.jitsi 'a-long-passphrase'

Note the domain in that command is meet.jitsi — the internal XMPP domain the Docker setup uses — not your public hostname.

On the firewall, open TCP 80 and 443 for the web interface and certificate issuance, and UDP 10000 for JVB media. That UDP port is not optional; it is where every multi-party call’s audio and video actually flows.

First run: open your PUBLIC_URL, start a room, and log in with the host account when prompted. Then test a guest join from a private browser window and a phone on mobile data, not just from your LAN.

The classic gotcha: two-person calls work perfectly, but the third participant joins and everyone loses audio and video. That happens because 1:1 calls use direct peer-to-peer WebRTC, while three or more participants route through the JVB. If UDP 10000 is blocked or JVB_ADVERTISE_IPS is missing behind NAT, the bridge is advertising an address nobody can reach. Fix the advertised IP and the firewall rule and the problem disappears.

Sizing for real events

The JVB is the component that scales with attendees, and it is mostly CPU and bandwidth bound. A 2 vCPU / 4 GB VPS handles small team meetings comfortably. For webinar-style sessions with a few dozen attendees, 4 vCPU / 8 GB is a more sensible floor, and outbound bandwidth is usually the first real ceiling — budget roughly a few Mbps per active video participant. Watch CPU and network on the host during rehearsals; a basic server monitoring setup tells you before event day whether the box is undersized.

For webinar-style use, moderation is critical. Decide whether rooms are open by default, whether only authenticated hosts can create meetings, and how participants join. If the event is public-facing, define the presenter flow in advance. Who admits users, who controls screen sharing, who mutes participants, and what is the fallback plan if the main host drops? These are operational questions, not just software settings.

Recording and streaming are also worth thinking through before launch. Some teams only need live participation. Others need a replay or a stream to another platform. Jitsi can support broader workflows, but each additional feature adds operational complexity. Start with the minimum viable event design rather than enabling every option because it sounds useful.

Security should not be an afterthought. Video platforms can attract abuse, especially if room names are predictable or access is too open. Use strong room management habits, secure the administration surface with the same care you would apply to any other internet-facing service, keep the system updated, and avoid treating a meeting domain like a throwaway experiment. If the service becomes important for your organization, it deserves production discipline.

Another reality check: not every organization should self-host video. If you rarely run events and do not have the skills or time to maintain a real-time communications stack, a hosted solution may be more sensible. Self-hosting makes the most sense when control, branding, privacy, or cost over time clearly outweigh operational burden.

My recommendation is to use Jitsi Meet for self-hosted video when you want a flexible platform for meetings, workshops, training, or webinar-like events and you are willing to plan capacity and moderation seriously. Start with small internal sessions, confirm performance on your actual infrastructure, and document the presenter workflow before running a bigger event. Jitsi can work very well, but it rewards preparation more than improvisation.

The real strength of Jitsi is that it gives you communications infrastructure you can understand and shape. That is powerful. But video systems are unforgiving when underplanned. Treat the platform like an event service, not just another container, and you will get much better results when real participants show up expecting the call to simply work.

One more practical tip: rehearse with the same device mix and network conditions you expect on event day. Test host audio, screen sharing, guest joins, moderation, and fallback communication if someone cannot connect. Webinar problems are often less about software bugs than about untested presenter habits. A short rehearsal turns a technically valid deployment into a much more reliable event platform.