Managed Jitsi Meet hosting

Collaboration and identityOn-prem or sovereign site

Video meetings people join from a link in the browser, run in Switzerland, the EU or your own datacentre so the servers that route the calls stay in the jurisdiction you picked. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Jitsi Meet

Licence
Apache-2.0
Runs on
Your own hardware, or any of twelve Pilae regions — six of them in Switzerland and the EU
Upgrades
Pinned, tested against your configuration, applied in your window
Upstream
jitsi.org

Running Jitsi Meet in production: what it takes

  1. Deploy signalling, bridge and TURN

    A version we have run: the web interface, Prosody and Jicofo on one machine, Jitsi Videobridge on dedicated cores with its UDP media port open, and a TURN server on 443 for networks that block UDP.

  2. Sign in hosts, admit guests by link

    Hosts sign in through Keycloak or your identity provider, and guests who open the link wait in the lobby until one of them arrives. Gravatar lookups are off, and STUN points at your own server rather than the public one the default configuration uses.

  3. Watch the bridges, add more when they fill

    Probes every 60 seconds on the web interface and on the health endpoint of each bridge, with bandwidth watched per bridge and alerts reaching an engineer. A bridge near the limit of its link gets a second one beside it, and more simultaneous recordings mean more Jibri machines.

  4. Back up recordings, not meetings

    A meeting in progress stores nothing, so what we back up is configuration, Prosody data and recordings: daily, encrypted, to an offsite location in your chosen country. Once a month we restore them into a scratch environment and hold a three-person call on it from outside the network.

  5. Upgrade when no meetings are booked

    Each Jitsi stable release ships the web interface with matching versions of Jicofo and the videobridge. The Pilae Agent tests each one on a copy, waits for your approval and applies it in your window, draining each bridge first. A restart interrupts meetings in progress, so we agree a window with no meetings booked.

What Jitsi Meet is, and who runs it

Self-hosted Jitsi Meet for video meetings

Jitsi Meet is video conferencing in the browser. A meeting is a link: people open it and join, with screen sharing, chat, breakout rooms, polls and a lobby. Desktop and mobile apps exist for those who want them, and guests need no account. The project is maintained by the Jitsi team at 8x8 with community contributors.

It replaces Zoom, Teams meetings or Google Meet where calls with customers and partners have to run in a country you chose. We put the bridges where you want the calls routed: in one of 12 Pilae Cloud regions, Zurich and five EU regions among them, or on your own hardware.

Element Web, the browser app of Element, can start conference calls in a room through Jitsi and can point at your deployment. Mattermost calls are voice and screen sharing between people with an account, and group calls need a paid Mattermost plan; a meeting with cameras on, or a supplier with no account, belongs in Jitsi Meet.

Jitsi Meet in production: bridges, TURN and recordings

Four services make a deployment: the web interface, Prosody for signalling, Jicofo to run each conference and Jitsi Videobridge to route the media. Jicofo places each new conference on a bridge, so capacity grows by adding bridges, not by buying a bigger machine.

Media is where Jitsi Meet departs from our private network rule: guests must reach a UDP port on the bridge, or TURN on 443 when their network blocks UDP. Get either wrong and a meeting works with two people, who talk peer to peer, then goes silent when a third joins and everyone moves onto the bridge. We test from outside before go-live and in every monthly restore drill.

Recording runs through Jibri on machines of its own, because upstream warns that a recorder on the same server can exhaust the disk and stop Jitsi Meet altogether. Recordings, configuration and Prosody’s data are backed up daily, encrypted, to an offsite location in your chosen country. Upgrades go through the Pilae Agent in a window with no meetings booked, and each bridge is drained before it restarts.

Jitsi Meet licence and sign-on

There is no per-user fee. Hosts sign in with JSON Web Tokens, which upstream recommends over its deprecated secure-domain set-up, and the community OpenID Connect adapter issues them from Keycloak, which can broker Microsoft Entra ID. Pricing for our operation is on request. Talk to us about the meetings you want to hold on servers of your own.

Jitsi Meet and the Jitsi components it runs on, Jitsi Videobridge, Jicofo and Jibri, are Apache-2.0. There is no paid edition of the self-hosted software and no feature held back for one. 8x8, which maintains the project, sells a hosted version called Jitsi as a Service, which you do not need when the servers are yours. Jitsi is a trademark of 8x8, and the Apache licence grants no rights to the name, so we brand your deployment with your own. Single sign-on through OpenID Connect uses a community adapter from the jitsi-contrib project, also Apache-2.0, which we pin and test with each release.

Jitsi Meet system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory
4 dedicated vCPU · 8 GBFor the web interface, Prosody, Jicofo and one videobridge. Media is real time, so the cores are dedicated rather than shared, and Prosody only ever uses one of them.
Network
1 Gbit/s · 10000/udpUpstream counts about 2.5 Mbit/s per 720p stream. Every participant, guests included, must reach the bridge on UDP 10000. When one link fills, we add a second bridge.
TURN
coturn · TLS on 443Some corporate networks allow only TCP on port 443. TURN over TLS on 443 relays their media; without it, those people join but their audio and video do not get through.
Recording
Jibri · 1 per recording · 8 GB+Jibri runs Chrome in a virtual display and encodes with ffmpeg, one meeting at a time. Two recordings at once need two Jibris, on machines separate from the meeting servers.
Host sign-in
JWT via OIDC adapterHosts get a token from Keycloak or your identity provider through the adapter. Only hosts need an account; guests join by link.

