Jitsi Meet has several components. A Docker release tag, a web package version and a running Jicofo build are different identifiers. Record the component that has the problem rather than reducing the whole deployment to one number. The upstream discussion about identifying versions makes this distinction explicit. [S1][S2][S11]
This guide is for administrators with permission to inspect their deployment. If you only received a meeting invitation, ask its organizer or administrator for the server details. Keep private meeting links and access tokens out of version reports.
Docker: identify the actual containers
Run these commands where the deployment’s Compose files live. Reuse its exact project name, -f file order, profiles and environment-file options. The examples use plain docker compose for a default project; add your existing options to each command if your deployment needs them. These are inspection commands, not an upgrade procedure. [S3][S4]
docker compose version
docker compose ps --all --format 'table {{.Service}}\t{{.Image}}\t{{.State}}'
docker compose imagesps --all includes stopped containers. Read the state column before calling an image “running”. images lists images used by created containers; it does not establish what a future deployment will use. Standard Jitsi service names include web, prosody, jicofo and jvb; include any optional components you actually deploy. [S2][S3][S4]
An empty result can mean the wrong project, directory or file list. Check those inputs before assuming the server has no containers. If an older Compose CLI rejects the formatted output, use docker compose ps --all and read its ordinary table. [S3]
Record the image reference and image ID
First obtain the running web container ID. Repeat this with the actual service names for the other components. [S3]
docker compose ps --quiet --status running webCopy its output and replace CONTAINER_ID below. If it returns nothing, inspect the container state before continuing. Request only the image fields, rather than sharing the entire container inspection. [S5]
docker inspect --type container --format 'image_reference={{.Config.Image}} image_id={{.Image}}' CONTAINER_IDCopy the complete sha256:... image ID from that result and replace IMAGE_ID below. Inspect the ID used by the container, not just a tag that might now refer to a different locally available image. [S5][S6][S7]
docker image inspect --format 'id={{.Id}} digests={{json .RepoDigests}}' IMAGE_IDKeep the reference, ID and available repository digests in your deployment record. Tags are names; a digest identifies image content. A local or custom build may have no repository digest, so an empty list alone is not evidence of corruption. Record how that image was built and any mounted custom plugins separately. [S6][S7]
Compare running images with Compose configuration
Use the same file and project options again. This prints the resolved image names without printing the full configuration. [S8]
docker compose config --imagesCompare the names with the container inventory:
| Observation | What to check next |
|---|---|
| Resolved configuration names a different tag from the running container | Check the deployment record and file set; editing configuration alone does not replace a container. |
Reference uses a moving tag such as stable |
Keep the running image ID and digest; the tag alone is insufficient to identify the image content. |
| Core components come from different intended releases | Investigate a partial upgrade or override before choosing a recovery procedure. |
| Correct images, but a custom Prosody plugin behaves differently | Inventory the mounted plugin and effective module configuration as well as the image. |
These are diagnostic branches, not instructions to restart or upgrade immediately. The official Docker guide recommends the release archive for production; compare your files and overlays with the chosen release. For example, stable-11248 has its own Compose file and release notes. Do not assume a current master file describes an older deployment. [S2][S9]
Once the versions and mismatch are understood, follow the Docker upgrade guide, or the rootless migration guide when crossing that release boundary. For role problems, continue with the moderator policy checks.
Debian or Ubuntu: list installed component packages
Run this in a Linux shell on the host where the packages are installed. It queries the package database and filters for installed Jitsi components and Prosody. On a distributed deployment, repeat it on the relevant hosts. A Docker host’s package database does not inventory packages inside its containers. [S10]
dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' |
awk '$1 ~ /^(jitsi-meet|jitsi-videobridge2?|jicofo|prosody|jibri|jigasi|coturn)([-:]|$)/ && $3 == "installed"'The columns are package name, version and status. This reports installed versions, rather than repository update candidates, and omits entries that are only known to the package database. No matching output does not prove a Jitsi outage; verify that you are inspecting the correct host and installation method. [S10]
Keep the component rows separately. Do not require the web application, conference controller, bridge and Prosody to have identical version strings. The Docker release identifier and a package’s version string are also not interchangeable. [S1][S2][S11]
What browser information can tell you
Upstream maintainers point administrators to component version messages in debug console logs. Such information can supplement a report, but it does not replace the backend inventory. Do not upload an unredacted browser log just to share a version: logs can contain room identifiers and connection details. [S1]
Save a useful support record
Record the inspection date, installation type, affected component, running image reference and ID or installed package version, intended release and exact Compose file list. Include the last known working release and sanitized error text when available. Keep private registry names or internal hostnames private if they identify your organization.
For a JVB or Jicofo connection failure, component versions help determine which source and configuration format to inspect. The inventory itself does not fix the connection or prove that versions caused it.
Verification and open questions
Commands checked October 20, 2026 with Docker Engine 29.2.1 and Compose 5.0.2 against an isolated ghcr.io/jitsi/web:stable-11248 Linux/amd64 container. Its Jitsi entrypoint was replaced by an idle process, with no published ports or network access. This checked metadata queries, not a functioning meeting server.
The fixture reported jitsi-meet-web version 1.0.9442-1 on Debian 13. A temporary change to the lab’s Compose tag changed config --images, while ps still reported the original running image. The container’s start time and restart count stayed unchanged during inspection.
The package query was verified inside that Debian image. A complete Ubuntu package deployment, additional component images, custom registries and older Compose versions were not exercised. The commands are documented upstream, but this page remains marked as not production-tested. A custom build or mounted plugin may require additional provenance that these commands cannot recover.
Recheck the commands when Compose output, package naming or Jitsi’s release layout changes. Read the exact release’s documentation before acting on a mismatch.
Sources
- [S1] Upstream issue #17926: identifying Jitsi and backend versions, reviewed October 20, 2026.
- [S2] Docker stable-11248 component definitions.
- [S3] Docker Compose container listing and state options.
- [S4] Docker Compose image inventory.
- [S5] Docker object inspection and image-reference fields.
- [S6] Docker image inspection.
- [S7] Docker image tags, IDs and immutable digests.
- [S8] Docker Compose configuration resolution and image-only output.
- [S9] Official Jitsi Docker guide and stable-11248 release notes.
- [S10] Debian dpkg-query manual, including package version and installation-status fields.
- [S11] Pinned Jitsi Debian package definitions and Prosody dependencies.