Self-hosted team chat in 2026: revisit Mattermost, Rocket.Chat and Zulip before you move another team off Slack

Sooner or later, every growing Indian company has the same conversation about chat. The free plan of a hosted chat tool has started hiding old messages, or the renewal quote for a paid plan has arrived for a few hundred users, or a large customer has asked where the project discussions are stored. Somebody says, “Let us host our own Slack, Mattermost is open source”, somebody else says, “Rocket.Chat is also free”, and a third person quietly points out that half the field team is still in WhatsApp groups that nobody controls. A week later there is a test server running on a spare VM, and nobody has read the licence page.

This post is written for that week. A team chat server looks simple, but underneath it is a database, a file store, a real-time connection to every client, a search index, a push path that leaves your network, and free and paid editions that decide how many people you can add. The software decides how many of those parts you own. It does not decide whether people actually move off WhatsApp. That part is yours.

We revisit three popular self-hosted options in 2026: Mattermost (a Go server with a React web app on PostgreSQL, built to feel like Slack, with a free Team Edition and a commercial Enterprise Edition that runs free as “Entry”), Rocket.Chat (a Node.js and Meteor server on MongoDB, with omnichannel customer chat, Matrix federation and a free Starter plan) and Zulip (a Python and Django server on PostgreSQL, organised around topics inside channels, fully Apache 2.0 licensed). We also look briefly at Matrix with Element as context. The aim is not to pick a winner but to see what each asks of you over five years.

The free editions are the real news this year. With Mattermost v11 in October 2025, Mattermost lowered the user limit of its MIT-compiled Team Edition to 250 and introduced Mattermost Entry, a free mode of the Enterprise Edition with a 10,000 message history limit. Mattermost v12.0 came on 16 October 2026 with PostgreSQL 15 as the new minimum and the old built-in Slack importer removed; 12.0.1 followed on 22 October with security fixes. Rocket.Chat made 8.9.0 a long-term support release on 5 October 2026, with support until 31 October 2027, and its release notes warn that Custom OAuth will need a paid licence from 9.0.0, which is in release candidates now. Zulip shipped 12.3 on 21 September 2026 with four security fixes and published the first 13.0 release candidate on 30 October 2026.

This post stays with chat servers for a company’s own staff. For the pieces around a chat server, see Keycloak and its alternatives for single sign-on, reverse proxies in 2026 for the front door, and PostgreSQL backups in 2026 for the database underneath two of the three. If your real problem is email, our last post on self-hosted email is the better starting point.

A scenario to keep us honest

We will use one invented company through the post. Malaikottai Boiler Services is an invented example, not a real business: a Tiruchirappalli company that fabricates, installs and services industrial boilers for sugar mills, paper mills and textile units across Tamil Nadu, Karnataka and Gujarat. The company has about 420 people. About 150 work in the office and the fabrication shop, and about 180 are service and commissioning engineers who spend most of their time at customer sites and use only phones. The IT team has four people, led by Revathi.

What they use today:

  • A hosted chat tool on its free plan, used by about 90 office staff, mostly engineering, purchase and accounts. Older messages are no longer visible, and the design team has lost commissioning notes that were only ever written in chat.
  • Dozens of WhatsApp groups, one per customer site, created by site engineers on personal phones. Some include former employees and some include customer staff. Photos of drawings, test reports and boiler inspection readings live in these groups.
  • An ERP and a document management system on the internal network, and Microsoft 365 for mail. Staff sign in to Microsoft 365 with their company accounts.

What triggered the review: a sugar mill customer, a co-operative with a government auditor, asked for proof that inspection photos shared with Malaikottai engineers are kept for the contract period and can be removed when the contract ends. At the same time, a quote for a paid hosted chat plan for about 330 users came in higher than the finance head expected. A young developer proposed Mattermost because “it looks exactly like Slack and it is free”.

Revathi’s questions: which server, what does the free edition allow for 330 users, how do notifications reach phones at sites, how do we keep and delete data, and can four of us own it for five years?

