Self-hosted Slack alternatives compared

Which self-hosted Slack alternative should you run

The self-hosted Slack alternatives worth a small team's time are Mattermost, Rocket.Chat, Matrix with Synapse, and Zulip. For an internal team tool on one server, run Mattermost. For a public community, run Zulip. Run Matrix with Synapse when you have to talk to servers other people own, and only then, because federation is the one thing the others cannot copy and it is also the thing that changes your job as an administrator.

Feature lists will not separate these four. They all do channels, threads, search, file uploads and mobile apps. What separates them is what they ask of you every month: memory, a database you have to keep alive, a mobile push path you may not control, and a licence that decides whether the feature you need sits behind a payment. The comparison below runs on those axes, at ten users and at a hundred.

What each of the four actually is

Mattermost is a Go server with a PostgreSQL database. One binary, one database, one configuration file. It behaves like Slack, threads and slash commands included, and it is the least interesting of the four to operate, which is a compliment.

Rocket.Chat is a Node.js application on MongoDB. It carries the widest feature set here, including voice and video calls, and an omnichannel inbox that pulls customer conversations from email and social channels into the same interface. If that inbox is the reason you are looking, weigh it against a dedicated Chatwoot support desk first, because a chat server doing support work is a different job from a chat server doing team work.

Matrix is a protocol, not a product. Synapse is the reference server (Python, PostgreSQL) and Element is the client most people use. This is the only option here where your server can speak to servers you do not run.

Zulip is a Python server (Django plus Tornado) with PostgreSQL, RabbitMQ, memcached and Redis behind it, installed as one unit by its own script. Its model is topics inside channels, so a conversation from Tuesday is still findable on Friday. Version 12.0 landed in April 2026.

How much RAM and which database, at 10 users and at 100

Every number in the chart below comes from the project's own documentation, read in August 2026. None of it is a measurement of mine and none of it is invented. The basis is the same for every row: the smallest configuration that project publishes, with the database counted when the project sizes it separately.

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

The rows are not the same shape, and that is the first useful finding. Synapse's 1 GB is a floor for the Synapse process with a condition attached: the docs ask for at least that much free RAM if you want to join large public rooms. PostgreSQL sits outside that figure. Mattermost's 2 GB is the whole machine, database included, and it covers 1 to 1,000 users on a single vCPU. Zulip documents 2 GB and one CPU below 100 users, plus 2 GB of swap, then 4 GB and two CPUs at 100 users and above. Rocket.Chat publishes the largest number here, 8 GB, because it sizes the application at 4 GiB and MongoDB at 4 GiB, and that tier is rated for up to 500 concurrent users.

At ten users, all 4 of them run on hardware you would not think about twice. At a hundred the answers separate: Mattermost is still inside its 2 GB tier, Zulip wants 4 GB and a second CPU, and Rocket.Chat's smallest documented tier is unchanged at 8 GB, because MongoDB's memory appetite is set by the machine rather than by your user count.

The database choice decides your future upgrades more than your daily performance. Mattermost needs PostgreSQL 14 or newer and has deprecated MySQL support starting at v11, so a MySQL install today is a migration tomorrow. Synapse runs on SQLite and its own docs say plainly that SQLite is acceptable only for testing, because it performs badly in large rooms. Rocket.Chat 8 requires MongoDB 8.0, which means the database upgrade and the chat upgrade are one project rather than two.

What does a 2 GB VPS really get you

The 2 GB plan is the entry size at most providers, and it is a real answer for two of these four.

• Mattermost fits. It is the only one whose vendor documents that exact size, for up to 1,000 users, with PostgreSQL on the same box. Ten people on 2 GB is comfortable.
• Zulip fits, with swap. The docs recommend swap on anything under 5 GB and warn that minimal-RAM machines hit out of memory errors during upgrades, where tools/webpack is the step that fails. That is a real failure you will meet at upgrade time, not at install time.
• Synapse fits while it is quiet. The idle cost is small. The spike is the problem, and the section on federation below explains where it comes from.
• Rocket.Chat is the one to avoid at 2 GB, and the cause is MongoDB's storage engine. WiredTiger sizes its internal cache at the larger of 50% of (RAM minus 1 GB) or 256 MB, so on a 2 GB machine it reserves roughly 512 MB before Node.js has started. The result is not a clean refusal. It installs, it runs, it slows down as history grows, and eventually the kernel out of memory killer stops whichever process was largest at the time.

Check what you actually have before you decide, because providers count RAM differently from free:

free -h
swapon --show

Remember that the chat server is not the only thing on the box. TLS (transport layer security) termination, backups and a container runtime all want memory. Put whichever server you choose behind a reverse proxy you understand, Nginx, Caddy or Traefik, and if you deploy with containers, the Docker Compose basics for a VPS are the part worth getting right first.

