# How to check your installed Jitsi Meet version

> For Docker, list the project's containers and images, inspect each running container's image reference and image ID, then compare those with docker compose config --images. For Debian or Ubuntu packages, query installed package versions on each component host. Keep the Docker release tag, image identifiers and component package versions separate; a browser version alone does not identify the whole server.

Source: https://jitsi.help/guides/check-jitsi-version/
Updated: October 20, 2026
Publisher: Jitsi Help (https://jitsi.help/)

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]

```bash
docker compose version
docker compose ps --all --format 'table {{.Service}}\t{{.Image}}\t{{.State}}'
docker compose images
```

`ps --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]

```bash
docker compose ps --quiet --status running web
```

Copy 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]

```bash
docker inspect --type container --format 'image_reference={{.Config.Image}} image_id={{.Image}}' CONTAINER_ID
```

Copy 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]

```bash
docker image inspect --format 'id={{.Id}} digests={{json .RepoDigests}}' IMAGE_ID
```

Keep 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]

```bash
docker compose config --images
```

Compare 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](/guides/upgrade-jitsi-docker/), or the [rootless migration guide](/guides/upgrade-jitsi-docker-rootless/) when crossing that release boundary. For role problems, continue with the [moderator policy checks](/guides/jitsi-login-moderator-password/#jwt-works-but-everyone-becomes-a-moderator).

## 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]

```bash
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](/troubleshooting/jvb-jicofo-xmpp-stream-error/), 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](https://github.com/jitsi/jitsi-meet/issues/17926), reviewed October 20, 2026.
- **[S2]** [Docker stable-11248 component definitions](https://github.com/jitsi/docker-jitsi-meet/blob/stable-11248/docker-compose.yml).
- **[S3]** [Docker Compose container listing and state options](https://docs.docker.com/reference/cli/docker/compose/ps/).
- **[S4]** [Docker Compose image inventory](https://docs.docker.com/reference/cli/docker/compose/images/).
- **[S5]** [Docker object inspection and image-reference fields](https://docs.docker.com/reference/cli/docker/inspect/).
- **[S6]** [Docker image inspection](https://docs.docker.com/reference/cli/docker/image/inspect/).
- **[S7]** [Docker image tags, IDs and immutable digests](https://docs.docker.com/reference/cli/docker/image/pull/).
- **[S8]** [Docker Compose configuration resolution and image-only output](https://docs.docker.com/reference/cli/docker/compose/config/).
- **[S9]** [Official Jitsi Docker guide](https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker/) and [stable-11248 release notes](https://github.com/jitsi/docker-jitsi-meet/releases/tag/stable-11248).
- **[S10]** [Debian dpkg-query manual](https://manpages.debian.org/trixie/dpkg/dpkg-query.1.en.html), including package version and installation-status fields.
- **[S11]** [Pinned Jitsi Debian package definitions and Prosody dependencies](https://github.com/jitsi/jitsi-meet/blob/bf7cef3188f67fa212f5ddb8c2e701c600713b3a/debian/control).

## Frequently asked questions

### How do I check my Jitsi Docker version?

Use the same Compose project and file options as the deployment. List its containers and images, inspect the running container's image reference and image ID, and compare them with docker compose config --images. Repeat for web, Prosody, Jicofo and JVB, plus any recording or transcription services.

### Does JITSI_IMAGE_VERSION prove which version is running?

No. It is a configuration input. A changed .env file does not prove that existing containers were recreated. Compare the resolved Compose image names with each container's actual image reference and image ID.

### Why are my Jitsi package version numbers different?

The web application and backend components are separate packages. Record their names and versions individually, and compare them with the release files or deployment record you intended to use. Do not assume every component should have the same package version string.

### Can a meeting guest check the whole server's version?

A guest cannot establish every backend component's deployed version from the meeting page alone. Ask the server administrator for a sanitized component inventory. Browser build or console information can help identify a client, but is not a full server inventory.


---

Jitsi Help is an independent service. It is not affiliated with, endorsed by or sponsored by 8x8, Inc. or the Jitsi project. Jitsi and Jitsi Meet are trademarks of 8x8, Inc., used here only to describe the software we host and support.