This guide is for administrators maintaining an existing Jitsi Meet installation with local host accounts. Authentication controls who may start a meeting; the guest and lobby policies control how others enter. [S2][S5][S7]
For new installations: upstream now marks the older secure-domain method as deprecated and recommends JWT. Read the JWT guide and identity-provider guide alongside current upstream documentation. Do not interpret this page as a recommendation to build a new authentication system around local passwords. [S6]
Reviewed baseline: docker-jitsi-meet stable-11248-2, commit 74d3e6e, source checked on 24 October 2026. The Docker templates still support internal hashed-password authentication. This revision has source and configuration checks, not a completed live login test. [S1][S2]
1. Choose and apply the host policy
Back up the existing project and persistent data first. Use your existing Compose project, environment files, profiles and overlays throughout; substituting a different project can target different containers or storage. Make access changes in a maintenance window. See backup and upgrade preparation. [S1][S9]
For internal accounts with anonymous guests, set these values in the project’s .env: [S2][S5][S8]
ENABLE_AUTH=1
AUTH_TYPE=internal
ENABLE_GUESTS=1The reviewed templates select internal_hashed for the main XMPP host and add an anonymous guest host when authentication and guests are enabled. Setting ENABLE_GUESTS=0 removes that guest route; verify that ordinary participants then need accounts under your actual configuration. [S2][S8]
Recreate changed services with your usual Compose options. For a project normally run without extra options: [S9]
docker compose up -dA container restart alone does not apply changed Compose environment values. This step can interrupt meetings. Check that the containers start successfully before creating host accounts. [S9]
Do not regenerate service passwords to create a host. The release’s password generator replaces internal service credentials; it is not a host-account manager. [S1]
2. Find the active domain and configuration
For this Docker release, startup renders the active Prosody configuration under /run/prosody/config/. The main file is /run/prosody/config/prosody.cfg.lua, and its included site configuration is conf.d/jitsi-meet.cfg.lua. The main XMPP domain defaults to meet.jitsi, which administrators can override. [S2][S3]
Read only the domain and authentication declarations, using the same Compose options as above: [S2][S3]
docker compose exec -T prosody sh -c 'printf "%s\n" "${XMPP_DOMAIN:-meet.jitsi}"'
docker compose exec -T prosody grep -E '^(VirtualHost|[[:space:]]*authentication =)' /run/prosody/config/conf.d/jitsi-meet.cfg.luaConfirm that the main host has authentication = "internal_hashed". With guests allowed, check for the intended guest virtual host as well. Other internal service hosts may appear; do not create meeting users on those domains. [S2]
Do not paste the full rendered configuration or .env into a public issue: they can contain service credentials. If the runtime file is absent, check the installed release and container startup rather than creating an empty replacement. Older Docker instructions may use /config/prosody.cfg.lua; that is not the rendered runtime path in this baseline. [S1][S3]
3. Create a host account without a password in the command
Replace alice with the chosen host username and meet.jitsi with the main XMPP domain confirmed above. Run this interactively, with a terminal attached, and enter the new password when prompted. Do not add -T to this interactive account command. Prosody’s adduser takes a full account JID. [S2][S3][S4]
HOST_JID='alice@meet.jitsi'
docker compose exec prosody prosodyctl --config /run/prosody/config/prosody.cfg.lua adduser "$HOST_JID"Using a prompt keeps the password out of the literal command line and shell history. Avoid posting the resulting account identity or password in screenshots. Account data uses the configured persistent Prosody storage, so an upgrade must preserve that storage as well as the project files. [S1][S3][S4]
To change this account’s password later, use Prosody’s interactive passwd command with the same JID and active configuration: [S4]
docker compose exec prosody prosodyctl --config /run/prosody/config/prosody.cfg.lua passwd "$HOST_JID"Successful account creation does not establish meeting access or moderator permissions. Complete the following checks before inviting users.
4. Test host, guest and lobby access
Use a new, non-sensitive test room name. Keep the host browser and an independent signed-out guest browser separate; a reused authenticated session can hide an access-policy error. The following are acceptance criteria for the intended policy, not results we measured on your server. [S2][S5][S6][S7]
| Check | Expected result |
|---|---|
| Signed-out visitor opens a fresh room | Cannot start the conference without a host |
| Host enters an incorrect password | Authentication fails |
| Host uses the newly created account | Can authenticate and start the test meeting |
| Guest opens the existing meeting with guests enabled | Can join subject to its lobby or password policy |
| Moderator enables the lobby, then a new guest joins | Guest waits for admission; moderator can admit or reject |
| Guest attempts moderator-only actions | Permissions match your intended policy |
| Guests disabled, visitor has no account | Cannot enter through an anonymous guest route |
The UI wording may vary. Check the result rather than relying on the exact text of a button. If an unauthenticated visitor starts a new meeting, keep the server restricted while investigating. If guests become moderators unexpectedly, stop and review Jicofo and any role-assignment modules instead of assuming that login alone provides the desired role split. [S2][S5][S7]
Lobby availability is not automatic admission control. ENABLE_LOBBY=1 enables the feature in the reviewed Prosody template; a moderator normally activates it for a particular room. Test separately configured persistent or token-based policies using their own documentation. [S2][S7]
Meeting passwords protect one meeting and reset after the last participant leaves, according to Jitsi. Private, hard-to-guess room links reduce accidental discovery but do not replace authentication or admission controls. See login, moderator and password prompts. [S10]
Troubleshoot login and guest access
| Symptom | Check before changing anything |
|---|---|
| Account exists but login fails | Exact main XMPP domain, spelling and selected authentication backend |
/config/prosody.cfg.lua is missing or obsolete |
Release-specific runtime path and successful startup |
| New settings have no effect | Same project and overlays; changed containers recreated; active declarations match |
| Guests cannot enter | Guest flag, guest virtual host, web anonymous domain, host presence and room admission policy |
| Anyone can start rooms | Main authentication and Jicofo settings; customized overrides or modules |
| Hosts can log in but lack expected permissions | Jicofo and room role policy; test separately from account authentication |
These checks follow the reviewed Prosody, Jicofo and web templates. Do not publish full configuration or token dumps when seeking help. [S2][S3][S5][S8][S9]
Debian and Ubuntu package differences
Docker environment flags do not configure a package installation. Upstream’s older secure-domain instructions use the main host in /etc/prosody/conf.avail/meet.example.com.cfg.lua, web settings in /etc/jitsi/meet/meet.example.com-config.js, and Jicofo authentication in /etc/jitsi/jicofo/jicofo.conf. Replace the example with your actual host and edit the existing sections rather than duplicating them. [S6]
For an existing package server already configured with internal authentication, account creation uses the configured main virtual host and the package’s normal Prosody configuration: [S4][S6]
sudo prosodyctl adduser alice@meet.example.comChanging the account database alone does not configure the host, guest or Jicofo policy. Package service management and Docker recreation are different procedures. For new deployments, follow the current upstream authentication design instead of copying legacy secure-domain snippets. [S4][S6]
Open questions and maintenance
We checked pinned upstream source, Compose environment propagation and shell syntax. We have not run these interactive account commands or the full host/guest/lobby matrix on a live Jitsi server for this revision. Customized modules, SSO, recording users and older releases need separate checks.
Recheck after Docker runtime-path changes or upstream authentication updates. Plan migrations away from deprecated authentication as a separate task with account, role, guest and recovery tests. Continue with the security checklist for port exposure and credential handling.
Sources
Checked 24 October 2026 unless pinned.
- [S1] Docker release stable-11248-2, Compose file and password generator: environment, mounts and service credentials.
- [S2] Pinned Prosody site template: internal authentication, main and guest domains, lobby support.
- [S3] Pinned Prosody startup and main template: rendered configuration and data paths.
- [S4] Prosody prosodyctl documentation and creating accounts: account JIDs, interactive adduser/passwd and configuration selection.
- [S5] Pinned Jicofo template: authentication selection and domain.
- [S6] Jitsi secure domain, deprecated and current authentication guidance: status, package paths and migration direction.
- [S7] Pinned lobby module, Jitsi Meet 11248: room admission and moderator checks.
- [S8] Pinned web system configuration: authenticated and anonymous domains.
- [S9] Docker Compose up and restart: recreation and changed environments.
- [S10] Jitsi security and privacy: room-link handling and password lifetime. Its public-service policies differ from self-hosted defaults.
For help reviewing your access policy, contact our engineers.