Do the mobile apps need your own push server

This is the axis people discover after they deploy, and it is the one that most often decides the answer.

Here is the mechanism. Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM) accept a notification only from whoever holds the signing credentials for that specific app. Your server cannot push to an app you did not build. So a self-hosted chat server using the vendor's App Store build must hand its notifications to the vendor's gateway, and the vendor sets the terms.

• Mattermost. The free path is the Test Push Notification Service (TPNS) at https://push-test.mattermost.com, which the docs state is not recommended for production and carries no service level agreement (SLA). It works only with the App Store and Play Store builds. The Hosted Push Notification Service (HPNS) is production grade and needs a paid subscription. The third route is compiling the push proxy yourself, which then requires your own app builds with your own APNs and FCM credentials.
• Rocket.Chat. Push requires registering the workspace with Rocket.Chat Cloud, and community workspaces are capped at 10,000 push notifications per month. That is about 330 a day for the whole workspace. When the quota is spent, notifications stop arriving until the month resets, which reads to users as the app being broken.
• Matrix with Element. Synapse sends notifications to a push gateway, and the official Element apps are pointed at the gateway matrix.org runs at https://matrix.org/_matrix/push/v1/notify. The payload carries the event and room identifiers rather than the message text, and the app fetches the content from your server, so the gateway sees metadata rather than conversations. Running your own Sygnal gateway is supported and means building and distributing your own apps. On Android there is a middle road: UnifiedPush with an ntfy server you host.
• Zulip. The free plan includes the mobile push service for up to 10 users. Above 10 users you need a plan, and the free Community plan covers many non-commercial organisations. Zulip 12.0, in April 2026, added end to end encryption for push payloads.

At ten users every one of these gives you working notifications at no cost. At a hundred, the picture changes: Zulip requires a plan, Mattermost keeps working on the test service with no SLA and no support, Rocket.Chat's monthly cap becomes the constraint, and Matrix is unaffected because the gateway is free to use.

Which ones give you single sign-on for free

Single sign-on (SSO) is where the open core business model shows itself most clearly.

• Zulip includes SAML (security assertion markup language) and LDAP (lightweight directory access protocol) in the self-hosted server at no cost. There is no separate tier to buy.
• Synapse supports OpenID Connect (OIDC), SAML and CAS in its own configuration file, free. Newer deployments increasingly use the Matrix Authentication Service, a separate service with a one way migration from classic Synapse authentication, so plan that move rather than discovering it.
• Rocket.Chat community edition does basic LDAP and SAML login. Syncing extended user attributes, mapping groups and teams, and background synchronisation need an enterprise licence.
• Mattermost free Team Edition gives you GitLab OAuth and nothing else. SAML, AD/LDAP and OpenID Connect are paid features.

If you plan to run several services behind one login, put a self-hosted Authentik identity provider in front of them and check which of the four can actually talk to it on the licence you hold.

What federation really costs you

Federation is Matrix's reason to exist. Your user joins a room hosted on someone else's server and talks to people whose accounts live there, the way mail servers exchange mail. No other option here does this. If you need it, nothing else on this page is a substitute.

It is also the reason Synapse is a different kind of workload. When your user joins a federated room, your server takes on a copy of that room's state and its events, and it caches the media that users on other servers post: avatars, images and files. Your disk use is then driven by rooms you did not create and by people who do not have accounts on your server. This is why Synapse installs grow a media store far larger than the volume of messages their own users sent. It is also why joining a large public room is the specific operation the docs attach a memory condition to.

Set the retention policy on day one rather than the day the disk fills:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse gained media_retention in version 1.61, with separate lifetimes for local and remote media. Remote media is a cache, so if a user asks for a purged file again, Synapse re-requests it from the server it came from. Local media is not a cache, so a short local_media_lifetime deletes your own users' uploads permanently.

The honest summary: if your users only ever talk to each other, federation gives you nothing and charges you disk, bandwidth and a heavier upgrade path. Turn it off, or pick a different server.

How do upgrades go

Zulip is the easiest. One script, and the documented downtime is under 30 seconds unless a large database migration is involved. Install and upgrade look like this, run by you on the server:

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

Run the installer as root. The --push-notifications flag registers the server with the mobile push service during install, and it asks you to accept the terms of service at that moment, so read them before you start.

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

Later upgrades are the same tarball plus one command:

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost is predictable. Replace the binary, restart, and migrations run at startup. Since the August 2025 releases the Extended Support Release (ESR) track ships every 9 months with 12 months of support, and ESR to ESR upgrades are the tested path. Skipping several ESRs at once is supported but not tested, which in practice means you are the one testing it.

