Jitsi implementation plan and cost

What a Jitsi implementation involves

A self-hosted Jitsi Meet deployment is a set of cooperating services, not a single application. A web server (nginx or Apache) serves the web app, Prosody provides the XMPP signaling layer, and Jicofo acts as the conference focus that assigns participants to media routers. One or more Jitsi Videobridge instances carry the audio and video. Optional components add Jigasi for SIP dial-in and transcription, Jibri for recording and streaming, and extensions such as Etherpad and whiteboards. Each optional piece adds its own machine, storage or integration question, so list every component you need before you ask for a quote.

Organizations usually start this work for one of four reasons: they are leaving a hosted service, data location rules require meetings and logs to stay in specific infrastructure, internal policy limits which external tools staff may use, or the cost of hosted seats grows as headcount rises. Each trigger sets different requirements. A data location rule fixes where recordings and logs may live, while a cost trigger puts more weight on bridge sizing and bandwidth. Write the trigger down first, because it shows which parts of the plan will carry the most effort.

A pilot on one server shows that the web app loads and that a few people can talk. It does not show production readiness. A production rollout adds several videobridges, a valid domain certificate (the Jitsi handbook warns that self-signed certificates cause problems, especially with mobile clients), firewall rules for media traffic, and an authentication model such as JWT tokens or LDAP to control who can start meetings. Jitsi's scalable setup guide warns that building scalable infrastructure is not a task for beginning administrators and recommends configuration management tools such as Ansible or Puppet. Treat the pilot as a learning step and plan the production build separately.

Whether to build in-house or use a partner depends on whether your team already runs Linux services, reverse proxies, TLS certificates and container or configuration management tooling, and whether someone can own the platform after go-live. Internal IT time is often the most underestimated cost, because it recurs through upgrades and browser compatibility changes. Ask any partner, including DeployOpen, for a written scope that names the components, bridge count, authentication method, and who handles certificates, monitoring and upgrades. DeployOpen plans, implements and supports self-hosted platforms in your own infrastructure under fixed-scope terms agreed before work starts.

What the work includes and what you receive

A Jitsi rollout breaks into work packages that build on each other, from the host baseline through authentication, capacity and operations. Each package ends with a deliverable you keep, whether or not you later hand the operation to a partner.

Host and operating system baseline

Each server is prepared on a supported release, either Debian 12 (Bookworm) or newer, or Ubuntu 24.04 or newer, with OpenJDK 17 installed as the quick start requires. Confirm that your standard images, patch cadence and hardening baseline can be applied to these hosts before the build starts. The deliverable is a documented host build with versions recorded.

DNS and TLS certificate setup

Jitsi needs a real domain and a certificate issued by a trusted authority, because self-signed certificates cause audio and video problems, especially on mobile clients. Decide who holds the certificate renewal process and which DNS zone owns the meeting hostname. The deliverable is a DNS record set and a documented renewal procedure.

Container or package deployment

The rollout uses either the Docker setup, which separates web, Prosody, Jicofo, videobridge and optional containers, or the Debian and Ubuntu packages. Choose one method per environment and record why, since the upgrade and rollback steps differ. The deliverable is a deployed pilot environment and a configuration repository that reproduces it.

Firewall and port configuration

The core ports are 80/TCP, 443/TCP and 10000/UDP, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional items. Confirm with your network team which of these your perimeter, load balancers and proxies allow, and whether videobridges need a public address. The deliverable is a port matrix signed off by network and security owners.

Authentication choice and .env configuration

The Docker guide offers internal XMPP accounts, JWT tokens, LDAP, Matrix verification and a hybrid Matrix plus JWT mode, all set through the .env file. The handbook recommends JWT over the deprecated secure domain method for new installations. The deliverable is a decision record and the tested .env configuration for each environment.

Bridge sizing and horizontal scaling

Videobridges scale by adding more instances, and the scalable setup guide suggests starting points for the central server and each bridge. Your concurrent participant estimate and meeting profile determine how many bridges you need and whether the signaling server should be separated. The deliverable is a sizing worksheet and a load test report from the pilot.