The short version

  • Read the free edition limits before the feature list. Mattermost Team Edition stops at 250 activated users and has no single sign-on; Mattermost Entry has single sign-on but shows only the last 10,000 channel messages across the whole server. Rocket.Chat Starter allows 50 users; Rocket.Chat Community allows 100 concurrent users and its own site says it is not suitable for business-critical production. Zulip’s self-hosted Free plan includes all features with no user limit, but mobile push notifications are limited to 10 users for workplaces unless you pay for a plan.
  • Mobile push is the part that leaves your server. All three send phone notifications through a vendor relay to Apple and Google, because the official apps are signed by the vendor. Decide what message content you allow in those notifications before you pick a server.
  • Mattermost is the closest to Slack in look and habits, with a single Go binary on PostgreSQL, monthly releases, Extended Support Releases with 12 months of support, and the richest set of paid compliance features. It is a good fit when you can pay for a licence at your size, or when you stay well under 250 users.
  • Rocket.Chat brings the widest feature spread: team chat, omnichannel customer chat, end-to-end encryption, video integrations and native Matrix federation. It runs on Node.js with MongoDB 8, ships often, and supports standard releases for six months. Its free plans are small or limited, so plan for a commercial plan at company scale.
  • Zulip is the most open: Apache 2.0, every feature in the free self-hosted edition, and a topic model that keeps long-running work readable. It installs as a full system on a dedicated Ubuntu or Debian machine, or as a reworked Docker image. The cost is a different way of working that some users must learn, and paying per user if you want push notifications for everyone.
  • For Malaikottai Boiler Services, our plan is: decide retention and site-sharing rules first, then pilot Zulip 12.3 for 60 people across two customer sites and the design team on a dedicated VM with 8 GB of RAM, using a paid self-hosted plan for push notifications. If the pilot shows that people will not adopt topics, the fallback is a quoted Mattermost licence for the full user count, not the free edition. Rocket.Chat is kept in view only if they later want customer-facing live chat on the same platform.

Where things stand on 1 November 2026

Mattermost

Mattermost is developed by Mattermost, Inc. The server and web app live in one repository, mattermost/mattermost, and the company describes the product as an open core, self-hosted collaboration platform. Its documentation now aims the commercial editions at defence, critical infrastructure and other security-heavy organisations, but the product is still widely used by ordinary companies.

Releases come monthly. The release page says a new server version is published on the 16th of each month, and every few months one release becomes an Extended Support Release (ESR) with about 12 months of support. On 1 November 2026, the current lines are:

  • v12.0, released 16 October 2026, supported until 15 January 2027. Patch 12.0.1 came on 22 October 2026 with medium severity security fixes, a Go runtime update and a fix for v12 failing to start when some email settings held lists of addresses.
  • v11.7 ESR, released 15 May 2026, supported until 15 May 2027.
  • v10.11 ESR, whose support ended on 15 August 2026 according to the docs, which ask users to move to v11.7 or later.

The v12.0 changelog is long, and a few items matter for planning:

  • PostgreSQL 15 or newer is required. PostgreSQL 14 and earlier are no longer supported.
  • The maximum message length grows from 16,383 to 262,144 characters. The migration takes a short exclusive lock on each affected table and rebuilds the full-text index on posts afterwards, so search runs without it for a while. Busy servers should test and plan a window.
  • RHEL 7 and RHEL 8 are dropped; the binary now needs glibc 2.34 or later.
  • The built-in Slack import API and the “mattermost import slack” command are removed. The supported route is the mmetl tool with mmctl import.
  • Web app plugins run on React 19; old community plugins may be stopped.
  • Personal access tokens can no longer post as webhooks or bots; such scripts must move to a bot account or an incoming webhook.

The other big change happened a year earlier, with v11 in October 2025, and it is about editions rather than code. We cover it in the licences section, because it changes the answer for any company above 50 users.

Rocket.Chat

Rocket.Chat is developed by Rocket.Chat Technologies Corp. The server is a Meteor and Node.js application on MongoDB. Its own plans page now speaks of a “Secure CommsOS”, aimed at commercial, government and defence buyers, with two free entry points, Starter and Community.

Recent releases worth knowing:

  • 8.0.0, published 12 January 2026, was a clean-up release. It dropped MongoDB 5.0 and 6.0, removed many old features (including Off-the-Record messaging and the old FreeSwitch-based VoIP), added attribute-based access control, and put native Matrix federation into beta.
  • 8.9.0, released 5 October 2026, is a long-term support release, supported until 31 October 2027. Standard releases get six months. The notes say support for the previous LTS, 7.10.x, ended on 30 September 2026. 8.9 moves to Node.js 24.15.0 and Meteor 3.5.2, runs apps on Node.js instead of Deno, and declares MongoDB 8.0 in its engine versions.
  • Custom OAuth is being moved behind a licence. The 8.9.0 notes say Custom OAuth keeps working for now, but version 9.0.0 will require a licence that includes the oauth-enterprise module, and unlicensed workspaces now log a warning when someone signs in through it.
  • 9.0.0 is in release candidates (rc.3 on 31 October 2026, UTC). The candidates change how many REST errors are reported, returning 403 with one body shape for refusals, and change status codes for incoming webhooks. Integrations that read error codes will need testing.

Zulip

