Jitsi security hardening guide

Why Jitsi security hardening starts with who can create a room

For a Jitsi Meet deployment that carries confidential meetings, hardening starts with deciding who can create a room, because every other control depends on who is allowed into a conference. Hardening, in this sense, covers room creation, TLS certificates, transport encryption, container isolation, open ports and patch cadence, and the order matters: a permissive room creation policy undermines a well-configured network. Many teams take up this work after the stack is already running. In a default configuration, a room exists once the first person opens its URL, so the first decision is whether that should stay true for your organization. Confirm the behavior on your own build before you change anything.

The work is harder than it looks because default settings favor easy joining. Jitsi Meet is designed so that a participant can open a link and start talking, and each setting you tighten adds friction for someone. Encryption also has limits that you need to explain to stakeholders. All Jitsi Meet audio and video is encrypted on the network with DTLS-SRTP, but the videobridge decrypts packets in memory to route them. End-to-end encryption is available in Chromium 83 and later browsers and the Jitsi Electron client, and it covers audio, video and screen sharing only. It does not extend to chat or polls. A Jitsi stack is also several components, including the web server, Prosody, Jicofo and one or more videobridges, and each one needs its own secure configuration.

Start by choosing an authentication model for room creation. The Jitsi handbook marks the older secure domain method, which uses usernames and passwords to create rooms, as deprecated for new installations. It recommends JWT token authentication instead, where your identity system issues a signed token that identifies the user and their moderator rights, with a separate anonymous domain for guests. For Docker deployments, the .env file controls the options, which include internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode. Write the decision down as a room creation policy that states who may create rooms, who may join as a guest, who may moderate and how guests are admitted. Then test it from outside your network with an unauthenticated browser session, and confirm that the attempt fails the way the policy says it should.

Hardening Jitsi is configuration and verification work carried out inside your own infrastructure, whether that means your cloud accounts, your data centers or an air-gapped network. DeployOpen plans and implements these settings, runs security testing against them and documents the results so your team and independent auditors can review them. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that work, and they will ask for evidence of how room creation, encryption and access were configured and tested. Before any work begins, ask for a written scope that names each component, each setting and each test.

Which Jitsi components carry the security settings

A Jitsi Meet deployment is several services, and each one holds settings that affect who can join, what traffic they can reach and how media is protected. Hardening starts with knowing which component owns each setting, so changes are made in the right place and verified there.

Web server and HTTPS

The web server, either nginx or Apache, serves the Jitsi web app and terminates HTTPS for every browser that joins a meeting. Browsers and mobile clients need a certificate issued for your domain, since self-signed certificates cause failures, especially on mobile devices. Check the TLS configuration, the certificate renewal process, and that plain HTTP on port 80 only redirects to HTTPS. Confirm the certificate chain with each client type you support.

Prosody and account authentication

Prosody is the XMPP server that holds accounts and decides who can authenticate. Depending on configuration, it can validate internal XMPP accounts, JWT tokens, LDAP directories or Matrix-based verification. Review which authentication modes are enabled, how guest access is separated from authenticated access, and whether the older secure domain method is still in use, since the handbook marks it as deprecated for new installations.

Jicofo and room creation

Jicofo, the conference focus, creates rooms and assigns participants to videobridges. It enforces the policy on who can start a meeting, so it is the component to test when you restrict room creation. Confirm that an unauthenticated visitor cannot create a room on the authenticated domain, and that guest access works only on the domain and paths you intend to expose.

Videobridge media routing

Jitsi Videobridge routes audio and video between participants. Media on the network is encrypted with DTLS-SRTP, and the bridge decrypts packets in memory to route them, according to the Jitsi security documentation. Hardening here means keeping the UDP media port reachable, setting the public address correctly for NAT, and documenting that the bridge can access decrypted media during a meeting, which bears on what end-to-end encryption does and does not cover.

Docker containers and the .env file

The official Docker setup runs web, prosody, jicofo and jvb as separate containers, with jigasi and jibri added when enabled. Since release stable-11146 the containers run rootless with read-only filesystems. Most authentication and feature settings live in the .env file, so restrict its file permissions, keep its secrets out of version control, and confirm that every container image matches the release you tested.