Optional components

Etherpad, Excalidraw, Jibri recording, Jigasi SIP dial-in and transcription each add services, hosts and storage. Recording needs one Jibri per concurrent recording on its own machine, and SIP and transcription need their own backends. The deliverable is a scoped list of enabled components with the hosts and dependencies each one requires.

Monitoring and alerting

Operators need visibility into bridge load, container health, certificate expiry and failed joins before users report them. Agree which metrics go to your existing monitoring stack and who receives alerts out of hours. The deliverable is a dashboard set and alert rules mapped to the runbook.

Configuration backup and restore

Backups cover the .env files, container definitions, Prosody and Jicofo settings, certificates and any custom web interface files. A restore is only proven once someone has rebuilt a test host from those backups. The deliverable is a backup scope document and a restore test record.

Runbooks and admin handover

The operations runbook covers routine tasks, upgrade steps, certificate renewal, scaling and incident response, written for the staff who will run the service. A handover session transfers administration to your team and records open risks. The deliverable is the runbook, the configuration repository and a handover record signed by your IT owner.

Project phases and outputs

The rollout moves from agreed requirements and sizing to a tested build, a supervised pilot and a documented handover, with a named output at every phase.

Run requirements and capacity discovery
Your team and ours agree the expected concurrent participants, peak meeting times, meeting length, guest access, recording and SIP dial-in needs, and which networks and devices people use. We document these as a signed-off concurrency model that states the assumptions behind each number. Ask for the assumptions list to be part of the written scope, because every later sizing decision depends on it.
Decide architecture and sizing
Using the concurrency model, we choose the deployment method (Docker or Debian/Ubuntu packages), the number of videobridges, whether recording or SIP gateways are needed, and how the signaling server is placed. The output is a topology diagram that shows each component, its bridge count, the ports and public addresses it needs, and the failure assumptions. Your network and security teams review it before any build starts.
Build test and production environments
We build a test environment and a production environment in your infrastructure, using the same deployment method and configuration management so the two match. The test environment is complete when a multi-party call works across at least two networks and the videobridges are visibly distributed. Production is complete when the same checks pass, the firewall rules are confirmed with your network team, and the configuration is stored under version control.
Integrate authentication and certificates
We configure the chosen authentication method, such as JWT tokens from your identity system, internal accounts or LDAP, and set up a separate anonymous domain for guests if you need one. We install publicly trusted certificates for the meeting domain so browsers and mobile clients connect without warnings. The step closes when an authorized user can start a meeting, an unauthorized user cannot, and a guest can join through the intended path.
Run a pilot with real users
A limited group of real users holds meetings on the production build for an agreed period, across the devices and networks they actually use. We collect participant feedback and quality measurements, including audio and video failures, join problems and firewall issues. The pilot report lists each finding with its cause, the fix applied or planned, and whether it blocks cutover. Ask for the pilot exit criteria to be written into the scope before it starts.
Cut over and hand over
We move users, links and integrations to the new deployment as agreed in the cutover plan, and keep a rollback path until your team accepts the result. Handover includes a runbook covering routine operation, upgrades, certificate renewal, scaling steps and troubleshooting, plus training for the team that will run it. The engagement closes when your operators run a routine task from the runbook without assistance and the agreed acceptance checks are signed off.

What drives cost and duration

Each row names one driver of Jitsi implementation effort, explains why it changes the work, and gives a way to keep it under control.