Zulip is developed by Kandra Labs and a large open-source community. The server, web app and most tooling are in zulip/zulip under the Apache 2.0 licence. Zulip publishes two major releases a year and maintenance releases roughly monthly, and asks self-hosters to run the latest release.

  • Zulip 12.0 came on 27 April 2026. Highlights include generally available end-to-end encrypted mobile push notifications, a reworked Docker image (ghcr.io/zulip/zulip-server) with Compose and Helm documentation, a “Report message” feature, a beta Microsoft Teams import tool, and PostgreSQL 18 and Ubuntu 26.04 support.
  • Zulip 12.2 (10 August 2026) fixed five security issues, including one where the OpenID Connect backend did not check the email_verified claim, and one where guests could receive new messages from public channels they had not joined.
  • Zulip 12.3 (21 September 2026) fixed four more, including a forged group direct message issue and a typing notification endpoint that leaked user IDs to guests.
  • Zulip 13.0-rc1 was published on 30 October 2026 (UTC). The draft notes so far say that index migrations no longer use PostgreSQL’s CONCURRENTLY option by default, which matters only if you run migrations while the server is up.

Around them

  • Matrix with Element is the open, federated alternative: a homeserver such as Synapse plus Element clients, with end-to-end encrypted rooms that can talk to other organisations’ servers. It deserves its own post.
  • Mostlymatter, maintained by Framasoft, is a community fork of Mattermost that removes the user limits. A Mattermost staff reply on the Mattermost forum also notes that the limits live in one source file and can be changed by anyone compiling from the AGPL source. Both routes mean you maintain your own build, and the forum thread at the time said the fork had not caught up with v11.

The first questions to ask

Before comparing servers, Revathi’s team should write down answers to these:

  • How many people, and how many at once? Vendors count registered, active and concurrent users differently in their free limits.
  • Who needs phones, and what may a notification show? Notification text passes through Apple or Google.
  • Who outside the company must be in conversations? Customers may need guest accounts limited to one channel.
  • How long must messages and files be kept? A contract or an audit may decide this, not IT.
  • How do people sign in? Single sign-on is worth a lot, and it is what free editions tend to remove.
  • Who runs it at 9 PM when it is down? If the answer is “nobody”, buy hosted chat.

How each one works

Team chat in one minute

A chat server keeps users, channels and messages in a database, files on disk or in S3-compatible storage, and an open WebSocket connection to every client so new messages appear at once. Search runs on the database or a separate engine. When a user is away, a push notification goes from your server to the app publisher’s relay, then to Apple or Google, then to the phone. Integrations use webhooks, bots and slash commands; single sign-on uses SAML, OpenID Connect or LDAP. The editions differ in exactly these details.

Mattermost: one Go binary on PostgreSQL

Mattermost ships as a single Linux binary with the web app, plus a folder of pre-packaged plugins. It needs PostgreSQL (15 or newer from v12) and a place for files: local disk, NFS or S3-compatible storage. The documentation recommends the Docker deployment; Linux tarballs and a Kubernetes operator are the other common routes.

  • Plugins carry many features. Calls (voice and screen sharing over WebRTC), Playbooks (checklists for incidents and repeatable processes), Boards, the AI agents plugin and integrations with GitHub, GitLab, Jira and others ship as plugins. Some only run with a licence; in our drill, Playbooks refused to start on the unlicensed Team Edition.
  • Scaling to several application nodes, Elasticsearch or OpenSearch for search, and read replicas are Enterprise features. A single server is expected to handle 1 to 1,000 users on 1 vCPU and 2 GB of RAM, and 1,000 to 2,000 users on 2 vCPUs and 4 GB, according to the hardware requirements page.
  • Configuration lives in config.json or in the database, can be set through environment variables starting with MM_, and is managed in the System Console or with the mmctl command-line tool.

Rocket.Chat: Meteor on MongoDB, with many modules

Rocket.Chat runs as a Node.js application built with Meteor, connected to a MongoDB replica set. The official Docker images bundle Node.js; manual installs must match the Node version for the release (24.15.0 or later in the 24.x line, or 22.22.3 or later in the 22.x line, for 8.9). For large deployments, the documentation describes running Rocket.Chat as microservices on Kubernetes.

  • MongoDB is a first-class dependency. Rocket.Chat 8.x requires MongoDB 8.0 or later, and the documentation strongly recommends a three-member replica set for high availability. Upgrading Rocket.Chat across major versions usually means upgrading MongoDB first.
  • Files should go to S3, Google Cloud Storage or another object store; the docs say GridFS (storing files inside MongoDB) is not recommended.
  • Omnichannel lets the same server take customer chats from a website widget and other channels and route them to agents. This is one of Rocket.Chat’s real differences from the other two.
  • Apps-Engine runs marketplace and private apps. Community workspaces are capped at three private apps and five marketplace apps.
  • Federation with other Rocket.Chat and Matrix servers is built in, without a separate homeserver.

Zulip: Django and Tornado, with topics

