Slack's per-seat pricing has the same shape as every other per-seat product: the number of people who need to read messages grows faster than the number of people producing anything, and each of them is a full seat. Add contractors and the bill stops tracking the value.
So teams go looking for something they can run themselves. The candidates are well known. What is less well known is the pair of details that actually decide how the migration goes, and neither of them appears on a feature comparison table.
Which of these is actually open source
Read from the repositories themselves, on 17 August 2026:
| Project | Stars | Licence as GitHub reports it | What the repository shows |
|---|---|---|---|
| Rocket.Chat | 46.0k | NOASSERTION | One LICENSE, plus a separate ee/ directory |
| Mattermost | 38.8k | NOASSERTION | Ships LICENSE.txt and LICENSE.enterprise |
| Zulip | 25.7k | Apache-2.0 | A single licence across the repository |
| Synapse (Matrix) | 4.5k | AGPL-3.0 | Reference server for the Matrix protocol |
"NOASSERTION" is GitHub's way of saying it could not resolve the repository to one standard licence. In both cases the reason is the same open-core arrangement: a freely licensed core, plus a directory of enterprise features under separate commercial terms. Mattermost makes it explicit with a second licence file; Rocket.Chat keeps the enterprise edition in ee/.
None of this is hidden and none of it is wrong. It matters for one specific reason: if your motivation for leaving Slack includes a policy requirement that the software be OSI-licensed, Zulip is the only one of the three that satisfies it across the whole codebase.
We should be straight about the consequence for us. Our catalogue ships Mattermost and Rocket.Chat, each with a tuned compose file. It does not ship Zulip. If the licence is your deciding factor, the honest answer is that the one you want is not one we have packaged, and you would be deploying it yourself.
The part you cannot self-host
Here is the detail that surprises people after the migration rather than before it.
You can run the server. You cannot run the mobile push notifications, at least not without more work than anyone expects.
Push delivery to an iOS or Android app goes through Apple's and Google's push services, and both tie delivery to the credentials of the app as published in the store. The official Mattermost and Rocket.Chat mobile apps were published by Mattermost and Rocket.Chat. So when your self-hosted server needs to wake a phone, the notification is relayed through the vendor's push service, because only the vendor holds the keys that Apple and Google will accept for that app.
This is not a secret. Mattermost publishes its push proxy as a separate Apache-2.0 project, mattermost-push-proxy, precisely so you can run that hop yourself. But running it only helps if you also build, sign and distribute your own mobile app, because the proxy needs certificates for an app you control. For most teams that is a bigger project than the migration was.
The practical read:
- If your requirement is cost or control of your data at rest, this changes nothing. Configure the notification content to carry no message body and the relay carries only a wake-up.
- If your requirement is that no third party sees any metadata about your communications, then plan for either a custom mobile app or desktop and web clients only. Decide this before you migrate, not after someone asks.
Mattermost or Rocket.Chat
For teams that are not licence-constrained, this is the real choice, and the two differ most in the shape of what you end up operating. Read from the compose files we ship:
Mattermost runs mattermost-team-edition against PostgreSQL, and keeps state across several volumes: configuration, data, logs, plugins, client plugins, and a Bleve search index. Only configuration, data and the database really need backing up; the logs, plugins and search index rebuild. But you have to know that, because a naive "back up every volume" is heavier than it needs to be, and a naive "back up one volume" loses your configuration.
Rocket.Chat runs against MongoDB with a single data volume. Simpler to back up, and a different database to operate. If your team already runs Postgres and has never run Mongo, that is a real consideration and it points at Mattermost.
Beyond operations: Mattermost is the more conservative, more Slack-shaped product, and the one to pick if the goal is for nobody to notice the change. Rocket.Chat casts wider, with omnichannel and customer-facing chat features, which is an advantage if you want them and surface area you do not need if you do not.
Zulip deserves a mention on its own merits rather than just its licence. Its threading model is genuinely different - conversations are organised by topic within a channel rather than as a flat stream - and teams that adopt it tend to be emphatic about it. It is the one option here that is not trying to be Slack.
What it costs to run
Each of these is one application container plus one database. The bill becomes the machine rather than the headcount, which was the entire point of leaving.
On a flat plan starting at $5 a month they run beside whatever else you already host. The saving is real, but be honest about what replaces the cost: someone now owns upgrades, backups and the restore test.
When to stay on Slack
Stay if the integrations are load-bearing. Slack's app directory is the product for a lot of teams, and the equivalents are thinner.
Stay if the people using it are non-technical and the polish is why it works. This is the same conversation as every self-hosting migration, and the people who feel the difference are the ones who never asked what the software was called.
Stay if nobody will own the upgrades. An abandoned self-hosted chat server is worse than a bill.
Move if the seat count is what is growing, if the messages have to sit on infrastructure you control, or if you want a chat system that outlives a pricing change.
Frequently asked questions
What is the best self-hosted Slack alternative? Mattermost if you want the least disruption and already run Postgres. Rocket.Chat if you want a broader product and are comfortable with MongoDB. Zulip if you want a single OSI licence across the codebase, or if its topic-based threading appeals.
Is Mattermost open source?
The core is, but the repository also ships LICENSE.enterprise covering enterprise features. GitHub reports the repository as NOASSERTION for that reason. The same is true of Rocket.Chat, which keeps its enterprise edition in an ee/ directory.
Do mobile push notifications work on a self-hosted server? Yes, but they are relayed through the vendor's push service, because push delivery is tied to the credentials of the app published in the app stores. You can run the relay yourself only if you also publish your own mobile app.
Can I import my Slack history? Mattermost and Rocket.Chat both provide Slack import tooling that reads Slack's export. Expect channels and messages to travel well, and integrations, workflows and some formatting not to. Run the import into a scratch instance first.
What do I need to run one? The application container, its database, and a volume. Any small instance handles a team-sized deployment; the ongoing work is upgrades and backups, not capacity.