Driver	Why it changes the work	How to keep it down
Concurrent participants and videobridges	Bridge count sets capacity and how many machines you build, patch and monitor. Scale bridges horizontally.	Validate the starting sizes from the scalable guide: 4 CPU and 8 GB for the central server, 4 or 8 CPU and 8 GB per bridge.
Recording with Jibri	Each Jibri handles one recording at a time and needs its own machine or VM.	Size Jibri hosts to peak simultaneous recordings, and plan storage and retention before go-live.
SIP dial-in and transcription	Jigasi adds a SIP gateway. Transcription runs on Google Cloud, Vosk or Whisper, each with different data handling.	Enable only the features users need, and confirm where audio is processed before choosing a backend.
Authentication choice	Internal accounts, JWT, LDAP, Matrix or hybrid each add identity integration and admin effort.	Choose JWT for controlled room creation. Avoid secure domain, which is deprecated for new installs.
Network topology, NAT and TURN	Public addressing and NAT decide media paths. Restrictive networks may need TURN or TCP fallback.	Map ports and NAT before the build. Test from restrictive networks during the pilot.
Certificate and DNS work	Audio and video need HTTPS with a trusted domain certificate. Self-signed certificates cause problems, especially on mobile.	Start DNS and certificate requests early, and include renewal in the operations runbook.
Number of environments	Each environment is a full stack of web, Prosody, Jicofo and bridges to build and maintain.	Limit environments to production plus one test copy, and manage configuration with Ansible or Puppet.
Branding, customization and custom integrations	Custom branding and integrations add work at design, testing, upgrade and support stages.	Use documented configuration options first, and list every custom integration in the written scope.
Internal IT time	Reviews, test calls, approvals and cutover checks take staff hours that are easy to underestimate.	Name reviewers and test dates in the written scope, and ask the quote to show internal time separately.

What usually goes wrong

Most Jitsi rollouts fail on decisions made early: certificates, network paths, sizing, recording, authentication and resilience. Each card names the prevention step and the team that should own it.

Invalid certificates break media

The Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and warns that self-signed certificates cause problems, especially with mobile clients. Prevention: issue a certificate from a trusted authority for the meeting domain before pilot users join, and test on desktop browsers and mobile apps. Owner: the platform team, with the PKI or certificate team.

Blocked ports and NAT settings

Users can join a meeting but receive no media when 443/TCP or 10000/UDP is filtered, or when a bridge behind NAT advertises the wrong address. Prevention: open the required ports end to end, plan 5349/TCP for TCP fallback, and set the bridge public IP explicitly. Owner: the network and firewall team, verified by the platform team from outside the office network.

Capacity sized from averages

A bridge sized for typical load fails during the busiest meeting hour, when many rooms run at once. Prevention: estimate peak concurrent participants from calendar data and size bridges for that figure, using the scalable setup guide's per-bridge CPU and RAM as a starting reference only. Owner: the IT lead, with input from teams that schedule large meetings.

Jibri sharing other roles

Jibri runs Chrome in a virtual framebuffer and encodes with ffmpeg, and its README states one recording at a time per Jibri. Hosting it on a machine that also runs bridges or other services causes dropped recordings and degraded meetings. Prevention: give each Jibri its own machine or VM and size one per concurrent recording. Owner: the platform team, with the business owner for recording policy.

Authentication changed late

Switching from anonymous rooms or the deprecated secure domain to JWT tokens after launch breaks existing room links, calendar invitations and user access at the same time. Prevention: choose the authentication method, guest domain and token issuer before the pilot, then test links and user access against that design. Owner: the identity team, with the application owners who issue tokens.

No plan for server loss

A single videobridge that fails ends every meeting on it at once, and participants have no path to rejoin. Prevention: deploy more than one bridge, document how users rejoin after a failure, and rehearse losing a bridge during a live test meeting. Owner: the operations or on-call team, with the platform team that owns the runbook.

In-house or partner: who does which part

This table shows, for each part of a self-hosted Jitsi Meet rollout, what organizations usually keep in-house, what they often hand to a partner, and the skills each part requires.

