Which open-source alternative to Slack huddles fits your team
If your team is facing a Slack renewal, a data residency rule or a wish to stop paying for built-in calls, the three realistic self-hosted replacements for huddles are Mattermost Calls, Element Call on Matrix and Jitsi Meet linked from chat. None of them is a one-click copy of huddles, and chat and calls usually move on separate schedules. The practical starting point is the chat server you already run or plan to run, because Mattermost Calls is tied to Mattermost, Element Call to a Matrix homeserver, and Jitsi Meet can sit beside almost any chat tool through a link or an integration.
If you are already on Mattermost, Calls keeps the experience closest to huddles because the call lives inside the channel. Confirm with Mattermost which Calls capabilities and the rtcd component your edition and version support, and check that your plan covers the features you need. If you run Matrix with Element, Element Call is the natural fit, but it adds its own infrastructure questions. If your chat is on Rocket.Chat, or you want calls decoupled from chat entirely, Jitsi Meet is the most portable choice, and its deployment is documented as a separate stack with a web server, Prosody, Jicofo and Jitsi Videobridge.
Whichever option you pick, plan for three questions that hosting raises. First, can every participant reach your media servers, which usually means TURN or STUN planning for users behind strict firewalls. Second, how much bandwidth your media nodes need as concurrent participants grow, which you should test with your own usage pattern rather than assume. Third, whether calls must be recorded, and if so, who stores and governs those files. Ask each vendor and your own network team to answer these in writing before you commit to a platform.
How each huddle capability maps to open-source options
This table maps the huddle capabilities teams rely on to Mattermost Calls with rtcd, Element Call and Jitsi Meet. Each cell says whether coverage is confirmed by the documentation we reviewed, depends on your configuration, or must be checked against the release you plan to deploy. Jitsi has the most documented self-hosting detail, while Mattermost Calls and Element Call need release-level verification for several capabilities before you commit.
| Capability | Mattermost Calls (rtcd) | Element Call on Matrix | Jitsi Meet |
|---|---|---|---|
| Audio and video calls | Provided by the Calls plugin with the rtcd service. Confirm the current release and edition. | Element Call ships in Element Server Suite Community. Confirm the call features in your release. | Core function of the project, licensed under Apache 2.0. Deployed through web, Prosody, Jicofo and Videobridge. |
| One-click start from a chat thread | Confirm the call button and thread behavior in your release and client. | Confirm how calls start from a room in Element clients for your version. | Usually started from a shared link. Any chat button depends on your own integration work. |
| Screen sharing | Not covered in the supplied sources. Test in a staging cluster before rollout. | Not covered in the supplied sources. Confirm per Element Call release. | Confirm in the Jitsi Meet build you deploy, and test from each browser your staff use. |
| Guest access | Depends on guest account setup and Calls permissions. Confirm the flow end to end. | Depends on homeserver access and federation settings. Confirm how guests join. | Documented through a separate anonymous domain for guests, with JWT tokens for controlled rooms. |
| Recording and streaming | Confirm availability. Plan where recordings are stored on your own servers. | Confirm availability. Storage and retention are set by your own deployment. | Handled by the Jibri component, deployed as its own container alongside the other services. |
| Mobile clients | Confirm call support in the mobile app for your Mattermost version. | Confirm call support in Element mobile clients for your release. | Mobile clients need a certificate the device trusts, since self-signed certificates cause problems. |
| Single sign-on and directory login | SSO (SAML, OIDC, OAuth) starts at the Professional plan, so Team Edition lacks it. | Synapse supports OIDC, SAML2 and CAS. Calls rely on the homeserver login. | Internal accounts, JWT, LDAP, Matrix verification or a hybrid mode, set in the .env file. |
| Network ports and TURN or STUN | Confirm the ports and TURN requirements for your rtcd topology before setting firewall rules. | Confirm the TURN and media requirements for your Element Call release. | Needs 10000/UDP plus 443/TCP. 5349/TCP is for fallback and 3478/UDP for optional STUN. |
When Mattermost Calls, Element Call or Jitsi Meet fits
Slack huddles are built into the chat client, so replacing them means choosing a calling component that pairs with your chat server. The three options below differ in what they deploy, how users sign in, and which features sit behind paid editions.
Mattermost Calls with rtcd
Mattermost Calls adds audio and video calls to channels on a Mattermost server, and larger deployments run the separate rtcd media service alongside it. Your planning covers the media path between clients and rtcd, TURN relay for users behind strict firewalls, and the bandwidth each call consumes. Mattermost high availability and SSO sit in paid editions (Professional, Enterprise and Enterprise Advanced), so confirm which tier your sign-in model needs before you commit. Ask Mattermost to confirm the rtcd sizing and recording support for your version.
Element Call on Matrix
Element Call provides group calls for Matrix rooms and is included in the free, AGPL Community edition of Element Server Suite alongside Synapse. Synapse is licensed under AGPL, so review what that means for any changes you make and for any service you expose to users. Calls depend on the homeserver, a reachable TURN service and correct HTTPS certificates, and federation settings change who can join a call from outside your domain. Confirm the current Element Call deployment steps and recording options with Element before you plan the rollout.
Jitsi Meet linked from chat
Jitsi Meet is Apache 2.0 licensed and does not need to be the calling layer of your chat tool. Any chat product can post a meeting link, so this option works beside Mattermost, Rocket.Chat or Matrix without changing their server. Its deployment is heavier: a web server, Prosody, Jicofo and one or more Videobridge media routers, with ports 10000/UDP and 443/TCP open. Plan a valid domain certificate, because self-signed certificates cause audio and video problems. Confirm which authentication mode (JWT or LDAP, for example) your sign-in model needs.
Recording and retention checks
Slack huddles and their recordings sit inside Slack's retention rules, so self-hosted calls need a deliberate recording plan. Ask whether each option records calls, where the files are stored, who can open them, and how long they are kept. Jitsi recording relies on the separate Jibri component, which needs its own host capacity and setup. Mattermost and Element recording depend on version and edition, so confirm them in writing. Recording also raises consent and notice obligations that your legal team should set before go-live.
Bandwidth and TURN planning
Every option routes media differently, so the bandwidth and NAT traversal design should be decided before selecting a product. Group video uses more upstream bandwidth per participant than audio, and users on restrictive networks often need a TURN relay. Jitsi lists 5349/TCP for TCP fallback and 3478/UDP for STUN as optional ports, and its scalable guide recommends adding videobridges as load grows. Measure your peak concurrent calls in a pilot and size media servers from that result, not from the number of seats.
What TURN, bandwidth and recording demand when you host calls
Hosting huddles yourself means answering three questions before you pick a platform: can participants behind strict firewalls reach the media server, how many people the media tier must carry at once, and whether recordings need their own component and storage. Slack handles all three in its cloud, so none of them appears on a Slack invoice. On a self-hosted stack, each becomes your team's job. For Jitsi Meet, the Debian and Ubuntu quick start expects ports 80/TCP and 443/TCP for the web app, and 10000/UDP for media. Port 5349/TCP (TCP fallback for clients that cannot send UDP) and 3478/UDP (STUN) are optional, but they matter most for users on restrictive corporate or hotel networks. Confirm with the vendor whether your chosen option needs a TURN relay for those users, and where that relay runs. HTTPS is not optional. The Jitsi handbook states that a proper domain certificate is necessary for working audio and video, and warns that self-signed certificates cause problems, especially with mobile clients. Plan the certificate lifecycle, the DNS record and the firewall rules as part of the same change, and test from a network outside your office with a phone on cellular data. Capacity works differently: the Jitsi scalable setup guide scales videobridges horizontally by adding more of them. Its guidance sizes the central server and each videobridge separately, so ask your implementer to model concurrent participants per meeting and per day, and to confirm the bandwidth those streams consume at your peak. Recording is a separate system, not a checkbox. In Jitsi's Docker setup, recording and streaming run in the jibri container, so you must deploy, scale and secure it along with the rest. Decide what gets recorded, who may start a recording, where files are stored, how long they are kept and who can delete them, then match those answers to your retention and legal hold rules. Mattermost Calls and Element Call have their own recording and transcription designs, so confirm each vendor's current recording component, its storage requirements and its access controls before you commit.
Running calls beside Slack during the transition
Calls rarely move on the same day as chat. Teams usually keep Slack for messaging while a second call system takes over huddles, and each pattern creates its own sign-in and split-conversation problems. The cards below cover what each option depends on and what to check before users start switching.
Jitsi room links posted in Slack
Staff keep Slack as the chat system and replace huddles with a Jitsi Meet room link posted in the channel or DM. Jitsi can authenticate guests through JWT tokens or LDAP, so the room link does not need a Slack login, but the room's access rules are set on the Jitsi side. Check which people can create rooms, whether guests join through a separate anonymous domain, and that the Jitsi server has a valid HTTPS certificate, because the handbook says self-signed certificates cause audio and video problems. Users who keep clicking the Slack huddle button simply create a second call that nobody else joins.
Mattermost Calls on a parallel server
Running Mattermost Calls alongside Slack means a second chat server with its own users, channels and sign-in. Conversations move to Mattermost while Slack stays on for everyone else, so each person must be on the right side for the right thread. Calls in Mattermost depend on that server's identity setup, and SSO and AD/LDAP sync are paid features from the Professional plan. Check whether the people who must join calls already have Mattermost accounts before any huddle is moved, and decide who owns the server during the overlap period.
Matrix rooms bridged to Slack channels
A Matrix bridge can mirror Slack channels into Element rooms, which keeps messages flowing while users move. The bridge itself needs a Slack app identity and a Matrix account, so both sign-in systems become dependencies for the duration of the bridge. Bridged rooms usually carry text rather than live call state, so check whether calls started in Element Call reach Slack users at all. Plan for the bridge to be removed at cutover, and confirm which bridge options Matrix.org lists before choosing one.
Split conversations and lost call context
Each pattern splits the team's conversation across two places during the overlap. A decision made in a huddle may never reach the Slack channel where the project is tracked, and a call link posted in one system may be missed by people in the other. Set a rule for where call summaries are written and which system holds the record for each team. Slack's Free plan keeps only 90 days of visible history, so a decision recorded only in Slack may be harder to find later.
Staff who keep using Slack huddles
Some people will keep starting Slack huddles from habit, and nothing in Slack stops that while the workspace is live. Decide whether to leave huddles on, disable them for a group, or accept a short overlap. Ask Slack administrators which huddle settings the plan allows, and tell users in writing where calls now start. Track the first two or three weeks of use so you can see whether people still reach for the old button.
Cutover checklist for both systems
Before the switch, confirm that every user who must join calls can sign in to the new system, that the TLS certificate and firewall ports for the call server are in place, and that bridge or link routes work from both sides. Name an owner for the overlap period and a date when Slack huddles are turned off for each group. Ask your implementation partner to write this list in the statement of work so the criteria are agreed before work starts.
Moving huddle habits and call infrastructure off Slack
This sequence takes a team from Slack huddles to a self-hosted call service tied to chat, with media, TURN and identity tested on real networks before anyone is cut over. The output is a documented call setup, a tested set of users and a dated retirement of the Slack huddle habit.
Inventory huddle use by channel and team
Ask channel owners and team leads which channels and groups start huddles, how often they run, how many people usually join, and whether anyone relies on huddle notes, recordings or huddle canvases. Record the answers in a simple table with the channel name, owner, typical size and any external guests. Confirm with Slack what, if anything, it exports for huddles on your plan, since huddle content usually needs to be captured separately from the chat export. The step is done when every regular huddle use has an owner and a stated requirement.
Choose the call option and chat server
Match the inventory to one of three paths: Mattermost Calls with its rtcd service when chat already runs on Mattermost, Element Call when the team moves to a Matrix homeserver with Element, or Jitsi Meet linked from chat when the team wants a standalone video service that chat links to. Record the decision with its reasons, including whether guests join from outside the organization and whether recording is required. Ask each vendor or implementer to confirm current support for the features you named, since capabilities change between releases. The step is done when a signed decision record lists the chosen option and the open questions it leaves.
Deploy media and TURN in your network
Install the media path inside your own cloud account, data center or air-gapped network. For Jitsi, this means the web server, Prosody, Jicofo and Videobridge, with HTTPS on a proper domain certificate, because the Jitsi handbook says self-signed certificates cause problems for audio and video. Open the ports the Jitsi quick start lists, including 10000/UDP for media. For each option, plan TURN or STUN relays so users behind strict firewalls can connect, and size bandwidth from the expected concurrent participants. Ask your network team to confirm egress rules and how relays are reached from remote staff. The step is done when a test room opens over HTTPS and media flows between two internal machines.
Connect identity and access rules
Connect the call service to the identity provider your organization uses, so that huddle and meeting access follows the same accounts as chat. For Jitsi, choose between JWT tokens, LDAP or Matrix-based verification, and retire the older secure domain method for new installs as the handbook advises. For Element Call or Mattermost, confirm which single sign-on and directory features apply to your edition, because some are paid features. Decide who may create rooms, who may join from outside, and how guest access is separated. The step is done when a test user from each group can join and a user outside the group is refused.
Test with real participants on mixed networks
Run scheduled test huddles with pilot members from each main team, using laptops, phones, home connections, the corporate network and a guest on a separate network. Check audio and video quality, screen sharing, reconnects after network changes, and whether relays carry traffic when direct connections fail. Record the results against the inventory from the first step, and log any calls that drop or that users cannot start. Repeat failed tests after each fix. The step is done when pilot groups complete their usual huddle types on every network they use and the failure list is empty or accepted in writing.
Capture and archive existing huddle content
Before cutover, collect whatever huddle records, notes or canvases your retention rules require and store them in an archive your organization controls. Chat history moves through the Slack migration pages for each target, but huddle content is generally separate, so confirm what Slack provides for it and what your plan's export tools cover. Document where each captured item went and who can access it. The step is done when the retention owner signs off that every category the inventory marked as required is archived and searchable.
Set the cutover date and retire the Slack habit
Agree a cutover date with channel owners, announce where huddles now start, and update channel topics, onboarding notes and any bookmarks or links that point to Slack huddles. Keep the Slack huddle option available until the cutover date passes, then remove it from the team's routine. Monitor the new call service for failed starts and gaps for a short period, and route questions to a named support contact. The step is done when all inventoried channels use the new call option, support tickets about joining calls are closed, and the runbook is handed to the operations team.
What each option asks of your infrastructure
Running Mattermost Calls, Element Call or self-hosted Jitsi Meet on cloud virtual machines gives you public addresses, managed DNS and certificate automation, but media traffic still needs open UDP paths. Plan the network before the instance sizes, because a restrictive security group will break calls in ways that look like client bugs.
- Ports: Jitsi Meet needs 80/TCP and 443/TCP, plus 10000/UDP for media. Keep 5349/TCP for TCP fallback and 3478/UDP for STUN as optional, and confirm the TURN and STUN path for Element Call and Mattermost Calls with each vendor.
- Certificates and identity: The Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially on mobile. Decide whether users sign in through internal accounts, JWT tokens or an identity provider before launch.
- Sizing: 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.
- Questions for Element: Ask which Element Call components run on your instances, how TURN is provided, and whether the Element Server Suite Community edition covers the call stack you need.
- Questions for Mattermost: Ask which Calls components run as separate services, how the rtcd service is placed and secured, and which ports and TURN settings Calls expects.
Before you commit, confirm that your cloud provider allows the UDP range you plan to use and that your monitoring can see media-server load.
Inside a data center or disconnected network, the constraints move from security groups to firewalls, internal DNS and certificate authorities. Calls still need reachable media paths, and an air-gapped network also needs every package, container image and update delivered by hand.
- Ports: The same Jitsi ports apply, but internal firewalls often block UDP by default. Map each port to a rule and document which addresses clients use, including any NAT in front of the media servers.
- Certificates and identity: Use a certificate from your internal certificate authority and make sure every client trusts its chain, since the Jitsi handbook warns against self-signed certificates. Identity can run on LDAP through the Jitsi Docker authentication options or on your existing SSO provider.
- Sizing: Apply the same Jitsi scalable guidance per videobridge, then add headroom for the peak meeting count in your organization, which you should measure rather than assume.
- Questions for Element: Ask whether the Sovereign edition of Element Server Suite is required for air-gapped operation, which components it includes, and how updates are delivered offline.
- Questions for Mattermost: Ask whether Calls is covered by your edition for an air-gapped deployment, and which Enterprise Advanced features the offline path depends on.
Confirm your offline update process and your certificate renewal procedure before the first meeting goes live.
Jitsi as a Service from 8x8 runs the media infrastructure for you, which removes the videobridge sizing, UDP exposure and TURN work from your team. You trade that for a dependency on an external provider and less control over where media and metadata are processed.
- Ports and network: Your team opens no inbound media ports on its own servers. Ask 8x8 which domains, ports and regions clients need, and check that your firewall allows outbound access to them.
- Certificates and identity: The provider manages the public certificate. Your identity work is about JWT tokens issued by your application, so define how tokens are signed and who may create rooms.
- Sizing and scale: Capacity is handled by the provider, so the questions shift to concurrency limits, usage billing and what happens at peak load. The jitsi.org page describes JaaS as the team that builds Jitsi running it for you.
- Questions for 8x8: Ask about data location, recording storage, retention, subprocessors and the support commitment in writing before you rely on the service.
- Application integration: Plan the JWT flow in the application that links to meetings, since the Jitsi token authentication handbook recommends this method for new installations.
Get the provider's data processing terms and service levels in writing, and compare them with your own residency and retention rules.
Questions buyers ask before replacing Slack huddles
What drives the cost of self-hosting huddles instead of using Slack's built-in calls?
The cost comes from the servers that carry media, the TURN relay that helps participants behind strict firewalls connect, storage for any recordings, and the staff time to run it. Slack's huddles are included in the subscription you already pay, so the cost moves from a per-seat fee to infrastructure and people. Jitsi'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, so media capacity is the main hardware line. Ask any provider for a quote that separates one-time setup from recurring hosting, bandwidth, TURN capacity, backup and support, and that states which Mattermost plan or other edition each identity or compliance feature requires. Mattermost includes SSO and AD/LDAP sync from the Professional plan, so a quote should say which edition it assumes.
How long does a pilot and full rollout of self-hosted huddles usually take?
Timing depends on how many people will join calls, whether identity integration is part of the first release, and how much your network team must change. A small pilot on one platform can run in a few weeks when the domain, HTTPS certificate and firewall ports are ready. Full rollout takes longer when you add single sign-on, group sync, recording storage and load testing across office locations. Jitsi's handbook says HTTPS with a proper domain certificate is necessary for working audio and video, so certificate issuance is often the first blocker. Ask a vendor or partner to state the phases, the acceptance tests and the dates they depend on, rather than accepting an open-ended schedule.
Can an internal team run self-hosted huddles without outside help?
A capable platform or infrastructure team can run a Jitsi or Mattermost Calls deployment alone if it has time to learn the components and someone accepts on-call duty for media. Jitsi deployments involve a web server, Prosody, Jicofo and one or more Jitsi Videobridge media routers, so the team must understand each one before an incident. Mattermost Calls adds the rtcd service to its chat deployment, and Element Call adds its own pieces to a Matrix server. The honest test is whether two or more people can upgrade, troubleshoot and restore the service without the original builder. If not, plan for a support retainer or an implementation partner from the start.
What do networking and security staff need to do for self-hosted huddles?
Networking staff must open the media paths, publish a stable DNS name and provide TLS certificates, while security staff review who can create rooms and what identities they use. The Jitsi quick start lists ports 80/TCP, 443/TCP and 10000/UDP as required, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional. Self-signed certificates cause problems, especially with mobile clients, so use a certificate your users' devices trust. For Jitsi, the handbook recommends JWT token authentication and a separate anonymous domain for guests instead of the deprecated secure domain method. Ask your security team to review the Docker authentication options and the firewall rules before any pilot leaves the lab.
Can huddle recordings be kept for audit or legal purposes after moving off Slack?
Yes, but only if you deliberately design a recording pipeline, because Slack huddle content does not carry over automatically and each platform records differently. Jitsi offers recording and streaming through the jibri component, which the Docker setup runs as its own container, so storage, retention and access control must be planned around it. Mattermost compliance export is a paid feature from the Enterprise tier, so check whether your required retention and export capability needs that plan. Before cutover, confirm with legal and records staff what must be retained, where it will be stored, who can access it, and how deletion is logged. Slack's export rules also limit what you can retrieve from the old workspace, so decide early what history you need to keep.
When is it worth bringing in a partner such as DeployOpen to scope self-hosted huddles?
A partner is worth scoping when the work crosses several teams, when a regulated data requirement must be proven, or when no one on staff can own media operations. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with agreed deliverables before work starts. DeployOpen does not issue audit reports or certifications, but it can prepare systems and evidence for an assessment that an independent auditor will review. Ask for a written scope listing the platform, identity integration, TURN and networking work, recording design, testing and handover, and the support model after go-live. DeployOpen does not publish prices, so a quote follows from that scope.
How DeployOpen scopes and delivers a huddle replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Slack huddle replacement, that means choosing between Mattermost Calls, Element Call on Matrix or Jitsi Meet with you, then building the media path, identity and recording setup in your own cloud account, data center or air-gapped network.
How we scope
- Written scope names the chosen calling platform, the user count and the sites or networks involved.
- Scope lists TURN, STUN and firewall ports, including UDP media paths, for each office and remote network.
- Scope states whether call recording is in or out, and who approves where recordings are stored.
How we build
- Deployment covers the calling service, TLS certificates for the public domain, and identity integration with your existing directory.
- Testing covers call quality across networks, including restrictive firewalls and mobile clients, before users are onboarded.
- Hardening covers access controls, room authentication and network exposure of media and signaling components.
How we hand over
- Handover includes architecture notes, runbooks for certificate renewal and scaling, and the configuration files used.
- Your team receives documented steps for upgrades, backups and restoring the calling service after a failure.
- Deliverables are agreed in the written scope, so acceptance criteria are known before work starts.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade planning follows each platform's release and support windows, which you confirm against the vendor's published schedule.
- Ask any provider for the support hours, response expectations and upgrade cadence in writing before you sign.