Jibri and Jigasi scope

Jibri and Jigasi each widen the attack surface and should be assessed separately from the core stack. Jibri runs a browser and encoder to record or stream, and its README states that one Jibri supports one recording at a time, so it belongs on its own machine or VM. Jigasi bridges SIP dial-in and transcription. Give each one its own network rules, credentials and data retention decisions.

Which room creation and authentication model fits your meetings

This table compares the ways Jitsi Meet can control who creates rooms, from internal XMPP accounts to JWT, LDAP, Matrix and the deprecated secure domain method. Read each row for when the option fits, what it costs to run, and what it leaves open. The main takeaway is that the Jitsi handbook recommends JWT tokens with a separate anonymous domain for guests, and marks the secure domain method as deprecated for new installations.

Option	When it fits	Operational cost	What it leaves open
Internal XMPP accounts	Small teams with a few administrators who can manage accounts directly on the Prosody server	Account creation, password resets and removal are manual; offboarding depends on someone remembering to act	No link to your identity system, so joiners and leavers are not synchronized with HR or directory changes
JWT tokens from your identity system	Organizations with an existing identity provider that can issue signed tokens for meeting access, and the handbook's recommended pattern	Integration work in your identity system, plus protection and rotation of the token signing key and a plan for expiry	Token lifetime, key compromise response and guest handling need explicit design; confirm the claim format with the handbook before building
LDAP	Organizations whose users already authenticate against a directory such as Active Directory and need password checks to match	Directory service account, connection security settings and monitoring of directory availability	Group membership rules, nested groups and disabled-account handling must be tested; confirm supported directory schemas for your version
Matrix user verification	Teams that already run a Matrix homeserver and want users to be verified against it	Dependency on the Matrix homeserver's uptime, user lifecycle and federation settings	Meeting access follows the homeserver's policies, so changes to those policies affect Jitsi access; confirm the setup steps in the Docker guide
Hybrid Matrix plus JWT	Deployments that need Matrix verification for members and token-based access for specific cases such as integrations	Two authentication paths to configure, test and monitor, plus the Matrix and token signing dependencies together	More moving parts increase the chance of misconfigured access; each path needs its own test cases
Secure domain (username and password room creation)	Legacy installations that already run it; the handbook marks it deprecated for new installations	Maintenance of an older method with less current guidance, and migration work later	Deprecated status means fewer current references and an expected move to JWT; plan a migration path rather than new rollouts
Separate anonymous domain for guests	Meetings where external participants join without an account while members still require authentication	Second virtual host to configure and keep consistent with the main domain's settings	Guests can join any room they know the name of unless room names and lobby settings are controlled; confirm lobby behavior for your version

How to harden a Jitsi deployment in the right order

This sequence moves a Jitsi Meet deployment from a base install to a locked-down service in an order where each control depends on the one before it. Each step ends with a check you can run before moving on, so problems surface while they are still cheap to fix.