Zulip’s server is a Django application for most requests plus a Tornado process for real-time events, with PostgreSQL, Redis, RabbitMQ, memcached and nginx around it. The standard installer expects to own the machine: it installs and configures these system packages itself on Ubuntu 22.04, 24.04 or 26.04, or Debian 12 or 13. The alternative is the Docker image, which runs each service in its own container.

  • Topics are the core idea. Every message in a channel belongs to a topic, like an email subject line. People follow, mute and resolve topics, and read a busy channel topic by topic. For work that runs for weeks, such as one boiler commissioning per topic, history stays readable. Typing a topic feels slow to some at first; Zulip 10 added a “general chat” for messages without a topic, and 11.0 allows channels without topics.
  • Requirements are modest but specific: at least 2 GB of RAM with 2 GB of swap for small installs, and 4 GB with 2 CPUs for 100 or more users. The scalability section recommends 8 GB of RAM with 100 or more daily active users, and a separate database server with 16 GB each for 400 or more daily active users.
  • Outgoing requests go through Smokescreen, a proxy that Zulip configures to stop users from making the server fetch private network addresses (SSRF) through link previews and similar features.
  • Import tools exist for Slack, Mattermost and Rocket.Chat, plus a beta tool for Microsoft Teams in 12.0. The maintenance releases in 2026 have repeatedly improved the Mattermost importer.

Mobile push notifications: the part that leaves your server

For a company with field engineers, push notifications matter more than any feature on the comparison page. They are also the one part of “self-hosted chat” that is not fully self-hosted. The official mobile apps are published by the vendor, so only the vendor’s push relay holds the keys to send notifications to those apps. Each project handles this differently.

Mattermost

  • Test Push Notification Service (TPNS) is free for non-commercial self-hosted users. The docs say it is not recommended for production and has no service level agreement. It uses port 80 from the server.
  • Hosted Push Notification Service (HPNS) is for paid plans, uses port 443, and has relays in the United States and Germany.
  • Your own push proxy is possible, but only with your own signed builds of the mobile apps.
  • ID-only push, where Apple and Google see only a message ID and the phone fetches the content from your server, is an Enterprise feature. Every plan can choose how much the notification shows: full message, sender and channel only, or sender only.

Rocket.Chat

  • Starter workspaces get unlimited push notifications through Rocket.Chat’s gateway. Community workspaces are capped at 10,000 per month.
  • ID-only push and a custom push gateway are listed as paid capabilities on the Community comparison.
  • With 180 field engineers, a cap of 10,000 a month can run out quickly; do the arithmetic for your team.

Zulip

  • Zulip’s Mobile Push Notification Service is free for up to 10 users at workplaces on the self-hosted Free plan, and unlimited for eligible communities, open-source projects, research groups and small non-profits.
  • The paid self-hosted plans, Basic and Business, include unlimited push notifications. On 1 November 2026, the plans page lists Basic at USD 3.50 per user per month billed monthly, and Business at USD 6.67 per user per month billed annually (USD 8 monthly) with a 25-user minimum and email and chat support.
  • Since Zulip 12.0, end-to-end encrypted push notifications are generally available when both server and app are new enough, so the relay forwards content it cannot read. An organisation setting can require encryption, and since 12.1 legacy unencrypted notifications are then skipped entirely.

What to decide

  • What may a lock screen show? For customer data, “sender only” or encrypted push is a sensible default.
  • Can the server reach the relay on the right port? If not, decide to live without push.
  • Who pays? On all three, reliable push for a few hundred users is paid or capped.

Security and accounts

Exposure

  • A chat server must be reachable from phones on mobile networks, which usually means the public internet. Put it behind a reverse proxy with TLS, keep the database and cache ports private, and decide whether the admin console needs to be public at all.
  • Mattermost: in our drill, the pre-packaged Calls plugin opened a listener on port 8443 on all interfaces, even though we had set the main server to listen only on loopback. Calls needs that port (UDP and TCP) for media; if you do not use Calls, disable the plugin, and if you do, open it deliberately.
  • Zulip documents that port 4369 (epmd, part of RabbitMQ) must be firewalled, because it cannot be bound to localhost only.
  • Rocket.Chat exposes 443 and 80 to users; MongoDB’s 27017 must be open only between Rocket.Chat and the database.

Sign-in

  • Mattermost Team Edition has email and password sign-in only; since v11, GitLab sign-in has been removed from Team Edition. SAML, OpenID Connect, Entra ID and LDAP need Entry or a paid plan. MFA enforcement is listed among the paid features.
  • Rocket.Chat Starter includes LDAP, single sign-on and two-factor authentication. For Community, the vendor’s comparison mixes features and caps in one list, so confirm the sign-in methods you need on a test workspace, and remember that Custom OAuth will need a licence from 9.0.
  • Zulip includes SAML, OpenID Connect, LDAP, Entra ID, Google, GitHub and others in every self-hosted plan. The paid plans add support for setting them up, not the features themselves.

Guests and data boundaries

  • All three support guest accounts limited to chosen channels, which is far safer than a WhatsApp group with customer staff.
  • Several of Zulip’s 2026 security fixes concern guests. Guest isolation is hard on every platform; patch promptly if you use guests.
  • Mattermost: global and custom retention policies, compliance exports and legal hold are Enterprise features. Entry has no compliance features.
  • Rocket.Chat: retention policies are included in Starter and the paid plans.
  • Zulip: message retention policies, full and compliance exports are in all self-hosted plans, with support on Business.

