Integrating a Self-Hosted Jitsi Server with Moodle, Nextcloud and Mattermost: One Video Backend, JWT Authentication, the IFrame API

An organisation that self-hosts its collaboration tools tends to end up with three of them, each wanting video: the learning platform wants a classroom button, the file platform wants a call button, the chat wants a meeting button. Three video backends is absurd; one Jitsi server that all three trust is the sensible design. This post follows a developer building it on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, where the four applications sit in one account and talk over the internal network.

The organisation is a non-profit training body we will call Northgate Trust. It runs Moodle for courses, Nextcloud for files and Mattermost for staff chat, each as its own environment, and has just installed the Jitsi Video Conferencing package. The developer's brief: every video call from any of the three should run on that Jitsi, and only logged-in users of those applications should be able to start one.

The trust model: JWT tokens instead of passwords

Jitsi Meet supports authentication with JSON Web Tokens. The Jitsi server is configured with an application ID and a shared secret; an integrating application signs a token with that secret containing the room name, the user's display name and avatar, and whether the user may moderate. A participant who arrives with a valid token is admitted (and, if the token says so, made moderator); one without a token can be allowed as a guest into an existing room or refused, depending on configuration. This is exactly the shape Northgate needs: Moodle, Nextcloud and Mattermost each know who their users are, and each can vouch for them to Jitsi with a signature, without Jitsi having its own user database.

The developer enables the token authentication module in Prosody on the Jitsi node through the platform's config editor, sets the application ID and secret, and configures guests to be allowed into rooms that a token holder has already opened. The secret is stored in each application's settings; it never appears in a browser.

Moodle: a classroom per course

Moodle has a maintained Jitsi activity module. The developer installs it (after testing it on a cloned Moodle environment, as the school's upgrade policy requires), sets the server URL to the Jitsi node's domain, and selects JWT authentication with the application ID and secret. Teachers add a Jitsi activity to a course; students click it and are admitted with their Moodle name and avatar, and the teacher's token carries the moderator flag. Room names are derived from the course and activity, so they are unique and unguessable enough for a training body. Sessions can be recorded through Jitsi's recording component if the teacher chooses.

Nextcloud: a call button on every share

Nextcloud's own Talk app has its own WebRTC backend, which Northgate did not want to run separately. A community Jitsi integration app for Nextcloud instead embeds Jitsi Meet rooms in the Nextcloud interface and supports JWT with the same application ID and secret. Users start a room from the Nextcloud navigation and share its link with colleagues; because they are logged into Nextcloud, they arrive as moderators. The developer notes that the two approaches can coexist: Talk for quick one-to-one calls inside Nextcloud, Jitsi for anything with an external participant.

Mattermost: /jitsi in any channel

Mattermost has an official Jitsi plugin. Installed from the Mattermost system console and pointed at the Northgate Jitsi URL with JWT enabled and the same secret, it adds a /jitsi slash command and a meeting button to every channel. A user who types the command posts a join link into the channel; participants from the channel join with their Mattermost identities. Because Mattermost and Jitsi live on the same PaaS account, the plugin's server-side calls to Jitsi travel the internal network and never leave the data centre; only the participants' media goes to Jitsi's public IP.

Embedding Jitsi in Northgate's own portal

Northgate also has a small internal portal, and the developer wants a Join Session button there without a plugin. Jitsi's IFrame API does it: include the server's external_api.js, create a JitsiMeetExternalAPI object with the room name and a JWT the portal's back end signed for the current user, and Jitsi renders in the page with the participant already named and authenticated. The API exposes events (participant joined, recording started) and commands (mute, hang up), so the portal can show attendance without touching the Jitsi server.

const api = new JitsiMeetExternalAPI('meet.northgate.example', {
  roomName: 'training-2026-cohort-b',
  jwt: tokenFromPortalBackend,
  parentNode: document.querySelector('#meet'),
  configOverwrite: { prejoinConfig: { enabled: true } }
});
api.addEventListener('participantJoined', (e) => recordAttendance(e.id));

Keeping it all in one place

The four environments sit in one environment group on the account, so the team sees them and their costs together and can share access with the training body's IT volunteer through collaboration roles. Server-to-server traffic between them stays on the internal network. The Jitsi node has a public IP and UDP 10000 open for media; the other three are reached through their own domains. When the trust rotates the JWT secret each year, it is one change on the Jitsi node and one in each of three applications, and the developer does it on a Friday evening in ten minutes.

Frequently Asked Questions

Can guests without an account still join a Moodle or Mattermost meeting?

Yes, if the Jitsi server is configured to allow guests into rooms a token holder has opened. Guests arrive without a token, wait in the lobby if enabled, and are admitted by the moderator. They cannot create rooms themselves.

Do all three applications have to share one JWT secret?

Jitsi's token module supports one application ID and secret per server. Sharing it across trusted internal applications is normal. If you need separate secrets per application, run the token module with an asymmetric key set (public keys per issuer), which recent Jitsi releases support.

Does the Jitsi server need to be on the same platform as the applications?

No, JWT works over the public internet. Having them on one PaaS account keeps server-to-server calls on the internal network, puts everything in one region for compliance, and lets you manage and bill them as a group, which is why Northgate did it.