Install on a supported OS with OpenJDK 17
Start from a supported operating system. The Debian and Ubuntu quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, and it requires OpenJDK 17. The engineer building the server installs the base packages on a clean host, pins the Java version, and records the exact OS and package versions in the build documentation. Confirm the OS release and Java version against the current handbook before you begin, because requirements change between releases. Check: the Jitsi services start cleanly, the web app loads over the local network, and the Java runtime reports version 17 to every service that uses it.
Issue a domain certificate and confirm HTTPS
Obtain a certificate issued for the public domain that users will type into their browsers, from a certificate authority your clients already trust. The Jitsi handbook states that 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. Configure the web server with the certificate and key, then confirm the chain is complete. Check: open a meeting in a current desktop browser and on an iOS and an Android device on a mobile network, and confirm there are no certificate warnings and that audio and video start. Repeat this check after every certificate renewal.
Choose and enforce the authentication mode
Decide how a person proves identity before they can create a meeting. The Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, configured through the .env file. The handbook marks the older secure domain method, which uses usernames and passwords for room creation, as deprecated for new installations and recommends JWT token authentication. The security or identity lead should confirm which mode matches the directory the organization already runs. Check: an unauthenticated browser session cannot create a room on the main domain, and a test account with valid credentials or a valid token can. Look up current configuration keys in the official handbook rather than copying values from this page.
Disable open room creation on the main domain
Once authentication is enforced, confirm that the main domain does not let anonymous visitors create rooms. This step is separate from authentication because a configuration can require login in one place while a related setting still allows open access. The engineer reviews the web interface and the XMPP configuration for the main domain and removes any path that lets an unauthenticated participant start a conference. Check: from a clean browser profile with no session, try to start a meeting by typing a new room name on the main domain. The attempt should be refused, and the refusal should appear in the server logs. Record the test result in the change file.
Separate guest access onto an anonymous domain
Guests who should join a meeting without an account need a route that does not touch the authenticated main domain. The handbook recommends a separate anonymous domain for guests. The engineer configures the anonymous domain, decides which meetings can be joined from it, and documents who is allowed to issue guest links. Guests reach a room through the anonymous domain, and the main domain stays protected by the authentication settings from the earlier steps. Check: a guest joins a meeting from outside the corporate network using the anonymous domain, and the same guest cannot reach the authenticated main domain or create a room there.
Run containers rootless with read-only filesystems
This step applies to Docker deployments. Since release stable-11146, the official Docker containers run rootless with read-only filesystems. The engineer confirms the release in use is at or after stable-11146, checks the container user and filesystem settings in the compose file, and makes sure any writable paths are the ones the services need. Hosts running Debian packages do not get this protection from the container runtime, so the team should apply equivalent host hardening there. Check: each container reports a non-root user, a write attempt to a read-only path fails as expected, and the meeting still works end to end.
Restrict open ports to the required set
Open only the ports the deployment needs. The quick start requires 80/TCP, 443/TCP and 10000/UDP. It lists 5349/TCP for TCP fallback and 3478/UDP for STUN as optional, so open them only where your network design needs them. The network engineer writes the firewall rules at the perimeter and on the host, and documents the reason for each optional port. Check: a port scan from outside the network shows only the expected ports open, and a participant on a restrictive network can still join. Confirm the current port list against the official handbook before finalizing the rules.
Set a patch cadence for matching builds
Jitsi Meet, Prosody, Jicofo and the videobridges work as one system, so they should run on matching stable builds. Stable releases are tagged by build number, such as stable/jitsi-meet_11248. The operations owner sets a written patch cadence, records which build each component runs, and tests each update in a staging environment before it reaches production. Ask the implementation partner, if one is involved, to state how it tracks upstream stable releases and how it reports version drift. Check: every component reports the same stable build, and a test meeting passes on staging before the production update is approved.

Where Jitsi end-to-end encryption stops and what to do about it

Jitsi encrypts media on the network, but the videobridge still handles decrypted packets and the server operator sits inside the trust path. The cards below cover where that boundary lies, which access decisions and secrets matter most, and which data stores sit outside end-to-end encryption.

Transport encryption and the videobridge

All Jitsi Meet audio and video is encrypted on the network with DTLS-SRTP. The videobridge decrypts packets in memory to route them, and according to the project it never stores them. Confirm this behavior against the release you deploy, and treat the bridge host as a system that sees media in clear while it runs.

End-to-end encryption coverage limits

End-to-end encryption is offered in Chromium 83+ browsers and the Jitsi Electron client, and covers audio, video and screen sharing only. Chat and polls are not covered. Before promising confidentiality to users, test an E2EE meeting with each browser and client your staff use, and state the excluded features in your usage policy.

Server operator trust boundary

Decide whether the people who run the Jitsi servers sit inside your trust boundary. If an outside operator or hosting provider manages the infrastructure, they control the code, configuration and host access that could expose meetings. Write this decision into the design record, and align it with your data classification for meeting content.

Room access and E2EE enablement

Control who can create rooms and join them, and decide when E2EE is turned on for a meeting. Token-based authentication, covered in the Jitsi handbook, ties room creation to your identity system. Test that E2EE is enabled for the meetings where it is required, since participants must be able to use a supported browser or the Electron client.