Migrating from Zoom to Jitsi Meet

Nothing in Zoom has to be imported, because a meeting is not a document. What moves is everything around it. Recurring invites in people's calendars carry Zoom links, and each one is re-sent with a Jitsi room address. Cloud recordings stay in Zoom until someone downloads them, so we export the ones you must keep before the licence ends. Phone dial-in has to be replaced: in Jitsi Meet it needs the Jigasi gateway and a SIP account from a telephony provider. Jitsi is not among the third-party meetings a Zoom Room can join, so a room PC with a browser takes its place. The servers are the quick part; the rooms and the phone numbers take the time.

  1. List what depends on Zoom

    Recurring meetings and their owners, dial-in numbers people still call, room systems, webinars and the cloud recordings you must keep. Each item gets a replacement, or a decision to drop it, before the move.

  2. Test from the networks your guests use

    A pilot bridge, tried from the office, from home, from a phone on mobile data and from a locked-down partner network, so UDP media and the TURN fallback are proven before anyone relies on them.

  3. Set up sign-on and standing rooms

    Hosts sign in through your identity provider from the first real meeting, with no new password to remember. Teams and recurring meetings get fixed room addresses with the lobby on, so a link sent once works for every meeting after it.

  4. Re-issue the invites, then let Zoom lapse

    Owners re-send each recurring invite with its standing room address, and the recordings on the keep list come out of Zoom. Zoom stays available until its renewal date for anything that was missed.

Sign-on, guests and media in one .env file

# acme-meet/.env (excerpt) · zur1
PUBLIC_URL=https://meet.acme.ch
TZ=Europe/Zurich
CONFIG=/srv/jitsi-meet-cfg

# TLS ends at the Pilae gate on 443
DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETSENCRYPT=0

# Media: the one port besides 443 that guests must reach
JVB_PORT=10000
JVB_ADVERTISE_IPS=10.20.0.14,203.0.113.24

# Hosts sign in through Keycloak; guests wait for a host
ENABLE_AUTH=1
JICOFO_ENABLE_AUTH=0
AUTH_TYPE=jwt
JWT_APP_ID=acme-meet
TOKEN_AUTH_URL=https://meet.acme.ch/oidc/auth?state={state}
ENABLE_GUESTS=1
XMPP_MODULES=persistent_lobby
XMPP_MUC_MODULES=muc_wait_for_host

# No Gravatar, no public STUN server
ENABLE_THIRD_PARTY_REQUESTS=0
P2P_STUN_SERVERS=turn.acme.ch:3478
JVB_DISABLE_STUN=1

# TURN over TLS for networks that block UDP
TURNS_HOST=turn.acme.ch
TURNS_PORT=443

# Jibri recorders run on their own machines
ENABLE_RECORDING=1

# JWT_APP_SECRET, TURN_CREDENTIALS and service passwords: from the secret store
An example excerpt from a Docker deployment in Zurich. Hosts sign in through Keycloak, guests wait until one arrives, Gravatar and the public STUN server are switched off, and TURN on 443 carries the people whose networks block UDP. Secrets are written at deploy time and never committed.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs
zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials
You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave
The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running Jitsi Meet

Pricing is on request: a fixed price for onboarding, then a monthly price for Jitsi Meet, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size
The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability
One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups
How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support
Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region
Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.
Sign-on and integrations
Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Jitsi Meet: common questions

Is Jitsi Meet open source?

Yes. Jitsi Meet and its server components, Jitsi Videobridge, Jicofo and Jibri, are Apache-2.0, with no paid edition of the self-hosted software. 8x8, which maintains the project, sells a hosted version called Jitsi as a Service, which you do not need when the servers are yours. The Jitsi name is a trademark of 8x8, so your deployment carries your own name.

Where do our meetings and recordings live?

Wherever you put the bridge: Zurich, an EU region such as Frankfurt or Amsterdam, another Pilae region, or your own hardware. Audio and video are encrypted in transit and pass through a videobridge on dedicated machines there, which routes packets in memory and stores none of them. In a two-person call they go directly between the two devices, or through your TURN server, unless you ask us to switch peer-to-peer mode off. Recordings are files in storage in the same region, backed up with the rest.

Can people outside our organisation join?

Yes, from a link in a browser or from the Jitsi Meet mobile apps, without an account. They wait in a lobby until a signed-in host joins. Their audio and video reach the bridge over UDP, and through TURN on port 443 where their network blocks UDP, so a guest behind a strict corporate firewall is still seen and heard.

Can we record meetings?

Yes, through Jibri. One Jibri records one meeting and upstream asks for at least 8 GB of memory for each, so we size recording by how many meetings you need to record at the same time. Where policy requires recordings to be kept centrally, we switch off local recording in the browser.

Is Jitsi Meet right for teaching and training?

Less so than for meetings. Slides are shared by screen sharing, and a recording is a video file. BigBlueButton is built for teaching: slides are uploaded and annotated, recordings replay the slides and the chat, and it runs as an activity in Moodle. For training and education work we can scope BigBlueButton instead.

Also in collaboration and identity

Back to apps

Bring us your Jitsi Meet. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.