End-to-end encryption

  • Rocket.Chat offers end-to-end encrypted rooms. Encrypted rooms limit server-side search and complicate history for new members and lost keys.
  • Mattermost and Zulip do not encrypt message content end to end; they rely on TLS in transit and your control of the server and disks. Zulip encrypts push notifications end to end.

Patching

All three ship security fixes often. Mattermost posts details 30 days after a fix release; Zulip lists advisories in its changelog; Rocket.Chat lists fixes in release notes. Subscribe to the announcements and keep a monthly update window.

Performance and how to read benchmarks

What vendors publish

  • Mattermost publishes performance reports from its own load-test framework for each release. For v12.0, its changelog reports a 4.31% decrease in the number of supported users compared with the previous release, within its own prediction interval of plus or minus 5%. These are Mattermost’s own runs on its own setup. It also publishes the single-server sizing above and recommends its open-source load-test tool beyond 2,000 users.
  • Rocket.Chat publishes sizing by concurrent users: up to 500 concurrent users on Starter, 2 vCPUs and 4 GiB for Rocket.Chat plus a three-member MongoDB replica set with 2 vCPUs and 4 GiB each.
  • Zulip publishes conservative sizing by daily active users, as listed above, and its release notes claim specific improvements, such as the web app loading about twice as fast in very large organisations in 12.0. These are the project’s own measurements.

We do not compare messages per second here. For a few hundred people, throughput is rarely the limit; memory, search on a large history, file growth and open connections are.

Questions to ask

Was the test about sending, search or reconnect storms after a restart? Were plugins, push and search enabled? Was the database on the same machine?

What to measure yourself

Peak memory during the morning login rush, search time on a year of history, time to restart and reconnect all clients, disk growth per month for files, and time to restore the database and files on a new machine.

Licences and free-edition limits

This is the section to read twice. In 2026, the free tiers, not the code licences, decide what you can do.

Mattermost: AGPL source, MIT binary, commercial Enterprise Edition

  • Source code. The repository’s licence file says the server source is available under the GNU AGPL v3.0 (with stated exceptions), or under a commercial licence. The admin tools and configuration files, including the web app folder, are under Apache 2.0.
  • Team Edition binary. Compiled versions produced by Mattermost, Inc. are licensed to you under an MIT licence. The docs describe Team Edition as free, open source and self-hosted, “intended for small teams, hobbyists, or personal use under 250 activated users where single sign-on (SSO) is not required”. In the v11 announcement, Mattermost lowered the Team Edition user limit from 1,000 to 250 and removed GitLab SSO. In the server code, unlicensed servers get a warning limit of 200 and a hard limit of 250 users; our drill on 12.0.1 returned exactly those numbers.
  • Entry. The Enterprise Edition binary runs free without a licence key as “Mattermost Entry”. It has the features of Enterprise Advanced, with server-wide limits: 10,000 channel messages of history across all channels (older messages stay in the database but cannot be seen or searched), no compliance features, no high availability, no delegated admin roles and community support only. The docs list further limits on board cards, playbook runs, AI queries, call length and push notifications as taking effect in a future release, and say Entry is best suited to teams of fewer than 50 users.
  • Paid plans. Professional, Enterprise and Enterprise Advanced. The docs describe Professional as best for teams of up to 250 users. We do not quote prices here; ask for a written quote at your user count.
  • Self-compiling from the AGPL source is allowed and lets you change limits, but then you own your build, your branding (the trademark policy requires replacing the Mattermost marks in community builds unless permitted) and your security patching.

For Malaikottai, with about 330 users, this means: Team Edition is over its limit, Entry’s 10,000-message window would fill in weeks, and a paid plan is the realistic Mattermost route.

Rocket.Chat: MIT core, Enterprise directories under a commercial licence

  • Code licence. The repository is MIT, except the apps/meteor/ee and ee directories, which are under the Rocket.Chat Enterprise Edition licence. That licence says the software may be used in production only with a valid subscription for the correct number of seats.
  • Starter. Every workspace on 6.5 or later starts as Starter: self-managed, up to 50 users (active or pending users count as seats; guests and deactivated users do not), many premium features with usage limits, unlimited push, no paid support. When you reach the limit, new users cannot be added.
  • Community. The open-source (MIT) option for teams that outgrow Starter and need only basic features: up to 100 concurrent users, Jitsi and BigBlueButton video only, 10,000 push notifications a month, capped apps. The vendor’s own words are that it is “not suitable for production deployment by organizations that depend on Rocket.Chat for business-critical operations”.
  • Paid plans. Commercial, Government and Defense, priced by quote.