Work part	Usually kept in-house	Usually outsourced	Skills required
Requirements and capacity model	Decide who may host meetings, expected peak concurrent participants, recording and dial-in needs, and retention rules	Turn those answers into a written sizing model with bridge count and server specifications	Meeting usage analysis, network capacity planning, risk assessment
Linux and container administration	Own accounts, patch windows and access to the hosts after handover	Build the first hosts and document the Debian or Docker setup	Debian or Ubuntu administration, Docker, OpenJDK 17 operations
DNS and certificate management	Own the domain, DNS records and the decision to use the internal CA or a public CA process	Configure the HTTPS setup and verify that the certificate chain works in browsers and mobile clients	DNS administration, PKI, TLS troubleshooting
Network and firewall changes	Approve and apply firewall rules, public IP mappings and NAT policy	Specify the required ports and test media paths from representative networks	Firewall administration, UDP media troubleshooting, NAT concepts
Authentication integration with the identity system	Decide who may start meetings and own the identity source, groups and token signing keys	Configure JWT token authentication or LDAP settings in the environment file and test sign-in flows	Identity administration, OIDC or LDAP knowledge, secrets handling
Configuration management (Ansible or Puppet)	Own the repository, change approvals and secrets storage after handover	Write the first playbooks or manifests and the documented baseline configuration	Ansible or Puppet, infrastructure-as-code practice, Git workflows
Pilot and user communication	Choose pilot groups, communicate changes, and run the cutover decision	Prepare test scripts, pilot checklists and join-link validation	Change communication, end-user support, meeting-room and device testing
Monitoring and on-call	Run the on-call rota, incident process and escalation path after handover	Set up baseline health checks and document what each component reports	Observability tooling, incident response, Jitsi component knowledge
First upgrade cycle	Approve the maintenance window and own the post-upgrade acceptance tests	Run the first upgrade with a documented rollback, aligning all components to one stable release	Release tracking, Docker or Debian package upgrades, browser compatibility testing

How the plan changes by starting point

Moving from the free public instance or a JaaS account changes the plan from building a service to moving users and habits. The technical install is similar to a fresh deployment, so most of the added effort sits in cutover.

Effort driver: user communication, room links, calendar and app integrations, and a pilot before cutover. The detail sits in Jitsi migration.
Cost driver: confirm with 8x8 how long your hosted access continues and what export options exist for any account data.
Authentication: users who could start meetings freely on a public instance need an identity decision, covered in Jitsi SSO and identity integration.
Recordings and chat: anything held in the hosted service stays outside your deployment, so ask what can be exported and plan storage for it.
Compliance records: update the processing location and data flow documentation to reflect that media now runs in your infrastructure.

What you need to provide before work starts

Most schedule slips in a Jitsi rollout come from decisions the client has not made yet, not from the software itself. Before work starts, the client should name a business owner who can sign off scope and a technical owner who will hold the DNS, firewall and certificate tasks. Both names belong in the written scope as client dependencies, with a date by which each decision is expected.

Capacity and user decisions shape the architecture, so they come first. Confirm the expected number of concurrent participants and the peak meeting pattern, such as a daily stand-up spike or an all-hands event. List the user groups, state whether guests will join, and decide whether guests use a separate anonymous domain. These answers determine how many videobridges are needed and whether identity integration is in scope at all.

Network and certificate items are the next most common blockers. The client must provide a domain name with DNS control, a certificate process that can issue a valid certificate for that name (self-signed certificates cause problems, especially on mobile clients), public IP addresses for the videobridges, and a named person with authority to open ports 80/TCP, 443/TCP and 10000/UDP and to approve firewall changes. Also confirm the target OS and hosting location, since the quick start supports only specific Debian and Ubuntu releases.

Feature decisions affect hardware and vendor choices and should be settled in writing. Record whether recording (Jibri, which needs its own machine per concurrent recording), SIP dial-in or transcription (Jigasi) are wanted, and whether an identity source such as LDAP or an existing SSO is planned. Name the test and production environments, and reserve time on the calendar for internal reviewers to test and approve each stage.

Frequently asked questions

How much does a self-hosted Jitsi implementation cost?

DeployOpen does not publish a price list. A quote follows from the written scope, so the figure depends on what you ask us to build. The main cost components are planning, installation of the web server, Prosody, Jicofo and videobridges, certificate and network work, authentication setup and testing. Optional components such as Jibri recording or Jigasi SIP dial-in add their own effort. Ask for a quote that shows each component, who performs it, and what recurs. Server, bandwidth and storage charges come from your infrastructure providers and sit outside the implementation fee.

