The nice general chat UI and per-channel permissions for it were new in Zulip 11.0 last year: https://blog.zulip.com/2025/08/13/zulip-11-0-released/. So probably you tested not long before this got built.
3,222 karma · joined February 9, 2010
(And administrators can set it to be the default for new users in their organization, if the way your organization communicates is such that it's a better default than inbox).
Personally, I advocate for self-hosting communications software, ideally on physical hardware that someone in your community has control over. Zulip runs great on old laptops, if you can solve the IP address problem for hosting it in your house.
And if you want to be extra careful, put your chat system behind a VPN/firewall, so it's difficult to identify what software is being used externally.
And if you're not going to do that, because it sounds like too much work, the next best thing is to at least pick a Cloud service where you can migrate your group to paranoid self-hosting overnight if you decide the work is now worth it.
Self-hosting this way doesn't protect against all threat models. I am human and have children who I love dearly, so it's hard to rule out the possibility of my being compelled to make a malicious release.
But at least the Zulip source code is entirely open and highly readable; so users would at least have a chance to notice and not upgrade. With a centralized architecture like Discord, you're entirely reliant on whisteblowers.
Zulip is not designed to support 2M user accounts in a single organization. But if you enable the public access option (https://zulip.com/help/public-access-option), such that no account is required just to read content, you can end up with 1-2 orders of magnitude fewer "total accounts" that just wanted to see something once and don't actually use the server.
Regardless, there is no technical mechanism through which we could block access to a self-hosted Zulip server via the web application (which is hosted by the self-hosted server itself and designed to work on both desktop and mobile devices).
For Zulip Cloud, you can read https://zulip.com/policies/rules. One of the nice things about Zulip's model is that communities that we do not want to host can just migrate to self-hosting.
I'm told (https://chat.zulip.org/#narrow/channel/127-integrations/topi...) that upvoting that discussion might help it get prioritized.
Zulip uses standard TLS encryption, where the messages are encrypted in transit, but the server has access to the messages.
The server having access to the messages is extremely useful for many key features. Access control policies. Search. Markdown rendering that can make guarantees to clients about its behavior. Mobile notifications for mentions. And many more. There's options for all of these problems, but it's /hard/ and you end up having a lot of risk of nasty bugs where "all the message history become unreadable" and a lot of performance issues.
This is why why end-to-end encrypted messenger apps like Signal are extremely minimal with basically no chat features, and can take a while to load long conversations ... there's a lot of expensive cryptography happening in the background. AFAIK it's not realistic to use the Signal protocol with the volume of messages people do in high-traffic Discord or Zulip communities.
Some other E2EE chat systems have more features but fail to actually provide end-to-end security. (For example, the server provides the source code for the web app and can freely modify that code to steal all the messages the user can still read, or the server is still in charge of metadata like channel membership ... so a malicious server could just add a fake user to every channel).
You get almost all of the security benefits of these "E2EE" chat systems by having a trusted person self-host the server, and setting a message retention policy if you want messages in certain channels to be automatically be deleted after a period of time.
Our vision for Zulip is not billions of people on our Cloud service. People should own their own communities, not corporations. And in that world, usually the person who runs the community can be trusted to host it.
But the main reason is that the topics-based organization and ability for moderators to move/split conversations means one can read and participate in a community much more fully given a fixed amount of time.
Remember, self-hosted mobile push notifications already have a free community plan!
I can't say whether Zulip might be a fit for your needs. But you can always email our lovely sales/support team. https://zulip.com/help/self-hosted-billing#paid-plan-discoun... should give you a sense of our policies.
You don't need to email the sales team unless you have questions about the policy. It should be clear that "groups of friends" are eligible from the text you quoted.
You just need to spend 2 minutes filling out a brief form that's integrated in the server setup process if/when you have more than 10 users on your server. We enjoy hearing the brief notes users provide about how they are using Zulip. Is that too much to ask in exchange for reliably delivering you a service that you use every day?
It takes quite a bit longer to install a self-hosted server or configure an organization for thousands of users than to fill out the form -- I'd expect most people to spend more than 2 minutes creating a VM before they even get to running the installer. I'd expect that nicely configuring a Discord server for 2K people takes hours.
Is there something that we could change in the website that would make it obvious this is not an onerous process? The purpose of the section is to make clear that self-hosting Zulip is free for this sort of non-incorporated community use ... but we do need to have some eligibility process where you describe what you are, or it's free for Amazon too.
- We eschewed VC funding. A big part of my motivation was that I felt that VC funding usually requires eventual enshittification. https://zulip.com/values/ talks more about this.
- Zulip has been 100% FOSS software for more than a decade.
- At the very beginning, we built a complete data import/export system that allows migrating between our Cloud hosting and self-hosting; we put a lot of care into maintaining it well.
I can't promise that we'll never have something to sell for self-hosting communities. For example, I could imagine offering a paid add-on for encrypted backups.
That said, I'd like to push back on the idea that charging businesses for a tool that's an important part of their daily work "breaks the seal". Organizations with a software budget should be happier to pay a fair price for ethical, user-first software from a friendly vendor than for a closed-source product from a megacorp. And Zulip's full-time development team should be able to make a living building ethical FOSS software.
For the community tier, you don't have to do anything up to 10 users.
If your server has more than 10 users, you fill out a brief form (https://github.com/zulip/zulip/blob/main/templates/corporate...). We work hard to consistently process these requests within a couple business days, and the vast majority of communities are approved for full sponsorship without further interaction.
(Large communities managed by a business are quoted nonzero but extremely discounted pricing for self-hosted notifications).
Regarding the history: Slack had very effective marketing, powered by a lot of venture capital. And HipChat was a weak product that had an embarrassing total hack, which did not leave customers with confidence that their data was safe there.
Zulip is not venture-funded, so we're reliant on people sharing it with others to get the word out.
As a side note, I don't think Slack could have succeeded if it launched today. Microsoft Teams has far far more users as Slack, and it's slopware. You can thank the end of anti-trust enforcement for that.
Cryptography is not something you can do sloppily, and requires coordination between the mobile and server teams. Zulip 11.x included the protocol, but while doing the mobile implementation, we decided to make several more changes which have delayed it to the upcoming Zulip 12.0.
Some important context is that we retired the old React Native mobile app this summer in favor of the new Flutter apps (https://blog.zulip.com/2025/06/17/flutter-mobile-app-launche...), which has been an enormous improvement in the quality of the app and developer experience.
But as you can imagine, the cutover and relentlessly addressing feedback after it took a lot of time for the mobile team. We've also experienced an AI slop bombardment in the last few months that has consumed a lot of time. I'll save that story for another time.
I assume this API omission is intentional on Google's part but don't understand the motivation.
We do have plans to make the integration offer some additional ways to jump into a call, and have been talking about adding video chat. But our focus has been on building the best text chat possible, given there are multiple actively developed FOSS video call systems that we can integrate with.
But we don't have a dedicated accessibility tester on staff, so we're reliant on people reporting issues that bother them in actual use.
I should also mention there's a nice TUI app: https://github.com/zulip/zulip-terminal, which can be helpful for some people.
The main thing regards our double-entry API changelog system. Basically, the API documentation for individual endpoints, say https://zulip.com/api/get-user, natively cover for each endpoint all the changes relevant for that endpoint from https://zulip.com/api/changelog... and how to write nice code using feature level checks to support all server versions.
My understanding is that Campfire hasn't been actively developed for ~10 years (https://once.com/campfire/changelog shows some minor fixes after the OSS launch; their GitHub has no 2026 commits). There are no mobile apps. It is not an actively maintained Discord alternative.
Stoat is early in development. For example, https://github.com/stoatchat/stoatchat has 1421 commits, compared with 68K for https://github.com/zulip/zulip/. I wish them luck! It's really important that we have multiple independent efforts.
https://www.rocket.chat/ and https://mattermost.com/ are open-core military contractors these days. You'll see what I mean if you visit their websites. But like Zulip, they are full-featured team chat systems, and if the parts of their system that are OSS work for your organization, they're certainly valid options.
Finally there is Matrix/Element. They have an inspiring vision and similar values to mine, and I'd recommend checking it out. Element/Matrix is built on an ambitious distributed consensus protocol with an E2EE option, which provides capabilities Zulip don't have but also adds complexity. Zulip is focused on just doing team chat really well, and does not support more than ~100K users in an instance. Hopefully will have a lot more resources now, thanks to Current Events. I wish the Element team the very best of luck!
----------------------------------------
Overall, Zulip's focus has always been on making a delightful chat experience, especially when you have multiple conversations happening at the same time. We aren't trying to build a clone, but instead the best possible experience for having lots of possibly complex conversations. So there will be some differences from what you're used to.
But critically, we spend a very large amount of our time relentlessly fixing micro-interactions that annoy us or are reported to us. If you read #design, #issues, and #feedback in https://zulip.com/development-community/, you'll get an idea of how we work.
So while there's some features we don't have that are present in other products, and we don't have dozens of designers on staff to do cool end-of-year animated reports like Discord does, you can expect few bugs and a lot of interaction design polish.
-----------------------------------------
The one mistake that I think a lot of folks make in evaluating options is focusing on buzzwords like E2EE without thinking through their threat model. E2EE doesn't add much practical security over self-hosting for many threat models, and it comes with significant usability trade-offs. And some current E2EE systems don't actually protect against a malicious server, say because they only protect message content, not metadata like who has access to what... just against raiding the server's disk.
(For example, WhatsApp has E2EE for message content, but I expect Meta's databases know everyone who's had a conversation with me on WhatsApp and the precise timestamps and approximate lengths of every message I've sent or received on the platform. And apparently some keyboard apps send what you're typing to remote servers!).
Among customers, one reference that I can quickly cite is this one:
https://zulip.com/case-studies/gut-contact/
> Agents at GUT contact use Zulip every day to communicate with their team leads. “Most of our agents are in their 60s or 70s, so the software must be as simple as possible. That’s why we love Zulip,” says Erik Dittert, who’s been leading GUT contact’s IT team for the past 20 years.
I would recommend doing a little training/handholding call/video when moving over a community -- but this is true for any new app.
My mom needed training to do basic things in Squarespace, and I had a friend who worked at Slack whose manager started every chat message with "Hi <name>" and ended it with a signature, like you would an email. :)
It is highly ranked on some platforms that do validated reviews, like Capterra.
(I lead the Zulip project).
Given current events in the USA, I can't emphasize enough how worried one should be about the fact that a few companies like Discord, Google (Gmail), and Meta have databases with access to the private conversations of hundreds of millions of people with their closest friends and family members, linked up with their identity.
Some of the big strengths of running a self-hosted Zulip server for your community are:
- Zulip servers are operationally simple, highly stable and easy to upgrade.
- Zulip is much better than Discord or Slack for managing the firehose of busy communities. Or at least, a lot of people tell us that they prefer the user experience to everything else they've tried, after a few weeks of getting used to it. :)
- Your community leaders get to make the policy decisions about data protection, identity, etc.
- It's 100% FOSS software, with an extremely readable and maintainable codebase that ~1500 people have successfully contributed code to. I don't think you'll find modern alternatives with a comparable featureset to Discord that are more resilient to the sponsoring company being acquired or going out of business.
- We are a values-focused organization (https://zulip.com/values/) where providing a public service is important to us all.
- Each server is completely self-contained and independent, with the only centralized services needed from us being desktop/mobile app publication and mobile push notifications delivery (which is free for community use and soon to be E2EE).
I'm happy to answer any questions.
But for what it's worth, as Zulip's lead developer, every time I'm looked at whether we could have built Zulip on top of Matrix, it just feels impossible to me. And a big part of it is the architectural decisions Matrix made to support a decentralized E2EE social network, which are not required for a self-contained chat system like Zulip or Slack (which can still be bridged with other chat systems). Permissions enforcement, performance, and lots of other details really benefit from the more focused goal, where we've explicitly decided we're not building a generic distributed network architecture and are not competing with WhatsApp.
That said, I think it's great that we have multiple OSS chat systems with different strategies that are targeting different collections of niches!
I will never understand why so many organizations entrusted the communications fabric of their organization to Microsoft and SalesForce Cloud services over the last decade. If an organization can succeed in escaping Teams or Slack to Element/Matrix, that's great, even if it's a use case where Zulip would be a better end-user experience for their requirements.
As far as I know, there is no mechanism through which Zulip could bait-and-switch a customer that Element could not also do. And I think that as a practical matter, it would be a lot easier for a new team to pick up developing Zulip if the Kandra Labs team were to disappear than the similar question for Matrix/Element.
The core reason is that Matrix is far less simple and self-contained than Zulip. I've talked to multiple groups who tried to build apps on top of Matrix and found it too difficult. https://xn--gckvb8fzb.com/giving-up-on-element-and-matrixorg... may be a useful third-party reference.
This isn't to say Matrix is bad. It's just targeting a different niche. Matrix was designed around the requirements of a global social network, where you want to be able to keep writing in channels even in event of a network partition. As a result, Matrix is far more complex and less self-contained than a Zulip server is. If you are doing internal communications with some external guests, you are far safer from technical risk with a robust self-contained system like Zulip than something like Matrix that is also a social network.
Zulip's goal is to be the best way to do complex work, focused on replacing tools like Slack, Teams, and Discord, without the ambition to support a social network, and that changes a lot about the architecture and what we can do in terms of performance and focus on the human experience.
How much better could open source alternatives to Teams be in this moment if only 1% of what Europe paid Microsoft for Teams went to investing in open alternatives?