Chat and shared notes exposure

Optional Etherpad shared notes and in-meeting chat fall outside end-to-end encryption, so their content is readable by the server. Disable Etherpad unless it is needed, restrict the features that carry sensitive text, and set a retention rule for any notes that remain. Confirm the exact behavior of each optional component in your deployed version.

Recordings and transcripts as data stores

Jibri recordings and Jigasi transcripts are separate stores that hold meeting content outside the live session. Define where they are written, who can read them, how long they are kept and how they are deleted. Each one needs its own access control and backup review, because end-to-end encryption does not follow the content into these files.

Secrets in the .env file and JWT keys

The Docker setup reads its configuration, including authentication settings, from a .env file, and JWT tokens are signed with a shared secret. Restrict file permissions, keep the file out of version control, and rotate signing keys through a documented process. Anyone with the signing key can mint tokens that grant room access.

Prosody and Jicofo admin access

Prosody is the XMPP server and Jicofo manages conference focus, so their administrative interfaces control accounts and rooms. Limit access to these interfaces to named administrators on a management network, and log changes. Confirm which admin endpoints your release exposes and close any that are not required.

What drives the hardening effort and how to keep it down

This table lists the factors that most change how much work Jitsi hardening takes, with the reduction approach for each. Read it as a checklist for your written scope: the more of these factors are unresolved when work starts, the more time goes to decisions and rework rather than configuration. Ask your partner to state which drivers they have assumed and how each would change the quote.

Driver	Why it changes effort	How to keep it down
Identity sources and JWT issuance	Each identity source (internal XMPP accounts, LDAP, Matrix, or JWT issued by your own system) adds configuration, testing and user documentation. Whether an existing system must issue JWT tokens decides if new identity work is needed at all.	Pick one authentication mode for the first release. Reuse your existing identity tooling to issue JWT tokens rather than building a new login flow. Confirm the token claims and the anonymous guest domain in the written scope.
Number of environments	Test, staging and production each need their own domain, certificates, .env settings and access controls. Hardening steps repeated per environment multiply the verification work.	Build one configuration template and apply it to every environment with a configuration management tool such as Ansible or Puppet, changing only environment variables. Keep the test environment close to production so findings carry over.
Guest and external participant access	Allowing guests means a separate anonymous domain, stricter room creation rules and extra testing of join flows for people outside your directory. Open rooms widen the review of who can start and join meetings.	Decide up front which user groups may create rooms and which may only join. Limit guest access to a defined set of rooms or a single anonymous path, and write the rule into the scope so testing covers it.
Optional components: Jibri, Jigasi and Etherpad	Each enabled component adds a container, network path, data store or recording storage that must be scoped, patched and tested. Jibri needs its own machine or VM, and recordings add retention and access questions.	Enable only components with a confirmed business need. Scope each one in a separate phase with its own acceptance checks. Put Jibri on a dedicated host from the start rather than retrofitting it later.
Certificate management and DNS	Jitsi needs HTTPS with a proper domain certificate for working audio and video, and self-signed certificates cause problems, especially with mobile clients. Slow certificate issuance or manual DNS records add delay at every renewal.	Confirm early who issues and renews certificates and how DNS changes are made. Use an automated certificate process where your policy allows it, and record the renewal procedure as part of the handover.
Firewall change control lead times	Ports 80/TCP, 443/TCP and 10000/UDP must open, with 5349/TCP for TCP fallback and 3478/UDP for STUN optional. Each rule that goes through a formal change board can hold up testing.	Submit the full port list as one change request with a clear justification and a rollback step. Pre-agree a change window for the pilot and production cutover so testing is not blocked by the next scheduled review.
Compliance evidence you must produce	Assessors usually ask for configuration baselines, access reviews, patch records and logs that show controls work. Evidence that is gathered after the fact takes more time than evidence produced during the build.	Agree the evidence list in writing before work starts, then have the build produce it, such as versioned configuration files, change records and test results. DeployOpen prepares evidence for assessment, but independent auditors issue any audit report.
Configuration method and skill level	The scalable setup guide warns that building scalable infrastructure is not a task for beginning Jitsi administrators and recommends configuration management tools such as Ansible or Puppet. Manual hardening on each host is slow to repeat and hard to verify.	Standardize on one deployment path, either the Docker setup or the Debian/Ubuntu quick start, and script all hardening settings. Confirm that your internal team can run and review the chosen tooling after handover.

