How to secure a self-hosted Jitsi Meet server

This is a checklist for administrators of their own Jitsi server. It covers the settings that matter most, in order, with the Docker setting first and the Debian package equivalent where it differs. It is not a full security audit of your environment.

Applies to: docker-jitsi-meet stable-11248 (the latest release as of 2026-10-11) and Debian/Ubuntu packages of the same release.

The checklist

1. Stay on a current release

Every Jitsi security advisory so far was fixed in a later release. These are the published GitHub advisories for the Jitsi projects, checked on 2026-10-11:

Check what you run with docker compose images (Docker) or dpkg -l | grep jitsi (packages), and upgrade with the matching release files: upgrading docker-jitsi-meet. Releases since stable-11146 also run every container as an unprivileged user with a read-only filesystem, which limits what a compromised container can do; see the rootless upgrade.

2. Use strong service passwords

Jicofo, the videobridge, Jigasi and Jibri log in to Prosody with internal accounts. Before April 2020, docker-jitsi-meet shipped them with the default password passw0rd, so anyone could log in as a system account. That is CVE-2020-11878, rated 9.8 critical, fixed in stable-4384-1.

Current releases ship no passwords at all. A service whose password is empty stops with a line like:

FATAL ERROR: Jicofo auth password must be set

Generate strong random passwords once, in the docker-jitsi-meet folder, before the first start:

./gen-passwords.sh

It writes openssl rand -hex 16 values into .env and keeps a backup in .env.bak. Do not reuse these passwords anywhere else, and keep .env out of version control.

3. Decide who can create meetings

By default anyone who reaches your server can create a room. To allow only signed-in users to start meetings while guests can still join them, set in .env:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

AUTH_TYPE can also be jwt or ldap. Step-by-step setups:

• Username and password (secure domain)
• JWT tokens from your own app
• LDAP and Active Directory
• Keycloak, Entra ID and other OIDC providers

Recreate the stack after changing .env with docker compose up -d. On Debian packages, follow the same guides; they cover the package configuration.

4. Keep admin interfaces private

docker-jitsi-meet publishes the Jicofo REST port (8888) and the videobridge colibri port (8080) only on 127.0.0.1, so they are reachable from the server itself but not from the internet. Keep it that way: do not change those port mappings to 0.0.0.0, and if you need them for monitoring, reach them over a private network or a tunnel. Our monitoring guide explains what they expose.

Leave the Jigasi REST API off (JIGASI_ENABLE_REST unset) unless you need it. A security researcher reported to 8x8 that an exposed, unauthenticated Jigasi REST API can be used to place outbound SIP calls (toll fraud); the report was closed as informative and a hardening pull request was not merged (docker-jitsi-meet PR #2320). If you do enable it, never publish its port.

5. Open only the ports Jitsi needs

Block everything else in your firewall and in your cloud provider’s security group. Prosody’s XMPP ports are not published by docker-jitsi-meet and do not need to be reachable from outside.

6. Turn on Prosody rate limits

docker-jitsi-meet can limit how fast a single IP address may log in and join, which slows down room-flooding and password guessing. It is off by default. In .env:

PROSODY_ENABLE_RATE_LIMITS=1

That loads Prosody’s rate_limit and muc_rate_limit modules with these defaults, each adjustable:

Test with a few real users afterwards: if many people join from one office address at once, they share one IP.

7. Serve only HTTPS

Use a valid certificate (Let’s Encrypt setup). Browsers block cameras, microphones and screen sharing on insecure pages anyway. docker-jitsi-meet sends a Strict-Transport-Security header by default (ENABLE_HSTS=1); leave it on.

8. Protect individual meetings

These are tools for organizers and moderators, on any server:

• Lobby: participants wait until a moderator admits them. The feature is available in docker-jitsi-meet by default (ENABLE_LOBBY); a moderator turns it on for a meeting.
• Meeting password: set by a moderator for one meeting. Jitsi notes that it is reset once the last person leaves, so set it again for the next meeting.
• Room names: use long, unusual names; short common names are easy to guess.
• Participant limit: MAX_PARTICIPANTS in .env caps how many people can join one room.
• End-to-end encryption (E2EE): media is always encrypted on the network with DTLS-SRTP, but the videobridge decrypts it in memory to route it. With E2EE turned on in a meeting, the bridge cannot read audio, video and screen sharing. According to Jitsi, E2EE does not cover chat or polls, and it only works when every participant uses a client that supports it.

More on what participants see: login, moderator and password prompts.

Verify

On the server:

docker compose ps --format '{{.Name}}\t{{.Ports}}'

Only the web ports and 10000/udp should be bound to 0.0.0.0; Jicofo’s 8888 and the videobridge’s 8080 should show 127.0.0.1. Then, from another machine:

curl -sI https://meet.example.com | grep -i strict-transport-security

It should print a Strict-Transport-Security line with max-age=63072000. Finally, open a new room name in a private browser window: with ENABLE_AUTH=1 you are asked to log in or wait for a moderator instead of starting the meeting.

Common mistakes

• Changing .env without recreating containers. Run docker compose up -d after every change.
• Reusing one password for every service or committing .env to a repository.
• Opening 8080 or 8888 “temporarily” for monitoring and forgetting to close them.
• Treating a meeting password as permanent. It resets when the room empties.
• Skipping upgrades for months. Most items in the advisory table were fixed in ordinary releases.

What we have not confirmed yet

• We took the defaults and settings from the stable-11248 source; we have not yet run every check above on a test server, including the rate limit behaviour with many users behind one IP.
• Fixed versions marked “See advisory” are listed on the advisory page itself; we did not repeat them here.
• This checklist does not cover your operating system, cloud account, backups or monitoring for intrusion.

Sources

• NVD: CVE-2020-11878, published 2020-04-17, CVSS 9.8, official vulnerability record
• docker-jitsi-meet commit a015710 “security: don’t provide default passwords”, 2020-04-06, source code
• GitHub security advisories for jitsi-meet, docker-jitsi-meet, lib-jitsi-meet, jitsi-videobridge and jigasi, checked 2026-10-11, official advisories
• NVD: CVE-2025-64754, published 2025-11-13, official vulnerability record
• docker-jitsi-meet at stable-11248: env.example, gen-passwords.sh, docker-compose.yml (port mappings, environment), the Prosody template prosody/rootfs/defaults/conf.d/jitsi-meet.cfg.lua (rate limits, lobby, auth defaults) and web/rootfs/defaults/ssl.conf (HSTS), source code
• docker-jitsi-meet PR #2320, Jigasi REST binding, closed unmerged, 2026-09
• Jitsi: Security & Privacy (DTLS-SRTP, E2EE scope, meeting passwords), official page, checked 2026-10-11

Need a hand?

Want a second pair of eyes on your server? Contact our engineers for a hardening review, or see our support plans.