Jitsi on Docker vs Debian packages

The official Docker setup lists five authentication options: internal XMPP accounts, JWT tokens, LDAP, Matrix user verification, and a hybrid of Matrix plus JWT. You choose the mode in the .env file that sits next to the Docker Compose configuration, so the setting lives with the rest of your deployment config. Each option changes who can create rooms and how users sign in, so pick the method before you publish the domain. Check the Docker guide for your release because option names and supporting settings can change between releases.

In the Docker setup, authentication is set through the .env file rather than by editing the Prosody or web container configuration by hand. The guide describes internal XMPP accounts, JWT, LDAP, Matrix and the hybrid Matrix plus JWT mode as values you select there, along with the settings each mode needs, such as directory details for LDAP or token parameters for JWT. Because the containers run rootless with read-only filesystems, changes should be made in the .env file and applied by recreating the containers, not by writing into the running containers. Keep the file under version control and record which mode each environment uses.

No. The Jitsi handbook marks the secure domain method, which uses username and password to create rooms, as deprecated for new installations. Existing deployments that still run it should plan a move to token authentication, because the handbook steers new setups toward JWT. The secure domain guide remains in the handbook for reference and migration context. Before you finalize the design, confirm the current status in the handbook page for your release, and ask your integrator to document how existing rooms, users and client links will change during the switch.

The handbook recommends JWT token authentication for most deployments, and it pairs that with a separate anonymous domain for guests. JWT lets your own application or identity layer sign a token that tells Jitsi who the user is and what they may do, so authenticated hosts can start meetings while guests join without an account. Keeping guests on their own domain separates the two populations, which limits what an unauthenticated visitor can reach. The token authentication page in the handbook explains the claims and signing setup. Your team still owns the signing keys and the application code that issues tokens, so plan for key rotation and for where the token service runs.

The Debian and Ubuntu quick start is built for a single-host package install on Debian 12 or newer or Ubuntu 24.04 or newer, with OpenJDK 17 and the standard web, XMPP and media ports open. Confirm which authentication methods the quick start and the linked handbook pages document for your release before you commit to a design. Do not assume a Docker-only option, such as the hybrid Matrix plus JWT mode, is available on packages. Ask your integrator for a written list of the methods they will configure on the package install, and test each one against your real client platforms, including mobile clients, before go-live.

Matrix user verification fits organizations that already sign people in through a Matrix homeserver and want Jitsi rooms to follow the same identities. The hybrid mode combines Matrix verification with JWT, so a Matrix user can be recognized while your application still issues tokens for specific rooms or roles. Both options add a dependency on the Matrix side of your environment, which means another service to run, patch and monitor. Choose them only when Matrix is already part of your identity plan. If Matrix is not in place, internal accounts or JWT with a guest domain usually keep the moving parts smaller.

Internal XMPP accounts can work for a small, closed group where one administrator creates and removes users and the meeting service is not exposed to outside parties. The model is simple to run, but it means account lifecycle is managed in Jitsi itself, so offboarding and password policy need a documented manual process. Larger or regulated environments usually need a source of truth such as a directory or an identity platform, along with logging of who joined which room. Before you rely on internal accounts, confirm how your team will handle departures, password resets and audit questions.

The cost comes from design, configuration, integration and ongoing upkeep, not from a license fee, because Jitsi Meet is Apache-2.0 licensed. Design work covers which mode each audience needs and how guests are handled. Configuration covers the .env settings, certificates, and testing across clients. Integration effort rises when you connect LDAP, a Matrix homeserver, or an application that signs JWT tokens, because each system has its own owners and change process. Recurring costs include token key rotation, directory changes, and upgrades that touch authentication. Ask any implementation partner for a written scope that names each mode, each integration, the test plan, and who maintains the signing keys after handover.

The Debian and Ubuntu route is a single-host style quick start that needs Debian 12 (Bookworm) or newer, or Ubuntu 24.04 or newer, plus OpenJDK 17 and the ports 80/TCP, 443/TCP and 10000/UDP open. The Docker route adds a container runtime and a .env file that drives authentication and settings, and runs separate web, prosody, jicofo, jvb, jigasi and jibri containers. Effort rises with the number of components you enable, the number of videobridges you add, and how much you customize. Ask the vendor or your own team to walk through a sample deployment for your topology before you compare hours.

Yes, a team with Linux administration and DNS and certificate skills can follow either official route, but the sources make two points you should plan for. HTTPS with a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially with mobile clients. Recording (Jibri) and SIP dial-in (Jigasi) add components that need their own testing. Check whether your staff have run containers in production and whether they can own the certificate renewal and upgrade cycle before deciding.

Plan for three skill areas: Linux server administration, networking for media traffic, and identity configuration. On the networking side, Jitsi needs UDP media reachability, and the handbook's 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. On the Docker side, staff should be comfortable with rootless containers and read-only filesystems, which the official guide applies since release stable-11146. Identity work covers choosing among internal XMPP accounts, JWT tokens, LDAP, Matrix verification or a hybrid mode, and the handbook marks the older secure domain method as deprecated for new installations.

No deployment duration appears in the sources, so this page does not give one. Duration depends on the install route, the number of videobridges, whether recording or SIP dial-in is in scope, the identity method you choose, and how many rounds of testing your acceptance criteria require. Ask for a written timeline tied to a defined scope with named deliverables, and ask which items the timeline assumes you provide, such as DNS records, certificates, firewall changes and test accounts. A fixed-scope agreement is the usual way to lock these assumptions in writing.

A useful quote lists each component in scope and its role, the install route chosen and why, the operating systems or container runtime versions, the number of videobridges and their sizing, the authentication method and identity source, and the certificate approach. It should also state whether recording (Jibri) and SIP dial-in (Jigasi) are included, what testing is performed, what documentation and handover are delivered, and what happens to upgrades after go-live. Separate one-time work from recurring support or retainer work. DeployOpen does not publish a price list, and a quote follows from the written scope.

Switching is possible but is real migration work, not a configuration toggle. The two routes install components in different ways, so moving between them means rebuilding the host layout, re-applying the .env settings or package configuration, and re-testing authentication and certificates. Your effort depends on how much you customized, how many videobridges run, and whether recordings or dial-in users depend on the current setup. Decide early on the install route and authentication method, document both, and ask any implementer to state in writing how a later move would be scoped and charged.

The Debian route updates through the operating system's packages, while the Docker route updates by moving to newer container images. The Jitsi handbook tags stable releases by build number, such as stable/jitsi-meet_11248 published September 14, 2026, so you should track which build your install runs. Ask your implementer how upgrades are tested before rollout, how rollback works in each route, and whether upgrades are included in a retainer or quoted separately.