Zulip: Apache 2.0, all features free

  • The whole server is Apache 2.0. There is no enterprise directory and no feature key.
  • The self-hosted Free plan includes all features. What you pay for is unlimited push notifications through Zulip’s service (Basic and above) and commercial support (Business and Enterprise).
  • Zulip’s plans page notes that non-workplace users can get large discounts, and eligible communities get free unlimited push.

Around them

Synapse, the main Matrix homeserver, is AGPL-3.0 on GitHub. Check Element’s current terms if you go that way.

Operations and day two

Sizing and hosting

  • Mattermost: one VM with 2 to 4 vCPUs and 4 to 8 GB of RAM is generous for a few hundred users, plus PostgreSQL on the same or a separate VM, and S3-compatible storage or a local disk for files. Our drill showed about 255 MB resident memory a few seconds after start, with plugins still loading. Measure your own peak.
  • Rocket.Chat: one application VM plus a three-member MongoDB replica set for anything you depend on. That is at least four machines or containers in practice, plus object storage for files.
  • Zulip: one dedicated VM; the installer will not share it nicely with other services. 8 GB of RAM for 100 or more daily active users, SSD storage, and swap below 5 GB of RAM.

Backups

  • Mattermost: back up PostgreSQL, the file store and the configuration. From v12, mmctl export can export one team or one channel, and imports can resume after a crash.
  • Rocket.Chat: back up MongoDB (mongodump or replica set snapshots) and the object store, and test that restored file references still work.
  • Zulip: the built-in backup tool captures the database, uploads and settings into one tarball, and restore-backup restores it on a fresh install. 12.1 fixed restore cases with symlinked uploads and permission problems, which is a reminder to test restore after each major upgrade.

Upgrades

  • Mattermost: monthly releases, three months of support for each, 12 months for ESRs. The docs recommend moving from one ESR to the next, and say skipping two ESRs is supported but not tested. For most small teams, staying on ESRs and applying their patch releases is calmer than following every monthly release. v12 shows why to read notes: a database migration with a table lock, a PostgreSQL floor, an OS floor and plugin breakage.
  • Rocket.Chat: standard releases get six months of support, LTS releases 12 months. Moving from 7.x to 8.x needs MongoDB 8 first. 9.0 will change API error codes and licence Custom OAuth.
  • Zulip: two major releases a year, monthly maintenance releases, one command (upgrade-zulip) for the standard install. The project advises upgrading to the latest maintenance release of a new major series rather than the .0. Docker users moving to 12.0 had a manual upgrade guide because the image was reworked.

Monitoring

Watch connection counts, API latency, database and file growth, failed logins, push errors and certificate expiry. Mattermost lists Prometheus performance monitoring as an Enterprise feature; Rocket.Chat 8.0 points to its official Prometheus and Grafana stack; Zulip documents Nagios checks.

Side by side

Architecture

  • Mattermost: one Go binary plus plugins, PostgreSQL 15 or newer, files on disk or S3.
  • Rocket.Chat: Node.js and Meteor, MongoDB 8 replica set, files in object storage; microservices for large installs.
  • Zulip: Django and Tornado with PostgreSQL, Redis, RabbitMQ, memcached and nginx on one dedicated host, or Docker containers.

Conversation model

  • Mattermost and Rocket.Chat: channels with threads; close to Slack habits.
  • Zulip: topics on every message; different habits, easier long-term reading.

Free edition at about 330 users

  • Mattermost: Team Edition capped at 250 users and no SSO; Entry has SSO but a 10,000-message history window. Neither fits; plan for a paid plan.
  • Rocket.Chat: Starter capped at 50 users; Community at 100 concurrent users and described by the vendor as not for business-critical production. Plan for a paid plan.
  • Zulip: Free plan fits with all features, except push for more than 10 users, which needs Basic or Business.

Mobile push

  • Mattermost: TPNS free for non-commercial use without SLA; HPNS on paid plans; ID-only push on Enterprise.
  • Rocket.Chat: unlimited on Starter and paid; 10,000 a month on Community.
  • Zulip: 10 users free for workplaces; unlimited on paid plans; end-to-end encrypted push since 12.0.

Single sign-on

  • Mattermost: Entry and paid plans only.
  • Rocket.Chat: Starter and paid plans; check Community on a test workspace; Custom OAuth licensed from 9.0.
  • Zulip: all plans.

Release and support rhythm

  • Mattermost: monthly; 3 months support, 12 months for ESR.
  • Rocket.Chat: frequent; 6 months support, 12 months for LTS.
  • Zulip: two majors a year, monthly maintenance; latest release recommended.

Operational weight

  • Mattermost: light on a single node; heavier when you add Calls, search clusters and high availability, which are mostly paid.
  • Rocket.Chat: heaviest, because of the MongoDB replica set and frequent breaking changes across majors.
  • Zulip: medium; many services, but the installer and upgrade tool manage them, at the price of owning the whole machine.

A worked plan for Tiruchirappalli