How long does a Jitsi implementation take?

Duration depends on scope, so no fixed figure applies to every team. The biggest variables are how many concurrent participants you expect, how many videobridges you need across networks or regions, whether recording, SIP dial-in or SSO must be connected, and how quickly your firewall, DNS and certificate requests are approved. A small pilot on one host moves faster than a multi-bridge deployment with identity integration. Your team's own review cycles and change windows also set the pace. Ask for a timeline in the written scope that lists the dependencies on your side.

Can our own IT team implement Jitsi without a partner?

Yes, for a small pilot. Jitsi publishes Docker and Debian or Ubuntu installation paths, and an experienced administrator can run a single-host trial. The Debian and Ubuntu quick start covers one host with OpenJDK 17 and specific ports open. A production deployment with several videobridges, a separate signaling server, TURN, token authentication and monitoring is different. The scalable setup guide warns that building scalable infrastructure is a task for experienced administrators and recommends configuration management tools such as Ansible or Puppet. Check your team's experience with Linux, TLS and networking before deciding.

What does our team need to provide for a Jitsi project?

Your side supplies the environment, the decisions and the people who will run Jitsi after handover. Expect to provide the domain name and DNS control, a certificate process your organization accepts, approval for the firewall ports Jitsi uses, the hosts or cloud accounts and their sizing, and the identity source if you plan token or LDAP login. You also need expected concurrency, meeting patterns, and any recording or SIP requirements. Name administrators who will patch, monitor and restart services. Confirm these inputs early, since they set the scope and the timeline.

Does self-hosting Jitsi remove the cost of JaaS?

No. Self-hosting replaces the hosted service fees with costs you carry directly: servers for the web server, Prosody, Jicofo and videobridges, bandwidth for media, storage for any recordings, monitoring, and staff time to patch and operate the system. JaaS is 8x8's hosted option, run by the team that builds Jitsi. Whether the total ends up lower depends on your participant volume, existing infrastructure and in-house skills. The cost of ownership topic walks through the one-time and recurring items and what to request in a quote.

Is Jitsi open source under Apache 2.0 without a vendor contract?

Yes. Jitsi Meet is licensed under Apache 2.0, according to its jitsi-meet GitHub repository, so you can install and run it without a license agreement with 8x8. Jitsi is a trademark of 8x8, Inc., so brand use is governed separately from the code license. Have your legal or procurement team review the license text and third-party components in your build, such as container images and libraries. Support from DeployOpen or an upgrade retainer is a separate agreement you can choose to buy.

How DeployOpen scopes, delivers and hands over Jitsi

DeployOpen plans, implements, hardens, documents and supports self-hosted Jitsi Meet inside your own cloud accounts, data centers or air-gapped networks. The plan and cost work starts with a written scope so that the phases, roles and cost drivers are agreed before any build begins.

How we scope

Engagements are fixed-scope, with the phases, deliverables and timelines agreed in writing before work starts.
The scope records expected concurrent participants, the number of videobridges and whether recording or SIP dial-in are needed.
The written scope also names the network, certificate and authentication work, along with the internal IT time your team must provide.

How we build

We deploy the web server, Prosody, Jicofo and Jitsi Videobridge components on the platform your scope names.
We configure HTTPS with a certificate for your own domain, since self-signed certificates cause audio and video failures on some clients.
We test joins from desktop browsers and mobile clients across the networks your users actually use before handover.

How we hand over

Handover includes documentation of the architecture, configuration, firewall ports and the decisions recorded during the scope.
We document the upgrade and rollback steps so your team can keep Jitsi components on matching stable releases.
Your staff receive a runbook covering monitoring, backups and the operational checks you agreed to own after go-live.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the implementation.
Retainer scope should be confirmed in writing, including which Jitsi components, environments and upgrade windows it covers.
Ask any provider to state in the quote who maintains the videobridges, certificates and recording hosts after go-live.