Does self-hosting Google Meet with Jitsi cost less?
Self-hosting Meet with Jitsi cheaper is possible, but only if the decision is made at the Workspace level, not the meeting level. Meet is bundled into Workspace editions, so moving meetings to Jitsi rarely removes a line item on its own: the per-user Workspace fee stays until you change the edition or leave Workspace entirely. Jitsi Meet is licensed under Apache 2.0, so there is no per-user license fee for the software itself. What you pay for instead is the infrastructure, the people who run it and the skills to keep it patched. Before a renewal or residency review, ask your Google account team which edition your current seats use and what each feature you depend on requires, and compare that against the components below.
Self-hosting tends to cost more in three places. First, servers: a Jitsi deployment has a central server (Prosody, Jicofo and the web front end) plus one or more Jitsi Videobridge media routers. The Jitsi 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, and says videobridges scale horizontally by adding more. Second, bandwidth, which grows with the number of participants and video quality and is billed by your hosting provider or data center. Third, operations: patching, certificate renewal (the Jitsi handbook says HTTPS with a proper domain certificate is necessary for audio and video to work), monitoring and on-call coverage. These costs recur every month, while the initial build and integration are largely one-time. Ask any implementation partner for a written scope that separates those two groups.
Savings appear mainly when you stop paying for Workspace seats that exist only for Meet, or when a residency requirement forces a move that you would otherwise need to fund anyway. Price the alternative against the seats you could actually release, not the full edition list, and include the cost of recording storage, which Meet keeps in Drive but Jitsi keeps on your own servers through Jibri. Costs are also driven by how many people hold a meeting at the same time, so size for peak concurrency, not headcount. Because no Google price is in this comparison, get the current edition pricing from Google and the server, bandwidth and labor estimates from your own environment before deciding.
Which cost components change when you move meetings to Jitsi
This table compares each cost component of Google Meet with the matching component of a self-hosted Jitsi deployment, and marks whether it is one-time or recurring. Read it as a checklist: most rows do not remove a Workspace line item on their own, so the savings depend on which edition you pay for and what you already run.
| Cost component | Google Meet side | Self-hosted Jitsi side | One-time or recurring |
|---|---|---|---|
| Workspace edition or seat licensing | Meet is included in Workspace editions, so the cost is the per-seat edition fee, which covers email, storage and other apps too | No Meet license is needed, but Workspace stays in place unless you leave it; a cheaper edition is the realistic saving | Recurring |
| Meet recording storage in Drive | Recordings consume Drive storage, which is part of the edition's pooled storage | Recordings written by Jibri land on your own disk or object store, sized by retention policy | Recurring |
| Jitsi software licensing | Not applicable, as Meet is a Google service | Jitsi Meet is Apache 2.0 licensed, so there is no license fee for the software itself | One-time setup, recurring upkeep |
| Compute for web, Prosody, Jicofo and videobridge roles | Included in the service price | Virtual machines or hardware for the web front end, Prosody, Jicofo and one or more Jitsi Videobridge nodes, sized by concurrent participants | Recurring (hosting) |
| Bandwidth | Included in the service price | Media traffic from every participant passes through your videobridges, so egress from your hosting provider is a recurring cost to ask about | Recurring, usage-based |
| TLS certificates | Handled by Google | A valid domain certificate is needed because the Jitsi handbook says HTTPS is necessary for audio and video; a public CA certificate or an automated issuer is usually low cost, but confirm it with your CA | Recurring if purchased, often nil if automated |
| Implementation | Little or none, beyond calendar and admin setup | Planning, installation, authentication choice (JWT, LDAP or Matrix), network and firewall work, and testing across browsers and mobile clients | One-time, by scope |
| Migration | Not applicable | Replacing Meet links in calendars and room booking, moving recordings out of Drive and training users; scope depends on how many calendars and rooms you have | One-time |
| Support and upgrades | Covered by the Google support tier you buy | Patching, Jitsi release upgrades, monitoring and incident response, either staffed in-house or bought as a retainer with a named scope | Recurring |
| Internal skills | Admin console skills only | Linux, Docker or Debian packaging, networking and TLS operations; the skill cost is in staff time or an external provider | Recurring (staff time) |
When a cheaper edition or leaving Workspace actually saves money
Self-hosting Jitsi saves money only when a Workspace cost actually goes away. Meet is bundled into Workspace editions, so moving meetings to Jitsi on its own rarely removes a line item. The savings appear in one of two cases: the seats that exist only for Meet can be removed or moved to a cheaper edition, or the rest of Workspace (mail, storage, identity, calendar) is also replaced. Before modeling either case, list which users need Workspace for anything other than video, and which need Meet only. Confirm what each edition includes, including participant limits, recording and live streaming, from your own contract and Google's current Workspace documentation. Edition terms change, and the differences that matter to you are the ones in your agreement, not in a generic comparison.
Jitsi removes the per-seat meeting fee, but it replaces it with infrastructure cost that does not shrink when fewer people attend. A production deployment needs the web front end, the Prosody XMPP server, Jicofo and one or more Jitsi Videobridge instances, with HTTPS on a proper domain certificate. The central server and each videobridge are sized in CPU and memory, and the Jitsi scalable setup guide describes adding videobridges as load grows. Recording through Jibri and SIP through Jigasi add their own hosts. Those servers, the bandwidth they consume and the time your team spends patching and monitoring them are paid whether you have 50 users or 500. Ask any implementation partner for a quote that separates one-time setup from recurring hosting, bandwidth and support, and for the sizing assumptions behind each line.
The comparison works best as a break-even question: at what user count, and with which Workspace seats removed, does the recurring infrastructure and operations cost fall below what you pay today for Meet? Build the model with your own numbers, not with the seat price alone. Include the cost of retiring recordings and calendar integrations, which may keep Workspace seats in place for months. If most users also depend on Gmail, Drive and Calendar, the Meet line item will be small against the platform cost, and replacing Meet alone rarely justifies the change. Treat the decision as a whole-suite question, and document what you expect to save before committing to a migration.
What moves the Jitsi versus Meet comparison
Self-hosting moves cost from a per-seat line on a Workspace invoice to servers, bandwidth and people who run them. The cards below cover the drivers that push that balance one way or the other, and what to check against your own usage before comparing numbers.
Concurrent participants and videobridges
Peak concurrent participants, not total users, set how many Jitsi Videobridge instances you need. Jitsi's scalable setup guide says videobridges scale horizontally by adding more, and it suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Larger peaks raise the server count, but idle capacity is the main waste. Ask your team to measure real peak concurrency for a typical month before sizing.
Recording and storage volume
Jibri recording and streaming runs on separate hosts with their own CPU needs, and recordings accumulate on disk. Storage cost recurs every month and grows with recorded hours, retention periods and backup copies. Meet recordings already sit in Drive, so moving them out adds a storage line you did not pay for before. Decide which meetings must be recorded and how long files stay before you estimate storage.
Bandwidth from media relays and TURN
Video traffic leaves your network through the videobridges, so egress bandwidth is billed by your hosting provider and scales with participants and video quality. Users behind restrictive firewalls may need a TURN relay, which carries their media and adds bandwidth on top. Check your provider's egress pricing and the allowance included in each server plan, and confirm which TCP and UDP ports your firewall policy permits.
Availability and high availability needs
A single Jitsi host is cheaper but stops every meeting when it fails. Adding redundant front ends, a second videobridge pool or a standby central server increases compute and operations cost and needs a load balancing design. Meet inherits Google's availability, which you do not manage. Ask what uptime your business requires for meetings and whether a short outage during a planned window is acceptable.
Edition or seat count being removed
Savings only appear when you remove a paid line item. Meet is bundled into Workspace editions, so moving meetings alone may leave the Workspace bill unchanged. Savings come from a cheaper edition, fewer seats, or leaving Workspace entirely. Confirm with your Google account team which edition, seat count and add-ons would change, and whether a contract term or commitment limits the timing.
Docker and Debian operations skills
Jitsi runs as separate web, Prosody, Jicofo, videobridge and optional Jibri and Jigasi containers, or as Debian and Ubuntu packages. Someone must patch the operating system, renew HTTPS certificates, watch the videobridges and handle upgrades. Those hours are an internal cost or a retainer with an implementation partner, and they recur every month. Count the people who can cover on-call duties before comparing against a per-seat fee.
How to build the Jitsi cost model with your own numbers
This sequence turns a vague sense that self-hosting is cheaper into a side-by-side model of your current Meet spend and a self-hosted Jitsi estimate built from your own meeting profile. Each step produces a number you can defend in a budget review.
Inventory Meet seats and Workspace features in use
Start in the Google Workspace Admin console and list every user who holds a Workspace license, grouped by edition. Note which of them actually depend on Meet features that may affect the choice, such as recording to Drive, live streaming, dial-in numbers or larger participant limits. Confirm these limits against your own edition's current Google documentation, since they change. Separate the Meet entitlement from the rest of the Workspace bundle, because email, storage and identity will usually stay in place. The output is a table of seats per edition, with a column that marks the Meet features each group uses and a second column for the Workspace services that would stay if you moved meetings only.
Measure peak concurrent meetings and participants
Pull meeting reports from your admin tools or ask a sample of meeting hosts to log their calendars for a representative period. Record the highest number of simultaneous meetings and the largest participant count in each of them, separately for internal meetings, external meetings and all-hands events. Peaks matter more than averages, because the videobridge capacity you buy has to cover the worst hour. Mark which events are one-off so they do not inflate the steady-state sizing. The output is a short profile with three numbers per meeting type: peak concurrent meetings, peak participants per meeting and peak total participants across the platform.
Size the central server and videobridges
Use the Jitsi scalable setup guidance as your starting point. The handbook suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge, and notes that the default install is already set up for horizontal scaling. Map your peak profile onto a count of videobridges, then add at least one spare so a single failure does not end every meeting. Test the sizing with a load test in a staging environment before committing to hardware or cloud instances, because the bridge count that works for your traffic is an empirical question. The output is a bill of materials for the central server and a number of videobridges, plus a note of the test result that supports it.
Estimate bandwidth from your meeting profile
Multiply your peak participants by the video quality you plan to allow, then split the result into the traffic that enters and leaves each videobridge and the traffic that leaves the datacenter toward users. Ask your network team for the committed rate of your current internet link and for any per-GB charges from your cloud provider, because egress is often the cost that surprises teams. Include the traffic for any Jibri recording or streaming, which adds a stream per recording. Confirm the per-GB or per-Mbit rates in writing with each provider rather than assuming them. The output is a monthly transfer estimate in gigabytes and a peak bandwidth figure in Mbit/s, both tied to the profile from the previous step.
Add recording and storage capacity
Decide which meetings will be recorded and for how long you will keep the files. If you use Jibri, each recording needs disk space on the machine that captures it and then storage for the finished file in your object store or file system. Multiply expected recorded hours by your planned bitrate to get a storage figure, and add backup copies if your retention policy requires them. Note that storage and backup usually recur monthly, while the capture hardware is a one-time purchase. Ask your storage team for the unit price of the target system and for the cost of restoring from backup. The output is a retention schedule and a recurring storage line item for the model.
Price your labor and hosting in your own quotes
Get written quotes for the infrastructure you will run and for the people who will run it. Cover the cloud or datacenter capacity for the central server, the videobridges, the TLS certificate and DNS, monitoring and backups. For labor, separate the one-time work of building, integrating with your identity provider and migrating users from the ongoing work of patching, upgrading and answering support requests. If you engage an implementation partner such as DeployOpen, request a fixed-scope quote from a written scope and compare it with internal effort, since DeployOpen does not publish prices. Ask each provider to state what is included, what is billed separately and what drives the price up. The output is a set of quotes, each tagged one-time or recurring.
Compare one-time and recurring totals over your chosen period
Set the comparison period first, such as the length of your current Workspace renewal term, and keep it the same for both options. Sum the one-time costs for the Jitsi build, such as setup, integration, hardware and migration, and the recurring costs for hosting, bandwidth, storage, support and staff time. Subtract the Meet costs that would actually disappear, which may be only part of the seat price if other Workspace services remain. Then run the model again with the peak load increased, with one videobridge removed and with a higher egress rate, to see which assumption moves the result most. Record the assumptions beside the result so the figure can be checked later. The output is a comparison table with a clear statement of what Meet spend would be removed and what would be added.
Who runs Jitsi after go-live and what that costs
The cost that outlasts the project is operations. After go-live, someone on your team or a retained partner owns the recurring work: patching the operating system and the Jitsi packages or Docker images, renewing and rotating the HTTPS certificate (the Jitsi handbook says HTTPS with a proper domain certificate is necessary for audio and video to work), watching videobridge capacity as meeting volume grows, and upgrading when a new stable build appears. Jitsi Meet stable builds are tagged by build number, such as stable/jitsi-meet_11248, published September 14, 2026, so confirm the upgrade cadence you will commit to and who tests each release before it reaches users. Incident handling also needs a named owner, covering a failed Prosody or Jicofo service, a bridge that drops media, or a recording container that stops, along with the on-call hours your organization expects.
Labor is the largest recurring component, and it is usually paid to in-house platform engineers or to a support contract, not to a software vendor. Ask any quote to split one-time work (installation, authentication design, load testing, documentation) from recurring work (monthly patching, certificate operations, capacity reviews, upgrade testing, incident response). Also ask what the scope includes for Jibri and Jigasi if you plan to record, stream or bridge SIP calls, since those add containers to maintain. Hosting, bandwidth and backups recur as well, and they rise with peak concurrent participants.
Jitsi as a Service from 8x8 is the hosted alternative. It moves most of this operational work to the vendor, so the decision becomes a comparison of two recurring models rather than a comparison of a license against a server. Put the hosted subscription and your self-hosted labor, infrastructure and support on the same monthly or annual basis, using the same user counts, peak concurrency, recording needs and data residency requirements. Confirm with 8x8 where its service runs, what it logs, and what happens to recordings, because those answers matter as much as the price.
Questions buyers ask about Meet and Jitsi costs
Does moving from Google Meet to Jitsi remove a Workspace line item?
Usually not on its own. Meet is included in Google Workspace editions, so the per-user fee is tied to the edition, mail, storage and identity services you also use. Dropping Meet only saves money if you also move to a cheaper edition or leave Workspace entirely. Before modeling savings, list which Workspace services your users depend on, then check your current invoice and your contract terms with Google to confirm which edition and seat count you actually pay for.
How much effort does a self-hosted Jitsi deployment take?
The effort depends on scope, mainly how many users you have, whether you need recording or SIP dial-in, how you handle authentication and how many videobridges you run. A basic install needs a server with a valid domain name, HTTPS and open ports, and the Jitsi handbook lists the components involved: the web front end, Prosody, Jicofo and Jitsi Videobridge, with Jibri and Jigasi optional. Scaling adds videobridges, and the handbook suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Ask your engineers to size a pilot against your real meeting profile.
Can our internal team run Jitsi without outside help?
Often yes, if you already run Linux servers, reverse proxies, certificates and container platforms. The skills that matter most are DNS and TLS certificate management, firewall rules for UDP media traffic, identity integration and monitoring. HTTPS with a proper certificate is required for audio and video to work, so a team with no certificate process should plan for that first. Be honest about capacity: someone must own patching, upgrades and incident response after go-live, and that work competes with other priorities. Consider a fixed-scope implementation for the build and a retainer for upkeep if the in-house team is thin.
What does the project need from our side to start?
Start with decisions and access rather than hardware. You need a named business owner, a target hosting location (your cloud account, data center or air-gapped network), a domain name and certificate approach, and a list of identity sources such as internal XMPP accounts, JWT tokens or LDAP. You also need firewall changes approved for the required ports, a decision on recording storage and a rollout group. The Jitsi Docker guide configures these choices through a .env file, so the platform team needs the answers before deployment starts.
How long does a Jitsi rollout take?
It depends on scope. A single-domain pilot with internal accounts is far simpler than a rollout with SSO, recording, SIP dial-in, multiple regions and migration of calendar links. The factors that move the timeline most are authentication design, approvals for network and certificate changes, the number of user groups and how much testing you require before go-live. Ask any implementation partner for a written scope with deliverables and milestones, and ask your own teams to confirm approval lead times. No fixed duration applies to every organization.
What drives the server cost of self-hosted Jitsi?
The main drivers are concurrent participants, video quality, the share of meetings that use video rather than audio, recording and streaming load, and how many regions or sites you serve. Jitsi scales horizontally by adding videobridges, so cost grows with peak concurrency rather than with total users. Bandwidth is often the least visible item: media traffic leaves your network or cloud account, and egress charges depend on your provider. Ask your provider for the egress price and ask your engineers to load-test a realistic peak before buying capacity.
How does recurring upkeep differ from the one-time setup cost?
Setup is largely one-time: design, installation, identity integration, testing, documentation and migration of links and recordings. Recurring costs include servers and bandwidth, certificate renewal, security patches, Jitsi upgrades, monitoring, backups, on-call coverage and staff time. Upgrades are where many self-hosted estimates fall short, because each release needs testing against your identity and recording setup. Ask any quote to separate one-time work from a monthly or annual support scope, and to state which upgrades and testing are included.
How DeployOpen scopes a fixed-price Jitsi cost model and rollout
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Google Meet cost comparison, we start with a written scope that separates the Workspace spend you can actually remove from the servers, bandwidth and operations you would take on.
How we scope
- Inventory which Workspace editions, add-ons and Meet features your organization pays for today.
- Model Jitsi servers, bandwidth and staff time as separate cost components, each with an owner.
- Confirm recording, guest access and identity needs before sizing the Jitsi deployment.
- Agree deliverables, timelines and exclusions in writing before any build work starts.
How we build
- Deploy the web front end, Prosody, Jicofo and Jitsi Videobridge in your environment, using Docker or Debian and Ubuntu packages.
- Configure HTTPS with a proper domain certificate, since self-signed certificates cause audio and video problems.
- Set up JWT token authentication and a separate anonymous domain for guests, rather than relying on the deprecated secure domain method.
- Test load on each videobridge and document the horizontal scaling plan against measured meeting use.
How we hand over
- Deliver architecture notes, runbooks, configuration files and the sizing model used in the cost comparison.
- Document backup, upgrade and certificate renewal procedures so your team can run the platform.
- Provide a cost ledger that shows which lines recur and what drives each one up or down.
- Walk your operations and service desk staff through incident handling before the handover closes.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers.
- Track Jitsi release updates and plan upgrades in agreed maintenance windows.
- Re-run the cost model when user counts, recording volume or bandwidth contracts change.
- Confirm with your own auditors which evidence they need, since DeployOpen prepares evidence but does not issue audit reports.