How hardening differs between Docker, Debian and scaled deployments

The official Docker setup runs the web, prosody, jicofo and jvb containers as separate services, with jigasi and jibri available as optional containers. From stable-11146 onward, the containers run rootless with read-only filesystems, so much of the container-level hardening is already in place. Your work shifts to the host and the network around it.

Native: containers run rootless and use read-only filesystems, per the Docker guide for stable-11146 and later. Confirm that the release you pin includes both behaviors before you rely on them.
Operator-added: host firewalling that limits inbound traffic to 80/TCP, 443/TCP and 10000/UDP, plus 5349/TCP and 3478/UDP only if you enable TCP fallback or STUN.
Operator-added: patching the Docker host operating system and the Docker engine, and updating images when new stable tags are released.
Operator-added: forwarding container logs to your central log platform. Confirm your Docker logging driver configuration before assuming logs leave the host.
Videobridge settings: the public address that jvb advertises must match the host's externally reachable address, and the UDP media port must reach the container. Confirm the variable names in the current Docker guide.

Check that each running container reports a non-root user and a read-only root filesystem, and that the host firewall matches the ports the bridge actually publishes.

How to test that Jitsi hardening holds and fails safely

The purpose of this section is to give the team a short set of checks that show each hardening control is working as intended, and a failure test that shows what happens to a live meeting when a component stops. Run these checks against a staging copy of the deployment first, then repeat the ones that matter after each upgrade or configuration change. Record the date, the Jitsi Meet build tag, the configuration values in the .env file and the result of each check. Frame this as a set of checks your team runs and keeps on file, not as an audit. An independent assessor may later review the evidence, but these checks do not produce an attestation.

Start with access control. From a browser with no session, try to create a room on the main domain. The check passes only if the deployment refuses to start the meeting for an unauthenticated user. Then, from a guest session on the anonymous domain, try to open a room that is meant to be restricted to authenticated users, and confirm the guest is refused. Next, generate a JWT with an expired timestamp, another with a wrong signing secret, and another with an audience or room claim that does not match the requested room. Each should be rejected. Confirm the expected JWT settings in the .env file match the token issuer your identity team operates, because a mismatch can look like a working login when it is not.

Check transport and certificates next. Open the meeting URL on a desktop browser and on at least one iOS and one Android device, and confirm the browser shows a valid certificate chain for the public hostname without warnings. The Jitsi handbook notes that self-signed certificates cause problems, especially with mobile clients, so a warning on a phone is a failed check even if the desktop looks fine. For the network side, scan the public address from outside your network and confirm that only the ports you intended to publish respond. The Debian and Ubuntu quick start lists 80/TCP, 443/TCP and 10000/UDP, with 5349/TCP and 3478/UDP as optional. Any other open port is a finding to explain or close. Confirm whether your firewall also filters the internal management interfaces.

Check the container posture on the host that runs the Docker stack. Confirm that each service runs as a non-root user and that its root filesystem is read-only, using the container runtime's inspect output and a write test inside each container. The Docker guide states that these defaults apply from stable-11146 onward, so confirm your deployed tag is at or after that release and record it. For encryption, confirm that DTLS-SRTP is active on the media path and that end-to-end encryption can be enabled in a test meeting in a supported browser or the Electron client. Then write down what it does not cover: as described on the Jitsi security page, end-to-end encryption is limited to audio, video and screen sharing, and it does not cover chat or polls. Anyone who signs off on confidentiality should be able to explain that gap in one sentence.

Finally, run a failure test in a test meeting with at least three participants. While the meeting is active, stop one videobridge container, then restart it, and record what each participant sees: whether media drops, how long it takes to recover, whether participants are moved to another bridge, and whether they must rejoin. Repeat the test with the signaling server stopped, since the web server, Prosody and Jicofo are single points of failure in a basic deployment. Record whether the failure is visible, whether any data is exposed in logs, and whether the system returns to a clean state. Results from this test decide what your high availability design and incident runbook must cover, so keep the recordings with the other check results.