Here is how we would approach Malaikottai Boiler Services, month by month.

Month 1: rules before software

  • Agree with the management and two major customers what must be kept and for how long: for example, commissioning and inspection conversations for the contract period plus a fixed number of years, general chat for a shorter period. Write it down.
  • Decide what a push notification may show. For customer data, choose sender and channel name only, or encrypted push where available.
  • Decide how customer staff join: guest accounts limited to one channel per site, with an end date.
  • Export the current hosted workspace and keep the export safely.
  • Get two written quotes: a paid Mattermost plan for 330 users and a paid Zulip self-hosted plan for push. Rocket.Chat only if omnichannel is a real need.

Month 2: Zulip pilot

  • One VM in the company’s rented data centre rack or a cloud region in India: 4 vCPUs, 8 GB of RAM, 100 GB of SSD, Ubuntu 24.04, with nothing else on it. Install Zulip 12.3 with the standard installer and Certbot.
  • Sign-in with Microsoft Entra ID through Zulip’s built-in support, so people use their existing accounts and leavers lose access when IT disables their account.
  • Register the server for the push service and start a paid plan for the pilot users only.
  • Firewall: 443 and 80 open, 22 only from the IT VPN, 4369 closed, 25 closed unless they use the email gateway.
  • Channels: one per active customer site, with topics per boiler, per visit or per issue; a design channel; a purchase channel. Write a one-page guide with three examples of good topics.
  • Pilot users: 60 people from two customer sites, the design team and the service manager’s office.

Month 3: measure and decide

  • Measure adoption honestly: are site engineers posting in Zulip or still in WhatsApp, and do they use topics?
  • Restore the backup on a fresh VM, run one maintenance upgrade, and remove a guest at contract end.
  • If the pilot works, extend to all 330 users, import the old workspace export with Zulip’s Slack import tool into a test organisation first, then decide whether old history is worth importing at all.
  • If people reject topics, move to the Mattermost quote with a paid plan that covers the full user count, single sign-on and retention. Do not run Team Edition at 330 users or Entry with a 10,000-message window for a company that needs history.

Month 4 onwards: own it

  • Apply maintenance releases monthly; move to 13.x after its first maintenance release.
  • Nightly backups copied off the machine with restic, and a restore test every quarter.
  • Two named people in IT who can upgrade and restore.
  • Close each site’s WhatsApp group once its channel is active, and tell customers why.

When not to adopt each

Do not adopt Mattermost if

  • You have more than about 50 people, need history and single sign-on, and cannot pay for a licence. Team Edition and Entry are both designed to stop you there.
  • You want a guarantee that free features will stay free.
  • Your team has no time to read monthly changelogs and you cannot stay on ESRs.

Do not adopt Rocket.Chat if

  • You do not want to run a MongoDB replica set and upgrade it ahead of the application.
  • You plan to stay on Community for a company-wide, business-critical system. The vendor itself says not to.
  • Your integrations depend on Custom OAuth or on specific REST error codes, and you have not tested 9.0.

Do not adopt Zulip if

  • Your users strongly want a Slack-like experience and the management will not back a change of habit. Topics work well only when people use them.
  • You cannot give it a dedicated VM or run its Docker image properly.
  • You need push for many users but cannot pay for a plan, and you are not an eligible community.

Do not self-host chat at all if

  • Nobody in IT can be on call for it. People notice chat downtime within minutes.
  • Your real problem is WhatsApp groups on personal phones, and you have no plan to retire them. A new server will only add one more place to look.
  • A hosted plan costs less than your hours, and customers have no residency requirement.

A short history

  • Zulip began as a startup in 2012, was acquired by Dropbox in 2014, and was released as open source by Dropbox in 2015. Kandra Labs, founded by the original team lead Tim Abbott, has led development since then.
  • Mattermost began as an internal chat tool at a small game company that had trouble getting its data out of a hosted chat service, and was released as open source in 2015, with an open-core business model.
  • Rocket.Chat also started in 2015, in Brazil, on Meteor, and grew into omnichannel and federation. The free Starter plan arrived with 6.5.
  • In 2025, Mattermost v11 reshaped its free offerings with Entry and the 250-user Team Edition, and GitLab began evaluating the removal of Mattermost from its Omnibus package. In 2026, Zulip made encrypted push generally available, Rocket.Chat moved Custom OAuth towards a licence, and Mattermost v12 raised its PostgreSQL and OS floors.

Decision guide

You want Slack-like habits and can pay for licences at your size

Mattermost on a paid plan, on ESR releases, with PostgreSQL backups you have tested. Read v12’s upgrade notes before you start.

You want every feature free and can accept a new way of working

Zulip on a dedicated VM, with a paid plan only if you need push for more than 10 workplace users.

You need team chat plus customer-facing live chat on one platform

Rocket.Chat on a paid plan, with a MongoDB replica set and a habit of testing each major release.

You are a small team of under 50, no SSO needed

