jitsi.help
Talk to an engineer

Prosody cannot load auth_token after a Jitsi Docker update

By Jitsi Help engineering teamUpdated View as Markdown

Short answer

If Docker Jitsi stable-11248-1 logs module 'inspect' not found while loading auth_token, compare the error and image version with upstream issue #2346. The stable-11248-2 release restores the missing dependency. Plan a matched-release upgrade and verify moderator and guest access afterward; an arbitrary login failure is not proof of this regression. [S1][S2]

Identify the exact failure

This guide covers a specific Docker regression, not every moderator or JWT login error. The reporter upgraded from stable-11248 to stable-11248-1, then found that Prosody plugins required Lua’s inspect module although that image no longer installed it. A maintainer confirmed that the corresponding removal from Meet source was not in the stable release and subsequently linked stable-11248-2. [S1]

Distinguish these symptoms:

Observation Next check
module 'inspect' not found while loading auth_token on stable-11248-1 Compare with this regression and the corrected release
Prosody cannot find its configuration file Use the separate configuration-path guide
A JWT is rejected without the missing-module error Follow JWT diagnostics
Video fails only when a third participant joins Investigate the media bridge path separately

Do not infer that a public meeting service or every package installation is affected because the Docker issue exists.

Check your deployment before changing it

First record the actual images and versions. On the Linux Docker host, run these with your existing Compose project, file list and environment options:

Terminal
docker compose images prosody
docker compose logs --no-color --tail=100 prosody

Read logs locally. For a public report, share only the relevant missing-module error and release information, after removing tokens, user identifiers and private meeting details. A tag written in a new .env file is not proof that the running container uses that image.

If Prosody cannot stay running, a failed exec command only confirms that there is no available running process to enter. It does not establish another Lua or authentication cause.

Use the corrected release as a matched deployment

As reviewed on 25 October 2026, stable-11248-2 explicitly includes Revert “chore(prosody): drop lua-inspect”. Its pinned Dockerfile installs lua-inspect and moves the Lua module into the Lua 5.4 directory. These release and source changes support a released correction for the reported missing dependency. [S2][S3]

Follow the Docker upgrade and rollback workflow: preserve existing secrets, configuration, project identity and optional services, rehearse the target, back up the stopped deployment and use matching release files and images. This is not a recommendation to change only one component or to regenerate passwords.

Installing a package inside a running container is not a durable matched-release upgrade. It can be lost when the container is recreated and leaves the deployment different from its documented image. Do not turn off JWT, grant moderator to everyone or replace component passwords to work around a missing library.

Verify the recovery

After the planned upgrade:

  1. Confirm the running images match the selected release, not just the environment file.
  2. Check fresh Prosody startup logs for successful module loading and the absence of the same missing-inspect failure.
  3. Use a disposable meeting to test the organizer’s intended authentication flow.
  4. Check permitted guest joining and verify that an unauthorized user still cannot obtain access your policy forbids.
  5. Verify a normal meeting, including the bridge path, and retain the backed-up rollback state.

Successful container startup does not by itself establish correct token validation or preserved access controls. If the error remains on a verified corrected image, investigate local images, custom plugin mounts and the new log excerpt before assigning it the same cause.

Scope and maintenance

We reviewed the issue discussion, release notes and immutable source. We did not run the affected image, reproduce authentication failure or upgrade a real server for this article. The correction is established by upstream release evidence; its outcome on your installation still requires the checks above. Recheck issue and release status when changing the version recommendation.

Package installations have a different dependency and service lifecycle. Diagnose their actual installed versions rather than applying Docker image commands to host packages.

Sources

Written by the Jitsi Help engineering team

Jitsi infrastructure engineers who deploy and run Jitsi Meet servers in production. Last updated . How we write our guides

Stuck on something this page does not cover? Ask a question below. Jitsi Help engineers read every one.

Did this fix it?

Something on this page is outdated or wrong?

Collect debug info

These commands gather what an engineer needs to diagnose a Jitsi server. Copy them, run them, and keep the output.

Terminal
# Run on the server, from your docker-jitsi-meet folder

# 1. Every service should be "running" (or "healthy")
docker compose ps

# 2. Which images and release tags are running
docker compose images

# 3. Recent logs from the core services
docker compose logs --tail=200 web prosody jicofo jvb

# 4. The settings most fixes depend on
grep -E '^(PUBLIC_URL|JVB_ADVERTISE_IPS|ENABLE_LETSENCRYPT|ENABLE_AUTH|AUTH_TYPE)=' .env

# 5. Is anything listening for media on UDP 10000?
sudo ss -ulnp | grep 10000

Installed with the Debian packages instead of Docker? Read the service logs with:

Terminal
sudo journalctl -u prosody -u jicofo -u jitsi-videobridge2 --since "1 hour ago"

Remove passwords, secrets and tokens before you share any output.

Send the output to an engineer

Frequently asked questions

Which Docker Jitsi release contains the inspect dependency correction?

The stable-11248-2 release lists the reversal of the lua-inspect removal. The maintainer also linked that release in issue #2346. This is released upstream evidence, not a completed upgrade test of your server.

Should I disable JWT to get meetings working?

No. Disabling authentication changes who can create or enter meetings and does not restore a missing Lua dependency. Diagnose the version and exact error, then use the matching release and preserve your authentication policy.

Does every auth_token error have this cause?

No. This report concerns stable-11248-1 and a missing inspect module. Token claims, issuer settings, component credentials and other module errors require their own checks.

Discussion

    Stuck, or would rather not do this by hand?

    Deploy it in one click

    A private Jitsi server in your own AWS account with SSL, your domain and optional recording, transcription and JWT. Free 15 minute trial.

    Start free trial

    Talk to a Jitsi engineer

    Setup, fixes, branding, recording, scaling. Tell us what is happening and we reply with a plan and a quote.

    Get expert help

    Related

    Recently updated