What to monitor, patch and document after hardening

Hardening a Jitsi Meet deployment is a one-time change, but the controls it creates decay without routine work. The four groups below cover what to watch, how to keep components current, what to back up and what to write down so that the baseline stays true after the engineers who built it move on.

Monitoring certificates and access signals

Watch the expiry date of the certificate on the web server, since the Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video and that self-signed certificates cause problems, especially on mobile clients. Track failed authentication attempts against your chosen method, whether internal XMPP accounts, JWT tokens or LDAP, so that repeated failures on room creation or login are visible. Confirm alert routing for both before go-live.

Monitoring ports and container health

Compare the listening ports on each host against the approved list, which should match 80/TCP, 443/TCP and 10000/UDP plus any optional ports you have deliberately enabled. Unexpected listeners, especially on the XMPP or internal component ports, indicate a configuration change or a container exposed by mistake. Watch for container restarts in the Docker setup, because repeated restarts can point to a failing component or a rootless permission problem.

Tracking and testing Jitsi releases

Follow new stable build tags in the jitsi-meet repository, for example the stable/jitsi-meet_11248 tag published September 14, 2026, and record which tag your deployment runs. Test each upgrade in staging first, then apply matching versions across Jitsi Meet, Prosody, Jicofo and the videobridges, because mismatched components can fail in ways that look like network problems. Apply operating system security updates on the same cycle, with a rollback path for each host.

Backing up configuration and keys

Back up the .env file, the configuration files for each component, the signing keys used for JWT tokens, and the TLS certificates and private keys. These files hold the authentication settings and secrets that define your hardening, so store the backups with restricted access, encrypted at rest and separate from the hosts they protect. Test a restore in staging, since a backup that has never been restored is an assumption rather than a recovery plan.

Documenting the hardening baseline

Keep a written baseline that records the hardening settings, the list of allowed ports, and the authentication decisions, such as whether room creation requires JWT tokens and whether a separate anonymous domain serves guests. Name an owner for each control and set a review date, so that changes go through a known person and the baseline is checked on a schedule. Update the document with every upgrade or configuration change.

Assigning ownership and decisions

Your team owns production decisions, including when to adopt a new tag, when to accept a risk from a failed test and when to change an authentication setting. Recurring patching and testing can be covered under a DeployOpen retainer if your team wants that support, but the retainer covers the work and not the decision to change production. Confirm in writing who approves changes and who is on call for an incident before the retainer or handover begins.

What buyers ask before hardening Jitsi with an outside partner

How much effort does hardening a self-hosted Jitsi Meet take?

The effort depends on how many decisions are already made and how many components you run. A basic deployment needs HTTPS with a valid domain certificate, a decision on room creation, and firewall rules for the ports Jitsi uses. Effort grows with the number of videobridges, the install method (Docker or Debian packages), the number of identity systems you connect, and whether recording or SIP dial-in is in scope, since each adds a service to lock down. Work also grows if your confidentiality rules require a documented baseline, a change process for firewall edits, or evidence for an assessor. Ask any partner to list each component, the hardening applied to it, and the testing that proves it. The initial build is one-time work, while patching and periodic reviews recur.

Can our internal IT team harden Jitsi without an outside partner?

Yes, many internal teams can, provided they have Linux, container or configuration management experience and time to test changes. The official guides cover the basics, but the 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. The harder parts are usually authentication design, reverse proxy and certificate handling, rootless container permissions, and confirming that media still flows after each change. A partner adds the most value where you lack reviewers, need a second opinion on the design, or must produce documentation and test evidence on a fixed timeline. Before deciding, identify who will own patching after go-live, because that work recurs.

What does a Jitsi hardening project need from our team?

