> Source: https://meetrix.io/blogs/jitsi-meet-commercial-support-checklist/ > Markdown copy of that page. Cite the URL above, not this file. Collaboration # Hiring Jitsi Meet Support: Vendor Checklist and Lock-In Risks [By Hiruna Kumara](https://meetrix.io/blogs/authors/hiruna-kumara/) • September 15, 2026 • 6 min read A note on who is writing this: Meetrix sells Jitsi Meet setup and support, so we are one of the vendors this checklist applies to. It is written from that side of the table. Most of the messy projects we get asked to take over didn't fail because Jitsi is hard. They failed because the customer didn't know what to ask for at the start, and found out at the first upgrade, outage or change of supplier. Jitsi Meet itself is free and open source, under the [Apache 2.0 licence](https://www.apache.org/licenses/LICENSE-2.0). When you hire someone, you are buying their judgment about architecture, security and operations, and you want to be able to check it. ## Ownership and access ### 1\. The servers run in your cloud account Ask for the deployment in your own AWS, GCP or Azure account, not the vendor's. You see the real infrastructure bill, you keep everything if the relationship ends, and access can be granted and revoked. Vendor-hosted setups can be fine for a trial; they are a trap for anything long-term. ### 2\. You get full administrative access Root or sudo on every server, the SSH keys or a way to add your own, DNS and certificate control, and admin access to any dashboards. We have met customers who could not log in to their own video servers because a previous developer kept the only key. Make access a delivery item, not a favour. ## Capacity and cost ### 3\. Capacity claims come with test evidence "Supports 500 users" means nothing without conditions. Ask how many participants were in one meeting versus spread across many, how many had cameras on, which instance types, and how it was measured. A vendor who has actually [load tested Jitsi](https://meetrix.io/blogs/jitsi-meet-load-testing/) can answer in a sentence. Our own numbers from [a 1000-user Jitsi test](https://meetrix.io/blogs/jitsi-1000-users-limit/) come with the conditions attached for exactly this reason. ### 4\. The monthly cloud bill is estimated up front Instance costs, bandwidth, recording storage and any always-on servers should be in the proposal. Bandwidth is the line most often left out, and recording roughly doubles the servers involved. [What it costs to self-host Jitsi Meet on AWS](https://meetrix.io/blogs/jitsi-meet-self-hosting-cost/) shows what a realistic breakdown looks like. ## Security defaults ### 5\. Room creation is locked down A fresh Jitsi install lets anyone who finds the URL start meetings on your servers. Authentication for hosts (JWT, LDAP or SSO), lobby for sensitive meetings, and closed internal ports should be the default, not an add-on. [Jitsi Meet security best practices](https://meetrix.io/blogs/jitsi-meet-security-best-practices/) lists the misconfigurations we see most, and it makes a good acceptance checklist. ### 6\. Users behind corporate firewalls can join Some networks block the UDP traffic Jitsi prefers. A TURN server reachable over TLS on port 443 fixes that, and a vendor should either include it or tell you plainly who will struggle to connect without it. [Jitsi Meet and firewalls](https://meetrix.io/blogs/jitsi-meet-and-firewalls/) explains the options. ## Upgrades and operations ### 7\. There is an upgrade plan Jitsi releases often, and security fixes arrive in new versions. The [Jitsi handbook](https://jitsi.github.io/handbook/docs/intro/) is the upstream reference a vendor should be tracking. Ask which version will be installed, how customizations are kept separate from upstream code so upgrades don't overwrite them, and how often upgrades happen. Heavily modified forks with no path back to upstream are the most expensive thing you can inherit. ### 8\. The infrastructure is reproducible If a server dies, can it be rebuilt the same way? Infrastructure defined as code, Terraform, Ansible or similar, plus a documented deployment pipeline for front-end changes, turns a disaster into a routine task. Hand-built servers configured over SSH turn it into archaeology. Our [Jitsi infrastructure-as-code service](https://meetrix.io/services/jitsi-infrastructure-as-code/) exists because of exactly this problem. ### 9\. Monitoring and support terms are explicit Who notices when a videobridge falls over at 2 a.m., and how fast do they respond? Get monitoring, alerting and response times in writing, along with what counts as an incident and what counts as a change request. ## Handover, exit and Jitsi Meet vendor lock-in ### 10\. You receive documentation and code you can hand to someone else This is where lock-in actually lives. Jitsi Meet's licence cannot lock you in, so anything that does is operational: servers you cannot reach, configuration nobody wrote down, a fork that has drifted from upstream. The handover test is simple: could a different competent engineer take over from the documents alone? That means an architecture diagram, server list with roles, ports and firewall rules, authentication setup, where every config file lives, how to deploy changes, credentials stored in a vault you control, and the source for every customization. If the answer is no, you are locked in whether or not the contract says so. Put the handover list in the contract Handover items that are "included" but not listed tend to arrive late or not at all. Attach the list above to the statement of work, and make final payment depend on it. ## Red flags in a quote | Red flag | Why it matters | | --- | --- | | A user count with no test conditions | The capacity is unknown, and so is the real cost | | Servers only in the vendor's account | You don't own your platform | | No mention of authentication | Anyone can use your servers | | "Custom version of Jitsi" with no upgrade story | Every future upgrade becomes a new project | | No documentation or code handover | Switching vendors means starting over | | Cloud costs "depend on usage" with no estimate | The bill arrives after you are committed | None of this requires you to be a WebRTC engineer. Ask the questions, ask for the answers in writing, and pay attention to which vendors answer them easily. ## Frequently Asked Questions Is Jitsi Meet free for commercial use? Yes. Jitsi Meet is open source under the Apache 2.0 license, so you can run and modify it commercially without paying for a license. What you pay for is the servers and bandwidth, and optionally a vendor to set it up, customize it and keep it running. What should a Jitsi Meet quote include? The architecture and how many concurrent users it is designed for, the server sizes and estimated cloud cost, which features are included (recording, authentication, branding), who owns the cloud account, what documentation and code you receive at handover, and what support and upgrades cost afterwards. Should the Jitsi servers run in my own cloud account? In almost every case, yes. Servers in your own AWS, GCP or Azure account mean you keep the infrastructure if you change vendors, you see the real cloud bill, and you control access. A vendor can still manage it through access you grant and can revoke. What are the most common Jitsi security misconfigurations? Letting anyone create rooms, exposing Prosody's internal ports to the internet, weak or shared JWT secrets, no lobby or passwords for sensitive meetings, and servers that haven't been updated for months. A good vendor closes these by default and documents how. How can I tell if a vendor's capacity claim is realistic? Ask how it was measured: how many participants, how many sending video, on which instance types, and with what bandwidth. A number with no test behind it is a guess. The honest answer usually comes with conditions attached. What causes Jitsi Meet vendor lock-in? Not the software, which is open source. It comes from servers held in the vendor's cloud account, undocumented hand-built configuration, customizations with no path back to upstream Jitsi, and credentials only they hold. Each one is avoidable at contract time. How does Jitsi make money? 8x8 owns Jitsi and funds it as part of its own paid products, while the code stays open source under Apache 2.0. Companies like ours earn from deployment, customization and support rather than from the software licence. ## Want Answers to This Checklist? Ask us every question on this page. Deployments in your own cloud account, documented handover, and upgrade paths that keep your customizations. [Commercial Support for Jitsi](https://meetrix.io/services/commercial-support-for-jitsi/) Meetrix Store Jitsi Meet Self-hosted video calls for 50 to 500 users [Deploy it](https://meetrix.io/store/jitsi-meet/) Meetrix Store New Deploy what this guide covers, pre-configured. - [Jitsi Meet Self-hosted video calls for 50 to 500 users](https://meetrix.io/store/jitsi-meet/) - [Coturn TURN/STUN for WebRTC, no per-minute relay fees](https://meetrix.io/store/coturn/) - [Mattermost Team chat, a self-hosted Slack alternative](https://meetrix.io/store/mattermost/) - [RustDesk Remote desktop AMI, a TeamViewer alternative](https://meetrix.io/store/rustdesk/) - [OpenVPN Encrypted remote access, no per-user fees](https://meetrix.io/store/openvpn/) - [Plane Issues, cycles and roadmaps, a Jira alternative](https://meetrix.io/store/plane/) [Browse all products](https://meetrix.io/store/)