Jitsi upgrades and support

An upgrade of a self-hosted Jitsi Meet deployment is not only a server change. The web app that users load runs inside their browser or the Jitsi Electron desktop client, so a release can change how meetings behave on machines you never touch. Support staff need to treat the browser and client matrix as part of every upgrade, not as something that only the people building the server have to think about. Before each release, confirm the current browser matrix with the Jitsi project, since compatibility statements can move between versions.

End-to-end encryption is one area where client differences matter. Per jitsi.org, Jitsi Meet offers end-to-end encryption in Chromium 83 or later and in the Jitsi Electron client. It covers audio, video and screen sharing, and it does not cover chat or polls. Support should therefore not assume that a user on Firefox, Safari or an older Chromium build gets the same protection, and should not describe encryption to users in general terms. Testing should include the browsers and client versions your users actually run, collected from your device inventory or from the browser reports your identity or endpoint tools already provide, plus at least one check that confirms encryption status is shown when a meeting is joined in a supported client.

Certificates are the most common source of browser-side failure after an upgrade. The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video. Self-signed certificates cause problems, and the handbook specifically warns that mobile clients are the most affected. A user may see the page load and still get no camera or microphone, so a certificate problem can look like a media fault. Put certificate expiry dates, the renewal method and the certificate chain on the support checklist, and test joins from a phone on the corporate network as well as from a desktop. Confirm with your certificate authority or internal PKI team how renewals are automated, because a lapsed certificate will break every client at once.

Browser policy changes are the second recurring risk. Browser vendors change permission prompts, autoplay rules, cookie handling and the way they treat insecure content, and any of these can affect camera, microphone or screen sharing access inside a meeting. Support should keep a short register of the browser versions in use, the policy changes announced for them, and the managed settings your organization pushes, such as permission allowlists for the Jitsi domain. When a browser release is announced, run the join test scripts against it in a staging environment before users are moved to it. Where the Jitsi release notes and the browser vendor notes disagree, treat the failing test as the authority and raise it with the Jitsi project.

Finally, write the support runbook so that a browser-related ticket is triaged in a consistent order: confirm the browser and client version, confirm the certificate is valid for the domain the user opened, check the permission state in the browser, and only then escalate to the server team. This order matters because most reports that look like a server fault after an upgrade turn out to be client or certificate issues. Record each result in the ticket so that the next upgrade test can reuse the same checks, and agree with the internal IT owner who approves browser policy changes before the next release goes live.

Once Jitsi Meet is live, the recurring work decides whether it stays reliable. Someone must watch the central server, which runs the nginx or Apache web tier, Prosody, and Jicofo, and watch each Jitsi Videobridge separately, because a healthy signaling server can still sit in front of a bridge that is overloaded or down. The same owner patches the operating system and keeps the OpenJDK 17 runtime current, follows new Jitsi Meet releases such as the stable tag stable/jitsi-meet_11248, renews TLS certificates before they expire, backs up configuration and any recordings, and answers incidents when a meeting fails. Each of these tasks is small on its own. Together they are the standing cost of operating the system. The first upgrade and the standing arrangement are different pieces of work, and they should be priced and staffed separately. The first upgrade includes building a test environment, comparing your local configuration against the defaults in the new release, confirming that Prosody, Jicofo and the videobridges are on matching versions, and checking browser behavior with your users' devices. That is one-time effort. A standing support arrangement covers the repeating tasks: monitoring, patch windows, release testing, certificate renewal, backup checks and incident response. Ask any partner to split its proposal into these two groups so you can see what you pay once and what you pay each period. The Jitsi scalable setup guide warns that building scalable infrastructure is not a task for beginning Jitsi administrators and recommends configuration management tools such as Ansible or Puppet. This affects who can maintain the system. If your team has no experience with these tools, every bridge you add becomes a manual change that someone must remember to repeat, and every upgrade becomes harder to reproduce. Decide early whether your staff will build and own the configuration code, whether a partner will build it and hand it over, or whether you need both. Confirm who holds the repository, the inventory of hosts and the secrets before go-live. A retainer covers the agreed tasks and the response expectations, and both should be set in writing before work starts. Specify which systems are monitored, how often patches are applied, what release testing includes, and how quickly incidents are acknowledged and worked. DeployOpen does not publish a price list, so a quote follows from the written scope. The main cost drivers are the number of videobridges, the number of environments that must be kept in step, whether recording with Jibri is in use, and how often your team expects new releases to be tested. Ask each provider to state which of these drivers its quote includes.

Confirm the Jitsi Meet release running in each environment before any scope is written. The release determines which upgrade path applies. The jitsi-meet repository tags stable builds by number, for example stable/jitsi-meet_11248, so ask for the exact build tag or Docker image tag from production, staging and any test environment, not a general description such as "the current version." For Docker, also confirm whether the deployment predates stable-11146, because the move to rootless containers with read-only filesystems changes how containers are rebuilt and what needs to be checked afterward. Mixed versions across Prosody, Jicofo, the videobridges and the web app are a common cause of failed upgrades, so ask for the version of each component.

Provide administrative access to the hosts or the container platform, plus DNS management for the meeting domain. Upgrades touch the web server, Prosody, Jicofo and each videobridge, so the team needs shell or container administration rights to inspect and change them. DNS access is needed for records that point to the public address and for certificate renewal. Without DNS access, a certificate or domain change waits on another team, and a short maintenance window can close before it is done. Also supply the current configuration files, including the .env file for Docker deployments, or the Debian configuration files for each component. Without them, the team has to reconstruct settings from a running system, which raises the risk of configuration drift after the upgrade.

List every enabled extension and authentication method. In Docker, these are usually visible in the .env file, but ask for a written list anyway, because optional components such as Etherpad, Excalidraw, Jibri or Jigasi each add containers, ports and storage that must be checked after an upgrade. Authentication also needs to be documented exactly: internal XMPP accounts, JWT tokens, LDAP, Matrix verification, or the older secure domain method. The Jitsi handbook marks the secure domain method as deprecated for new installations, so if you still use it, the upgrade scope should say whether migration is included. Supply certificate details too: the domain names covered, the issuer, how renewal runs and when the current certificate expires. HTTPS with a valid domain certificate is necessary for working audio and video.

Name one owner for decisions and one owner for each environment, with authority to approve changes and accept risk. Agree a maintenance window in writing, since restarting services ends active meetings and the window should avoid recording sessions and scheduled events. Provide a test set of user accounts covering guests, authenticated users and moderators, plus the browsers and mobile clients your staff actually use, so verification reflects real sessions. Identify where backups are stored and when a restore was last tested. If auditors require specific evidence, such as change records, access reviews or configuration baselines, share those requirements now. DeployOpen prepares systems and evidence for assessments, but independent auditors issue any audit report or attestation.