Expect to provide access and decisions early, because most delays come from waiting on them. The usual inputs are read access to your identity system so authentication can be connected to it, control of the DNS records and certificate process for the meeting domain, and a named person who approves firewall changes for the 443/TCP, 80/TCP and 10000/UDP ports the deployment needs. You also need a test environment close enough to production to prove each change, including a test identity source and test browsers across your device mix. Name a business owner who signs off on room creation rules and guest access. Confirm the access model, change windows and approval steps in writing before work begins, since these vary by organization.

Can DeployOpen make our Jitsi deployment compliant?

No partner can make a system compliant on its own, and DeployOpen does not claim to. DeployOpen plans, implements and hardens self-hosted platforms inside your own infrastructure, then prepares the systems, configuration records, controls and evidence that a compliance assessment will examine. It does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies that you select and engage. Ask which framework applies to your organization, which controls the hardening is meant to support, and what evidence the assessor expects. Put these points in the written scope so everyone understands what is delivered and what remains the assessor's decision.

Does end-to-end encryption mean the Jitsi server cannot see our meetings?

No. End-to-end encryption does not make the server irrelevant to confidentiality. Jitsi Meet encrypts audio and video on the network with DTLS-SRTP, and the videobridge decrypts packets in memory so it can route them to participants. Jitsi's security page states that the bridge does not store them, but verify that design statement in your own deployment before relying on it. Jitsi Meet's end-to-end encryption is available in Chromium 83 and later browsers and the Jitsi Electron client. It covers audio, video and screen sharing, but not chat or polls, and every participant must use a supported client. Treat the server, its logs, the chat channel and any recording path as in scope for your confidentiality review.

Is Jitsi hardening a fixed-scope project or an ongoing commitment?

Most hardening work is delivered as a fixed-scope project, with scope, deliverables and timelines agreed in writing before work starts. Ongoing needs are handled separately, usually through a retainer covering support, upgrades and continuous testing. The split matters because hardening is not a one-time state. Jitsi releases change, and stable builds tagged by build number need testing before rollout. Container images, Prosody, Jicofo and videobridges must stay on matching releases, and firewall rules and certificates need renewal and review. Ask the partner to separate the initial build from the recurring work, state what each covers, and explain how a security update released mid-contract is handled.

How is a Jitsi hardening quote produced from the scope?

A quote follows from the written scope. DeployOpen does not publish a price list, so the quote reflects what you have agreed to receive. Useful scope details include the number of videobridges, whether Docker or Debian packages are used, identity integration, recording or SIP dial-in, the number of environments, and the testing and documentation you need. Ask the quote to show each deliverable, who performs it, what you must provide, which items are one-time and which recur, and what is excluded. Also ask how scope changes are priced if your environment differs from what was described. A vague scope produces a vague quote, so tighten the written scope before requesting pricing.

How DeployOpen scopes, hardens and hands over Jitsi security work

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and Jitsi security hardening follows the same written-scope approach. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

How we scope

Confirm which Jitsi Meet deployment method applies, Debian or Ubuntu packages or the official Docker setup, and the supported OS versions for each.
Record the room creation model, certificate approach, recording and SIP extensions, and which data the confidentiality requirements actually cover.
Agree in writing which hardening areas are in scope, including authentication, TLS, firewall rules, container settings and patching, and which are excluded.

How we build

Configure HTTPS with a proper domain certificate, since the Jitsi handbook says self-signed certificates cause problems for audio and video.
Move room creation away from the deprecated secure domain method toward JWT token authentication with a separate anonymous domain for guests.
Restrict ports to those the deployment needs, verify rootless container and read-only filesystem settings, and document the encryption limits of DTLS-SRTP and end-to-end encryption.

How we hand over

Deliver a written configuration record covering authentication, certificates, network rules, container settings and patch procedure, reviewed with your team.
Provide verification steps your team can repeat, such as checking room creation is blocked for anonymous users and that only the intended ports answer.
Document the operating procedure for certificate renewal, Jitsi release updates and the responsibilities that stay with your internal team after handover.

How we support

Support covers follow-up questions on the hardened configuration after handover, scoped in the written agreement.
Ongoing support, upgrades and continuous testing are available as retainers, and a retainer can cover re-checking settings after each stable release.
Ask in any quote which hardening tasks recur, such as patching and certificate renewal, and which are one-time configuration work.