Any of the three works on its free edition, keeping Zulip’s 10-user push limit in mind.

You need federation across organisations

Look at Matrix with Element, or at Rocket.Chat’s native Matrix federation, and read a dedicated comparison before deciding.

Checklist

  • Retention, export and deletion rules written down with business owners.
  • Free edition limits checked against your user counts, in the vendor’s own definitions.
  • Push path, content setting and cost decided.
  • Single sign-on and the leaver process tested.
  • Guests limited to channels, with an end date.
  • TLS proxy in front; database, cache and admin ports private; media ports only if used.
  • Off-machine backups and one full restore practised on a new VM.
  • Versions pinned, a monthly update window, release notes read before majors.
  • Monitoring, two named owners, and a plan to retire the WhatsApp groups.

Common mistakes

  • Choosing by screenshots. The free edition limits decide more than the user interface does.
  • Assuming “open source” means “no limits”. The Mattermost and Rocket.Chat binaries you download enforce edition rules; changing them means building your own.
  • Forgetting push notifications. Field staff live on phones, and push either costs money, is capped, or comes without an SLA.
  • Running the free edition past its size. A 250-user hard limit or a 10,000-message window hits at the worst time, usually during a busy month.
  • Leaving plugin ports open. Our drill found Mattermost’s Calls plugin listening on all interfaces by default.
  • Importing everything. Import what you need and archive the rest.
  • Not testing restore. A chat server without a tested restore is a single point of failure for the company’s memory.

A small hands-on check

We ran a small, local drill on our box on 1 November 2026, around 10:21 PM IST. It used the Mattermost Team Edition 12.0.1 tarball for Linux x86_64 (checksum matched the published SHA-256) with PostgreSQL 17.11 from a user-level binary package, both run as an ordinary user inside an unprivileged network namespace with only loopback and no route outside. No packages were installed and no system services were touched. We did not run Rocket.Chat (MongoDB 8 and Node.js 24) or Zulip (dedicated machine or Docker). Diagnostics, security alerts, the marketplace and push were disabled. What we saw:

  • The server answered its ping endpoint about 3 seconds after start and reported the database as its search backend.
  • The client configuration showed version 12.0.1, not enterprise ready and not licensed.
  • The first account we created became a system administrator automatically. A second self sign-up without an invite was refused with 403. On a real server, create the first account yourself before anyone else can reach the page.
  • The server limits endpoint returned a user warning limit of 200 and a hard limit of 250, with one active user. That matches the source code and the v11 announcement.
  • The main server listened only on 127.0.0.1 as configured, but the pre-packaged Calls plugin opened a listener on port 8443 on all interfaces. It also tried to look up Mattermost’s public STUN server, and the server tried to fetch product notices from Mattermost; both failed offline with warnings only.
  • The pre-packaged Playbooks plugin refused to activate with the message that it requires a Professional licence or higher.
  • The Mattermost process used about 255 MB of resident memory a few seconds after start, with PostgreSQL using about 23 MB. Real use will be higher; do not size from this.
  • After the run, the database directory was 44 MB and the Mattermost data folder 243 MB, mostly extracted plugins. Both processes stopped cleanly.

The point is not speed. The first minutes of a new chat server already show licence limits, default listeners and outbound calls, and it is easier to find them on a test machine than in production.

Unlearn, re-learn

  • Unlearn “self-hosted means free”. Re-learn that free editions have user, history or push limits, and that the limits matter more than the licence name.
  • Unlearn “chat is just messages”. Re-learn that it is also files, retention, guests, phones and a push path through Apple and Google.
  • Unlearn “the Slack clone is the safe choice”. Re-learn that a different model, like Zulip’s topics, may suit long-running work better, if people are helped to adopt it.
  • Practise: count your registered, active and concurrent users today, list who needs phone notifications, and write one paragraph on how long chat must be kept. Then read each vendor’s free edition page with those three numbers in hand.

Sources

Mattermost

Rocket.Chat

Zulip

Around them

comments powered by Disqus

Releted Posts

Self-hosted email in 2026: revisit Stalwart, mailcow and Mailu before you run another mail server

Every few years, an Indian company with a few hundred people asks the same question about email. The hosted suite renewal has come in higher than last year, or the old mail server set up by a contractor in 2017 is running on an operating system that no longer gets updates, or invoices sent from the ERP have started landing in spam.

Read more

Virtualization platforms in 2026: revisit Proxmox VE, XCP-ng and Incus before you migrate another virtual machine

Most virtualization migrations in India over the last two years did not start with an architecture review. They started with a renewal quote.

Read more

Infrastructure monitoring in 2026: revisit Zabbix, Checkmk and Netdata before you add another host to your monitoring

In most Indian companies, monitoring starts with a person, not a tool. Somebody in the IT team logs in to the file server every morning, checks the disk, looks at the UPS panel, pings the branch router, and goes back to work.

Read more