What this decision involves
The first decision is whether Jitsi Meet runs on infrastructure you control or whether you use a managed service. Jitsi Meet is open source software licensed under Apache 2.0, so your organization can self-host it. 8x8 offers JaaS (Jitsi as a Service), a managed alternative run by the team that builds Jitsi, and the free public instance at meet.jit.si is a third option for casual use. Jitsi is a trademark of 8x8, Inc. DeployOpen is independent of 8x8 and does not resell JaaS.
Teams usually revisit this choice when one of four things changes: meeting content or participant data must stay inside a defined boundary, usage grows enough that per-minute or per-seat fees are worth re-examining, an internal security or data handling policy requires self-hosting, or recording and live streaming become a requirement. Each trigger points to different costs and different controls, so the trigger should be named before any option is priced.
Before committing, ask for both options to be costed against the same written scope: expected concurrent participants, recording needs, identity and guest access rules, and who operates the service afterward. Confirm current JaaS pricing and terms directly with 8x8, and confirm your own cloud, bandwidth and staffing rates internally. A partner's written scope gives you a like-for-like basis for that comparison.
What a cost of ownership study includes
A written estimate should price each part of the deployment, then separate one-time work from recurring running costs. DeployOpen does not publish prices, and the quote follows from the written scope.
Component stack and host layout
Each Jitsi Meet role runs as its own service: the web server that serves the app, Prosody for XMPP, Jicofo for conference focus and Jitsi Videobridge for media routing. The estimate should show which roles run on which hosts or containers and whether any share a machine. The Jitsi scalable setup guide suggests a 4 CPU, 8 GB central server and 4 or 8 CPU with 8 GB RAM per bridge as reference points to confirm.
Bridge hosts and headroom
Videobridges scale horizontally, so the number of bridges follows expected concurrent participants, not just meeting count. The estimate should state the bridge count, the spare capacity kept for peaks, and whether a spare bridge covers a failed host mid-meeting. Confirm whether these hosts run in your cloud account, a data center or an air-gapped network, because that choice changes both the hardware line and the recurring fees.
Bandwidth and egress paths
Media traffic passes through the videobridges on UDP port 10000 by default, and that traffic is the main bandwidth driver. The estimate should model peak concurrent participants, average meeting length and the share of users on TCP fallback or TURN relays. Ask your provider how inbound and outbound transfer is billed, and whether any relay or TURN service adds a separate charge.
Optional Jibri and Jigasi capacity
Jibri records or streams a meeting in Chrome with ffmpeg, and it supports one recording at a time per instance, so each concurrent recording needs its own host or VM. Jigasi adds SIP dial-in and transcription, and its Google Cloud, Vosk or Whisper backends carry different fees and data handling terms. Price these as separate line items, with storage for recordings and retention periods listed in the assumptions.
Certificates, backups and monitoring
Working audio and video require HTTPS with a certificate for a proper domain, and self-signed certificates cause problems, especially on mobile clients. The estimate should include certificate issuance and renewal, backup storage and restore testing for configuration and any recordings, and the monitoring hosts or subscriptions that watch bridges and the central server. Each of these items recurs, so record its renewal or subscription cycle.
Internal staff time and deliverables
Internal IT time covers the initial build, testing, upgrades on matching stable releases, incident response and user support, and it is often the largest unpriced cost. The written scope should list the deliverables: a cost model in one-time and recurring categories, a sizing assumption sheet, a comparison with JaaS terms supplied by 8x8 and a list of open questions for your team to answer before the quote is final.
What drives the cost
This table lists each driver of self-hosted Jitsi Meet cost and effort, why it moves the total, and how to keep it down, so you can check each one against a written quote.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Concurrent participants, meeting length and bridge count | Load on the videobridges follows peak concurrent participants and how long meetings run. The scalable setup guide says bridges scale by adding more, so bridge count is the main lever for capacity. | Measure peak concurrency from your calendar or meeting logs before sizing. Start with the default single-bridge install and add bridges only when measured load requires it. |
| CPU and RAM per machine | The scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Each machine size is a line item in cloud or hardware costs. | Confirm sizing with your own load test before buying. Choose the smaller suggested size where measurements allow, and ask the partner to state the sizing basis in the quote. |
| Bandwidth per participant | Media passes through the videobridges, so outbound traffic grows with participants and video quality. Many cloud providers bill outbound data, so this cost can grow faster than compute. | Estimate traffic from load tests, then compare the result with your provider's outbound data terms. Review default video quality settings with your user groups. |
| Recording volume and Jibri count | Jibri records one meeting at a time per instance, and the README says each should run on its own machine or VM. Simultaneous recordings need simultaneous Jibri machines, and storage grows with recording length and retention. | Record only meetings that need it, set a retention period in writing, and size the Jibri count to the peak number of simultaneous recordings you expect. |
| SIP dial-in and transcription backends | Jigasi adds SIP dial-in and transcription. Google Cloud is an external metered service, while Vosk and Whisper run on your own compute, which adds machine capacity and maintenance. | Decide whether dial-in and transcription are required. Pick the backend that fits your data rules and the compute you are willing to run. |
| Number of environments | Each environment, such as test, staging and production, repeats the web server, Prosody, Jicofo, videobridges and any optional Jibri or Jigasi components. Each copy adds infrastructure and maintenance work. | Keep the test environment small but on matching stable releases, and manage all environments with one set of configuration management code, as the scalable guide recommends. |
| Authentication choice | JWT tokens need an identity system that issues them, LDAP needs directory integration, and Matrix options depend on how your Matrix deployment is run. Internal XMPP accounts are simplest to start but add accounts your team must manage. | Choose the option that matches your existing identity system. Avoid creating a second identity store, and plan the replacement of the deprecated secure domain setup early. |
| Compliance evidence | Assessors look for configuration records, patch and upgrade history, access controls, backup tests and logs. Your team produces this evidence, and independent auditors, not DeployOpen, issue any audit report. | Ask the partner to list the evidence each control needs before work starts, and keep configuration in version control so records are produced as a by-product of operations. |
| Edition choice | Jitsi Meet is licensed under Apache 2.0, so the software carries no license fee. Costs sit in infrastructure, staff time, and any support contract. JaaS is a hosted service from 8x8 with its own terms and pricing. | Compare total cost for both options using the same concurrency, recording and support assumptions. Request written terms from 8x8 for JaaS and a written scope from any implementation partner. |
How the estimate is produced
The sequence turns a set of usage and policy answers into a written comparison of self-hosted Jitsi and JaaS, with each cost line traced to a stated assumption.
Collect usage and policy requirements
We work with your IT and security owners to record expected concurrent participants, meeting length, peak periods, guest access, recording and SIP dial-in needs, and any rule that meetings or recordings stay in approved regions or networks. The output is a requirements sheet with each answer marked as confirmed or open, so every later assumption can be traced back to a stated need.
Design architecture and size capacity
We map the requirements to a Jitsi Meet layout: web server, Prosody, Jicofo, videobridges, and optional Jibri or Jigasi hosts. The output is a sizing sheet listing the number of videobridges, CPU and RAM per host from the scalable setup guidance, bandwidth per bridge, storage for recordings, and the monitoring and backup components the design requires.
Compare self-hosted and JaaS terms
We set the sized design beside the JaaS option using 8x8's current published terms and the questions the organization must put to 8x8, such as data location, recording storage, feature availability, and support levels. The output is a side-by-side comparison table and a list of written questions for 8x8 that must be answered before the comparison is final.
Build the cost model
We separate one-time costs (design, build, certificate and network setup, initial testing and migration of meeting links) from recurring costs (compute, bandwidth, storage, monitoring, upgrades, support retainer and internal staff time). The output is a cost model in which every line names its driver and its assumption, such as a bridge count or a recording retention period.
Review assumptions with finance and IT owners
We walk the finance lead and IT owners through the cost model and the assumptions behind it, and record which numbers they accept, challenge, or need to source from their own cloud or data center billing. The output is a reviewed assumptions log, with each change tracked and the owner of every open item named.
Issue the written quote
We convert the reviewed model into a written quote tied to the agreed scope, deliverables, and the assumptions log, and state which costs are outside the quote, such as your own cloud or bandwidth charges. You know this step is complete when the quote, the sizing sheet, and the open-questions list all reference the same assumptions and the owners have signed off on them.
One-time and recurring costs
This table splits self-hosted Jitsi costs into one-time and recurring items, showing who pays for each and what changes the figure, with JaaS included for comparison.
| Cost component | Who pays | One-time or recurring | What changes the figure |
|---|---|---|---|
| Architecture, deployment, DNS and certificate setup | Partner or client staff, per the written scope | One-time | Number of bridges, existing DNS and certificate processes, and whether your team or a partner builds it. |
| Load testing, authentication, branding and recording setup | Partner, client staff or both | One-time | Expected concurrent participants, the chosen authentication method, brand assets, and the number of Jibri instances. |
| Hosting for the central server and videobridges | Cloud or data center provider | Recurring | Number and size of instances. The scalable setup guide suggests 4 CPU and 8 GB for the central server. |
| Bandwidth for media traffic | Cloud or data center provider, or your network team | Recurring | Participants per meeting, video quality, concurrent meetings, and whether the provider meters outbound traffic. |
| Recording storage and retention | Cloud or data center provider, or your storage team | Recurring | Recording hours, file size, retention period and archive policy. Each Jibri records one meeting at a time. |
| Monitoring and backups | Client staff or partner, plus the hosting provider | Recurring | Number of hosts, alerting scope, backup frequency, retention period, and where backups are stored. |
| Upgrades, testing and staff time | Client staff, or a partner under a retainer | Recurring | Stable builds change over time, such as stable/jitsi-meet_11248 in the GitHub repository. Each upgrade needs testing before rollout. |
| Support retainer and TLS certificate renewals | Partner under a retainer, plus your certificate authority or PKI team | Recurring | Support scope and response expectations in the written agreement. Renewal timing depends on the issuing authority. |
| JaaS subscription (hosted alternative) | Client pays 8x8 directly | Recurring | Costs follow 8x8's commercial terms. Obtain pricing and terms directly from 8x8 before comparing. |
Where estimates go wrong
Six gaps recur in Jitsi quotes. Each one moves cost from the quote into your team's later rework, so check each line before accepting a scope.
Bridge count for peak concurrency
Estimates often size videobridges for average use. Count the largest number of simultaneous participants you expect, then add capacity so that losing one bridge does not end active meetings. The scalable setup guide suggests 4 or 8 CPUs with 8 GB RAM per bridge, so require the bridge count and its arithmetic in the quote.
Media ports and TCP fallback
Quotes often assume that web traffic on 443 is enough. Media needs 10000/UDP reachable at the videobridges, and the Debian and Ubuntu quick start lists 5349/TCP for TCP fallback when UDP is blocked. Include firewall change requests, security group rules and tests from restrictive networks, and confirm who approves those changes internally.
Public IP and NAT work
Bridges behind NAT need correct public address settings so remote participants can reach them. Each bridge needs its own addressing plan, DNS records and firewall mapping, and every bridge you add repeats that work. Ask for a line item covering public IP allocation, NAT configuration and verification from outside your network as well as inside it.
One Jibri per recording
The Jibri README states that a single Jibri supports only one recording at a time, and it should run on its own machine or VM. Estimates that treat one Jibri as serving many meetings undercount hosts, Chrome and ffmpeg capacity and recording storage. Ask the quote to state the expected number of concurrent recordings and the Jibri hosts that requires.
Internal time for scalable setup
The Jitsi scalable setup guide warns that building scalable infrastructure is not a task for beginning administrators and recommends tools such as Ansible or Puppet. Estimates often leave out the hours your staff need to learn, review and operate that tooling after handover. Ask for the internal time your team must commit, not only the partner's build days.
Rebuilds after certificate or domain errors
The Jitsi handbook says a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially on mobile clients. It also marks the secure domain method as deprecated for new installations. Estimates that omit the cost of replacing certificates or switching to JWT authentication after launch understate effort, so settle both before the build starts.
How the cost model changes by starting point
Moving off a hosted service removes a usage or subscription line and adds infrastructure and staff time. The model shifts from a service fee to a set of recurring items you run yourself.
- Removed: the hosted service charge, which you should compare with your current 8x8 agreement or your existing free public use.
- Added: servers for the web server, Prosody, Jicofo and videobridges, plus the bandwidth they carry.
- One-time: domain and certificate setup, and migration of room links, calendar entries and app integrations.
- Recurring: patching, upgrades to matching stable releases and on-call coverage for meetings.
- Ask for: a quote that separates migration work from ongoing support, so you can compare it with your current contract.
Existing virtualization or Kubernetes platforms can lower hardware spend when spare capacity already exists, but they move cost into platform work. The Jitsi scalable setup guide suggests 4 CPU and 8 GB RAM for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge, so treat those sizes as a starting point to confirm.
- Hardware: spare capacity on current hosts may cover the central server and bridges, if the sizes fit.
- Platform labor: Kubernetes networking for UDP media, ingress and node placement adds design and testing time.
- Licensing: hypervisor or cluster software you already license may add no new line, but confirm any per-core charges.
- Bandwidth: media traffic still leaves through your network edge, so review egress capacity on either platform.
- Ask for: whether the quote covers Kubernetes manifests or only virtual machine builds, and who maintains them.
The install method changes who owns host and upgrade work more than the server count. The Debian and Ubuntu quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, and requires OpenJDK 17. The official Docker setup runs separate containers for web, prosody, jicofo, jvb and optional components.
- Packages: each host needs operating system and Java patching, and host images must match the supported releases.
- Docker: more moving parts to version, monitor and back up, but image rebuilds carry some of the host patching work.
- Security review: since stable-11146 the Docker containers run rootless with read-only filesystems, which affects how long hardening review takes.
- Labor: confirm how often your team expects to test upgrades between stable build numbers.
- Ask for: which method the quote assumes and how upgrade testing is scoped.
Without public cloud, you own every line a provider would otherwise bill. Costs move toward hardware purchase, facility and network work, and offline update handling.
- One-time: hardware for the central server and bridges, plus firewall work for 80/TCP, 443/TCP and 10000/UDP.
- Certificates: the Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video, so plan an internal certificate authority or a public certificate process.
- Updates: operating system packages and Docker images must be mirrored inside the network, which adds staff time for each release.
- Bandwidth: provider egress charges disappear, but you must size internal link capacity for media.
- Ask for: how offline mirrors, certificate issuance and dependency updates are priced and who performs them.
Recording and SIP dial-in add the most cost per concurrent meeting because they need dedicated machines. Jibri runs Chrome in a virtual framebuffer and encodes with ffmpeg, and its README states that one recording at a time is supported per Jibri, which should run on its own machine or VM.
- Compute: one Jibri machine per simultaneous recording, so recording capacity grows with concurrent recordings.
- Storage: recording files need capacity and a retention rule, and both recur over time.
- SIP and transcription: Jigasi needs its own sizing, and any telephony trunk or transcription service (Google Cloud, Vosk or Whisper) may bill separately, so confirm each arrangement.
- Labor: testing recording and dial-in after each upgrade adds a recurring effort line.
- Ask for: a breakdown per Jibri, per storage tier and per SIP component, with retention assumptions stated.
What to provide before requesting a quote
Give the quote team the inputs below before asking for a price, because each one changes the number of videobridges, the bandwidth budget or the support effort. The business owner should supply peak and typical concurrent participants, the longest normal meeting length and how many people will schedule meetings at the same time. Record these as ranges with the period they cover, since a quote built on a single peak figure will overstate typical weeks and understate busy ones.
The platform lead should confirm where the servers may run, including the cloud accounts, data center rules and any network segments that must stay private. The network team owns the bandwidth budget per videobridge and confirms that 80/TCP, 443/TCP and 10000/UDP can be opened, along with 5349/TCP for TCP fallback if restrictive networks are expected. The DNS and certificate owner must name the domain and agree how a trusted TLS certificate will be issued and renewed, because the Jitsi handbook warns that self-signed certificates cause problems, especially with mobile clients.
Decide whether recording or SIP dial-in is needed and estimate how many sessions each will handle in a typical month. Each Jibri instance records one conference at a time, so the recording owner should state how many simultaneous recordings are expected. The identity team names the authentication source, whether that is internal XMPP accounts, JWT tokens from your identity system, LDAP or Matrix. The monitoring and backup owners list the tools already in use. If JaaS is also being quoted, ask 8x8 to name a commercial contact and confirm in writing who owns the comparison.
Questions buyers ask about Jitsi cost
Is Jitsi free to self-host under the Apache 2.0 license?
The Jitsi Meet software is licensed under Apache 2.0, so there is no license fee for running it yourself, according to the jitsi-meet GitHub repository. Your costs are the servers and bandwidth for videobridges, storage if you record, monitoring, and the staff time to install, configure, patch and support it. Those costs recur, and the license does not cover them. Jitsi is a trademark of 8x8, Inc., so confirm any branding or naming terms with the trademark owner before you publish a customized service.
How does 8x8's JaaS pricing compare with self-hosting?
Compare the total cost of each option, and ask 8x8 for current JaaS terms before you decide, because this page does not list them. JaaS is the hosted service from the team that builds Jitsi, so you pay for the service and avoid running servers, bandwidth and out-of-hours support yourself. Self-hosting moves those costs onto your infrastructure and staff, and it keeps the deployment inside your environment. Model both options with the same participant numbers, recording needs and support hours over the same period.
What determines how many servers a self-hosted Jitsi deployment needs?
Concurrent participants and the load they put on videobridges drive server count most. Jitsi scales horizontally by adding videobridges, and the scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Treat those figures as vendor starting points, and validate them against your own peak load. Bandwidth per bridge, the overlap of peak meetings, and whether you need bridges in more than one region also affect the count. Load test with your expected peak before you buy hardware.
Does recording add much to the cost of a Jitsi deployment?
Yes, recording usually adds a dedicated machine and storage, and the amount depends on how many meetings you record at once. Jibri records a conference by running Chrome in a virtual framebuffer and encoding with ffmpeg. Its README states that one Jibri supports only one recording at a time and should run on its own machine or VM, so each concurrent recording needs its own Jibri. Plan storage around file size and your retention policy, and count the recurring cost of keeping and deleting recordings.
How long does a self-hosted Jitsi rollout take to deploy?
The schedule depends on the written scope, so this page does not give a fixed duration. A rollout moves through phases such as planning, build, testing and cutover, and each phase depends on decisions made earlier. The biggest timing factors are network and firewall work, a TLS certificate for a proper domain, identity choices, and whether recording or SIP dial-in is in scope. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a phase-by-phase plan tied to that scope.
Can our own team run a Jitsi deployment without a partner?
A team with solid Linux skills can deploy a basic Jitsi Meet installation with the Docker or Debian quick start. The vendor warns, however, that building a scalable infrastructure is not a task for beginning administrators, and its scalable setup guide recommends configuration management tools such as Ansible or Puppet. The skills you need include Linux administration, nginx or Apache, Prosody and XMPP basics, DNS and TLS certificates, firewall and NAT configuration, and monitoring. Assess those skills honestly, and request a written scope if you want outside help.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Jitsi cost of ownership and editions, that means turning a self-hosted versus JaaS comparison into a written cost model your finance and IT leaders can check.
How we scope
- The written scope lists the cost lines to model: videobridge servers, bandwidth, recording storage, monitoring and internal staff time.
- We agree expected concurrent participants, recording needs and SIP needs before any cost comparison is finalized.
- Engagements are fixed-scope, so the deliverables and cost assumptions are agreed in writing before work starts.
How we build
- We model one-time setup costs separately from recurring hosting, bandwidth, storage and operations costs.
- We test the sizing assumptions against a reference deployment built from the Jitsi quick start or Docker setup.
- Each cost assumption is recorded with its source, so changes in usage or vendor pricing can be recalculated later.
How we hand over
- You receive a cost model with one-time and recurring totals, its assumptions and the drivers that move each figure.
- A quote checklist shows what to request from a JaaS provider and from your own infrastructure and staffing teams.
- Documentation records the edition comparison, sizing decisions and the questions still to confirm with 8x8 or your vendors.
How we support
- Ongoing support can be added as a retainer to refresh the cost model when user numbers, recording needs or hosting prices change.
- Periodic reviews can recheck bandwidth and capacity assumptions as meeting volume grows over time.
- Upgrade and support scope is defined separately, so you know what a retainer covers before it begins.

