Most open-source team chat apps are not end-to-end encrypted by default. Of the popular self-hostable options, only Wire encrypts everything end-to-end with no way to turn it off, and Element (Matrix) encrypts direct messages and private rooms by default. Rocket.Chat has end-to-end encryption, but an admin has to enable it and it is off by default. Mattermost and Zulip have no built-in end-to-end encryption for messages, and Nextcloud Talk offers it only for calls, off by default. Being open source and self-hosted is not the same thing as being end-to-end encrypted.
End-to-End Encryption in Open-Source Team Chat, Compared
The table shows what each product does out of the box, according to its own documentation and source code as of November 2026. "Default" means what a new conversation gets without anyone changing settings.
| Product | License | Self-host | DMs | Group channels | Files | Calls | Protocol | What you lose with E2EE |
|---|---|---|---|---|---|---|---|---|
| Element (Matrix) | AGPL-3.0 (Synapse server, Element Web) | Yes | On by default when the other person has keys | On by default for private rooms (opt-out) | Yes, in encrypted rooms | Yes, Element Call (MatrixRTC) | Olm + Megolm | Server-side search (encrypted search needs Element Desktop's local index); bots and bridges must handle keys; admins can switch the default off |
| Wire | AGPL-3.0 (wire-server) | Yes | Always on | Always on | Always on | Yes, including conference calls | Proteus (Double Ratchet); MLS opt-in on self-hosted backends | Server-side search and plaintext integrations; compliance retention works through legal hold, which adds a visible recording device |
| Rocket.Chat | MIT core; ee/ directories under a commercial license (E2EE code is in the MIT part) | Yes | Off: admin must enable E2EE, then can make new DMs encrypted by default | Off by default for private rooms (can be forced from 8.8.0); public channels never | Yes, in encrypted rooms | Not covered by E2EE | Own scheme: per-room AES key wrapped with each member's RSA key | Search, auditing and monitoring, bots that aren't E2EE-aware, federated rooms |
| Mattermost | AGPL-3.0 source, MIT-licensed compiled builds; enterprise features commercial | Yes | No | No | No | No (DTLS-SRTP to the server) | None built in; unofficial community plugin | Nothing, because there is no E2EE; the database is left readable for search and compliance |
| Zulip | Apache-2.0 | Yes | No | No | No | No (Jitsi Meet by default, or Zoom, BigBlueButton and others) | None for messages; E2EE for mobile push notification content | Nothing, because there is no E2EE for messages |
| Nextcloud Talk | AGPL-3.0 | Yes | No | No | No (Nextcloud Files has separate opt-in encrypted folders) | Optional, off by default until all mobile clients support it | None for chat; WebRTC E2EE for calls | Chat stays readable on the server; encrypted calls are web and desktop only for now |
| Lupyd (Firefly engine) | Firefly client engine: MIT; Lupyd service: hosted | No | Always on | Always on | Yes, encrypted on the device | Group calls not yet E2EE; 1:1 calls use WebRTC | Signal Protocol (DMs) + MLS, RFC 9420 (groups) | Search runs on the device only; the server sees group membership, roles and group names; no self-hosting; no external audit yet |
Sources: each vendor's documentation and repositories, listed under Sources & References.
Self-Hosting Is Not the Same as End-to-End Encryption
Teams often pick an open-source chat server because they can run it themselves. That keeps data away from a vendor's cloud, but it does not keep it away from whoever runs the server. On a self-hosted server without end-to-end encryption, messages are stored in a form the server can read. Anyone with admin access to the server or its database can read every channel and direct message, and so can anyone who steals those credentials or a database backup.
Zulip's own security model says this plainly: anyone with root access to a Zulip application or database server has complete control over the installation and all of its data, including the ability to read messages and modify history. Mattermost's documentation says it does not encrypt data inside the database so that end-user search and compliance reporting keep working, and recommends disk encryption instead. Disk encryption protects a stolen disk, not a running server.
End-to-end encryption protects against a different threat: your own server operator. Keys live on members' devices, so the server stores and forwards ciphertext it cannot decrypt. That matters when the server is run by an IT contractor, a hosting provider, a parent company, or simply an admin account that might be compromised. If you only need data residency, self-hosting may be enough. If you need conversations that the server operator cannot read, you need end-to-end encryption, whether or not you self-host.
Product by Product
Element (Matrix)
Element creates encrypted direct-message rooms by default when the other person has keys uploaded, and defaults private rooms to encrypted with an option to opt out. A homeserver admin can change that default, or disable encryption entirely, through the server's well-known client configuration. Matrix uses Olm for device-to-device key exchange and Megolm for room messages; attachments in encrypted rooms are encrypted on the client before upload. Element Call, now Element's group calling, keeps calls end-to-end encrypted.
The cost: the server cannot search encrypted rooms. Element Desktop can search them using Seshat, a local index stored on your device, but the web client cannot. Bots and bridges have to manage their own encryption keys to read encrypted rooms. For a deeper look at Megolm versus MLS, see Lupyd vs Matrix.
Wire
Wire says all communication, including messages, files, calls and conference calls, is end-to-end encrypted, that this is always on and cannot be disabled. Messages use Proteus, Wire's implementation of the Double Ratchet. Wire also supports MLS; its self-hosting documentation describes MLS as an opt-in feature that the backend operator and team admins must enable. The server, wire-server, is AGPL-3.0 and can be self-hosted. For regulated teams, Wire offers legal hold: a recording device is added to the conversation, and the people involved can see that the conversation is being recorded.
Rocket.Chat
Rocket.Chat's end-to-end encryption covers direct messages and private rooms, plus files uploaded in encrypted rooms. In the source code every E2EE setting defaults to off: an admin must turn on end-to-end encryption for the workspace, and can then make new direct messages and private rooms encrypted by default. Since version 8.8.0 admins can force encryption on new private rooms. Public channels are not encrypted, and federated rooms are exempt because federation does not support it. The E2EE code sits in the MIT-licensed part of the repository, not in the commercially licensed enterprise directories.
Rocket.Chat's current documentation no longer labels the feature as beta. It lists the trade-offs: encrypted messages don't appear in search, encrypted content can't be audited or monitored, and bots can't read encrypted messages unless they support E2EE. The scheme itself is Rocket.Chat's own: each room has a shared AES key, which is encrypted to each member's RSA public key. That is simpler than Megolm or MLS and doesn't rotate keys per message.
Mattermost
Mattermost has no built-in end-to-end encryption. Its encryption options page covers TLS in transit, disk-level encryption at rest, and DTLS-SRTP for calls to the server, and explains that the database is not encrypted so search and compliance reporting work. In October 2024 Mattermost asked its community for input on adding E2EE for specific use cases, and in 2025 it announced a joint development program with Qrypt for quantum-secure E2EE. We found no shipped E2EE feature in the v11 changelog. A community plugin from Quarkslab adds per-channel E2EE for messages, but it is not an official Mattermost feature, does not encrypt files, and was last updated in July 2024.
Zulip
Zulip does not end-to-end encrypt messages. It encrypts traffic with TLS and, separately, end-to-end encrypts mobile push notification content so that Apple, Google and Zulip's push service can't see message text or metadata. The message itself is stored readable on the server, which is what makes Zulip's server-side search and topic features work. Calls are handed to an external provider, Jitsi Meet by default.
Nextcloud Talk
Nextcloud added end-to-end encrypted calls in Talk for the web and the desktop client in early 2025. The Talk API documentation says the setting is currently off by default until all Talk mobile clients support it. Chat messages are not end-to-end encrypted. Files shared in Talk live in Nextcloud Files, which has its own opt-in end-to-end encrypted folders, but that is separate from Talk chat.
Lupyd and Firefly
Lupyd encrypts direct messages with the Signal Protocol and group channels with MLS (RFC 9420), and encrypts files and backups on the device. The client engine, Firefly, is open source under the MIT license at github.com/lupyd/firefly, so anyone can inspect the code that holds the keys. The server is not published, so Lupyd is a hosted service, not something you can self-host today. Group calls run through Cloudflare and are not yet end-to-end encrypted. The server acts as an MLS external client, so it sees group membership, roles and group names, though not message content. Search runs on the device. Lupyd has not had an external security audit yet.
What End-to-End Encryption Costs You
The same trade-offs appear in every product that encrypts end to end, because the server can no longer read content:
- Search moves to the device or disappears. Element Desktop and Lupyd search locally; Rocket.Chat excludes encrypted messages from search.
- Bots and integrations need keys of their own, so classic webhook-style bots that read plaintext on the server stop working in encrypted rooms.
- Compliance export and moderation can't read content on the server. Wire's legal hold solves this with a visible extra device; Rocket.Chat says encrypted content can't be audited.
- Lost devices mean lost history unless keys are backed up. Each product handles key backup and recovery differently.
Products without end-to-end encryption keep all of these features, which is a fair reason some teams choose them. The point is to choose knowingly. For the wider landscape beyond team chat, see which messaging apps are end-to-end encrypted.
How to Choose
- You need data residency, full server-side search and compliance export: Mattermost, Zulip or Nextcloud Talk, self-hosted, with disk encryption and tight admin access. Accept that admins can read messages.
- You need E2EE and self-hosting: Wire (always on) or Element (on by default for DMs and private rooms). Rocket.Chat works if an admin enables and enforces E2EE.
- You need E2EE but not self-hosting: a hosted end-to-end encrypted service is an option, as long as its client code is open to inspection. If you are moving off Slack, see Lupyd vs Slack.
Frequently Asked Questions
Which open-source team chat apps are end-to-end encrypted by default?
Wire encrypts all messages, files and calls end-to-end and it cannot be turned off. Element (Matrix) encrypts direct messages and private rooms by default. Rocket.Chat supports end-to-end encryption but it is off until an admin enables it. Mattermost and Zulip have no built-in end-to-end encryption for messages, and Nextcloud Talk offers it only for calls, off by default.
Is Mattermost end-to-end encrypted?
No. Mattermost encrypts data in transit with TLS and recommends disk encryption at rest, but it does not encrypt messages end-to-end and leaves the database readable for search and compliance. A community plugin from Quarkslab adds per-channel message encryption, but it is unofficial and does not encrypt files.
Is Rocket.Chat end-to-end encryption available in the open-source edition?
Yes. The end-to-end encryption code is in the MIT-licensed part of the Rocket.Chat repository. It is off by default: an admin must enable it, and it covers direct messages, private rooms and files in encrypted rooms, not public channels.
Does self-hosting a chat server make it private?
It keeps data off a vendor's cloud, but anyone with admin or database access to your server can read messages unless the app uses end-to-end encryption. End-to-end encryption is what protects conversations from the server operator.
Is Lupyd open source and self-hostable?
Lupyd's client encryption engine, Firefly, is open source under the MIT license. The Lupyd service itself is hosted and cannot be self-hosted today. Direct messages use the Signal Protocol, group channels use MLS, files are encrypted on the device, and group calls are not yet end-to-end encrypted.
Final Takeaway
"Open source" and "self-hosted" tell you who can inspect the code and where the server runs. They don't tell you who can read the messages. Among open-source team chat apps, Wire and Element are the ones that encrypt end to end by default, Rocket.Chat can if an admin turns it on, and Mattermost, Zulip and Nextcloud Talk chat leave messages readable on the server. If you want an end-to-end encrypted team chat with an open-source engine and don't need to run the server yourself, Try Lupyd.
Sources & References
- End to end encryption by default, Element Web documentation
- Element Call: Redefining conferencing for privacy, scale and sovereignty, Element blog, December 2025
- Matrix Client-Server API: end-to-end encryption and encrypted attachments, Matrix specification
- Seshat: local indexing and full-text search for encrypted rooms, matrix-org on GitHub
- Synapse, element-hq on GitHub (AGPL-3.0)
- Security, Wire
- Messaging Layer Security (MLS), Wire documentation
- What is legal hold?, Wire Support
- wire-server, wireapp on GitHub (AGPL-3.0)
- E2E Encryption, Rocket.Chat documentation
- E2E settings defaults (e2e.ts) and room encryption (rocketchat.e2e.room.ts), Rocket.Chat source
- Rocket.Chat LICENSE, RocketChat on GitHub
- Encryption options, Mattermost documentation
- Mattermost v11 changelog, Mattermost documentation
- Mattermost Licensing, mattermost on GitHub
- Your Input Needed: End-to-End Encryption (E2EE) in Mattermost, Mattermost forum, October 2024
- Mattermost and Qrypt announce joint development program, Mattermost press release, May 2025
- mattermost-plugin-e2ee, Quarkslab on GitHub
- Security model, Zulip documentation
- Security, Zulip
- Configure call provider, Zulip Help Center
- Capabilities, Nextcloud Talk API documentation
- Nextcloud Hub 10, Nextcloud blog, February 2025
- Nextcloud Talk (spreed), nextcloud on GitHub (AGPL-3.0)
- Firefly, lupyd on GitHub (MIT)
- RFC 9420: The Messaging Layer Security (MLS) Protocol, IETF
Last updated: 4 November 2026.
- ✓ Wire end-to-end encrypts all messages, files and calls and it cannot be turned off; Element (Matrix) encrypts direct messages and private rooms by default.
- ✓ Rocket.Chat's end-to-end encryption is in the MIT-licensed open-source code, but every E2EE setting is off by default and public channels are never encrypted.
- ✓ Mattermost and Zulip have no built-in end-to-end encryption for messages, and Nextcloud Talk offers it only for calls, off by default until all mobile clients support it.
- ✓ Self-hosting is not end-to-end encryption: on a plaintext server, anyone with admin or database access can read every message.
- ✓ End-to-end encryption moves search to the device and limits server-side bots, auditing and compliance export, which is why some teams choose tools without it.
The workspace where nothing leaks
End-to-end encrypted channels and chat for your team, built on the Signal Protocol and MLS. Available on macOS, Windows, Linux and Android.