Rocket.Chat couples three upgrades together. As of August 2026 the 8.x line is current, with 8.7.0 released on 6 August 2026, and it requires MongoDB 8.0 and a matching Node.js version. Skipping a major version is how people end up with a database the application refuses to open. The Rocket.Chat Docker Compose install guide pins these together for you, which is the main argument for the container route here.

Synapse needs reading. Every release has upgrade notes, and you must read the notes for each version you pass through, not only the one you land on. After the upgrade, Synapse runs background updates against the database. On a small server these can keep the machine slow for hours, and that is expected behaviour rather than a fault.

Licence terms, in plain words

Mattermost distributes its compiled Team Edition builds under the MIT licence, while the source is offered under AGPLv3 or a commercial licence, with parts of the repository under the Mattermost Source Available License that requires a paid licence to run in production. Rocket.Chat is MIT except for the ee/ directories, which carry their own enterprise licence. Synapse moved from Apache 2.0 to AGPLv3 with version 1.99.0, and contributors sign a CLA that lets Element sell exceptions to that licence. Zulip is Apache 2.0 with no enterprise directory, which is why its SSO story has no asterisk.

The practical reading: AGPL matters to you only if you plan to modify the server and offer it to others as a service. What matters far more to a small team is the open core line, meaning which features are missing from the free build. Zulip has the fewest, Mattermost has the most.

Which one should you pick

An internal team tool. Mattermost. It has the smallest documented footprint, the most boring upgrades, and a familiar interface that needs no explaining. Plan for a paid plan on the day SSO becomes a requirement, because that day arrives for most teams.

A community server. Zulip. Topics keep a busy public channel readable months later, SAML and LDAP cost nothing, and upgrading is one command. If your community is closer to posts and replies than to live chat, compare self-hosted forum software first, since a forum indexes better in search and needs no push infrastructure at all. Pick Rocket.Chat instead when you want the voice, video and omnichannel features, and can give it the 8 GB its own documentation asks for.

A network that must interoperate. Matrix with Synapse and Element. Accept the media growth, set retention on day one, give it PostgreSQL and more disk than you think, and get real value from talking to servers you do not control. Choosing Synapse for a team that never federates is paying that cost for nothing.

FAQ

What is the best self-hosted Slack alternative for a small team?

Mattermost, for most internal teams. Its documentation covers 1 to 1,000 users on one vCPU and 2 GB of RAM with PostgreSQL on the same machine, so it fits the entry-size VPS plan that most providers sell. The catch is single sign-on: the free Team Edition supports GitLab OAuth only, and SAML, AD/LDAP and OpenID Connect all require a paid plan. If free SSO matters more than the Slack-like interface, run Zulip instead.

Can I run a self-hosted chat server on a 2 GB VPS?

Mattermost yes, and Zulip yes if you add swap, which Zulip's own docs recommend below 5 GB. Rocket.Chat is the one that will disappoint you, because MongoDB's WiredTiger engine claims the larger of 50% of (RAM minus 1 GB) or 256 MB for its cache, so roughly 512 MB of a 2 GB box is gone before the application starts. It will install and then degrade as history grows, ending in an out of memory kill. Rocket.Chat's smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB.

Do self-hosted chat servers need their own mobile push notification server?

Usually no, because Apple's APNs and Google's FCM only accept notifications from whoever signed the app, so the vendor's app uses the vendor's gateway. The terms differ. Mattermost offers a free test service with no SLA and a paid hosted service. Rocket.Chat caps community workspaces at 10,000 push notifications per month, after which delivery stops until the month resets. Zulip includes push free for up to 10 users and requires a plan above that. Matrix homeservers push through the gateway used by the Element apps at no cost. You only need your own gateway if you also ship your own app builds.

Should I self-host Matrix and Synapse for a team that never talks to other servers?

No. Federation is what Synapse is for, and it is also what makes it heavier to run. Joining rooms on other servers pulls their state and caches their media onto your disk, so storage grows for reasons unrelated to your own users. Set media_retention with a short remote_media_lifetime before that happens. A team that only talks to itself gets the operational cost and none of the benefit, and Mattermost or Zulip will do the same job on less hardware.

Which self-hosted Slack alternative has free single sign-on?

Zulip and Synapse. Zulip includes SAML and LDAP in the self-hosted server at no cost, and Synapse supports OpenID Connect, SAML and CAS in its configuration, with newer installs moving to the separate Matrix Authentication Service. Rocket.Chat's community edition does basic LDAP and SAML login but puts attribute sync, group mapping and background sync behind an enterprise licence. Mattermost's free Team Edition supports GitLab OAuth only.