Self-hosted Slack alternatives: which one fit you?

Wetin self-hosted Slack alternative you suppose run

Self-hosted Slack alternatives wey worth small team time na Mattermost, Rocket.Chat, Matrix with Synapse, and Zulip. For internal team tool wey dey one server, run Mattermost. For public community, run Zulip. Run Matrix with Synapse when you must talk to servers wey other people own, and only for that case, because federation na the one thing wey the others no fit copy, and na also the thing wey go change your work as administrator.

Feature lists no go separate these four. All of dem get channels, threads, search, file uploads, and mobile apps. Wetin separate dem na wetin dem require from you every month: memory, database wey you must keep running, mobile push path wey you fit no control, and licence wey decide whether the feature you need dey behind payment. The comparison below use these points, for ten users and for a hundred.

Wetin each of the four really be

Mattermost na Go server wey get PostgreSQL database. One binary, one database, one configuration file. E dey behave like Slack, threads and slash commands join, and na the easiest of the four to operate, which mean say e no dey give much wahala.

Rocket.Chat na Node.js application wey dey run on MongoDB. E get the widest feature set for here, including voice and video calls, plus omnichannel inbox wey dey bring customer conversations from email and social channels enter the same interface. If na that inbox make you dey look, compare am with dedicated Chatwoot support desk first, because chat server wey dey handle support work different from chat server wey dey handle team work.

Matrix na protocol, no be product. Synapse na the reference server (Python, PostgreSQL), while Element na the client wey most people dey use. Na only this option for here wey your server fit communicate with servers wey you no dey run.

Zulip na Python server (Django plus Tornado) wey PostgreSQL, RabbitMQ, memcached and Redis dey support behind am. E dey install as one unit with its own script. Its model na topics inside channels, so conversation from Tuesday still easy to find on Friday. Version 12.0 land for April 2026.

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

Every number for the chart below come from the project documentation itself, wey I read again on 18 October 2026. None of dem na my own measurement, and I no invent any of dem. The basis dey the same for every row: the smallest configuration wey the project publish, with the database included when the project size am 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."
  },
  {
    "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 no get the same format, and na that be the first useful finding. Synapse's 1 GB na the minimum for the Synapse process, but e get one condition: the docs ask for at least that amount of free RAM if you want join large public rooms. PostgreSQL dey outside that figure. Mattermost's 2 GB na a single-server figure wey cover 1 to 1,000 users on one vCPU, although the requirements page no talk whether PostgreSQL dey share that server. Zulip document 2 GB and one CPU for below 100 users, plus 2 GB swap. For 100 users and above, e need 4 GB and two CPUs. Rocket.Chat publish the biggest number here, 8 GB, because e size the application at 4 GiB and MongoDB at 4 GiB. That tier fit handle up to 500 concurrent users.

For ten users, all 4 of dem fit run on hardware wey you no need think about twice. For 100 users, the requirements separate: Mattermost still dey inside im 2 GB tier, Zulip need 4 GB and second CPU, while Rocket.Chat's smallest documented tier remain 8 GB. This happen because MongoDB memory demand depend on the machine, no be on your user count.

The database choice go decide your future upgrades more than your daily performance. Mattermost v12.0, wey release on 16 October 2026, need PostgreSQL 15 or newer and no longer support PostgreSQL 14 and earlier. The v11.7 ESR still accept PostgreSQL 14. Support for MySQL end with v11.0 for October 2025, so MySQL installation must migrate to PostgreSQL to remain on supported release. Synapse run on SQLite, and im own docs talk plainly say SQLite only dey okay for testing because e perform badly inside large rooms. Rocket.Chat 8 require MongoDB 8.0, so the database upgrade and chat upgrade na one project, no be two.

Wetin 2 GB VPS really fit give you

2 GB plan na the entry size for most providers, and e be real option for two out of these four.

• Mattermost fit run. The vendor documentation specify this exact size for 1 to 1,000 users on one server. Na the widest user range among the four services wey 2 GB fit handle. Ten people on 2 GB go dey comfortable.
• Zulip fit run, with swap. The vendor documentation specify 2 GB too, for fewer than 100 users, and e require swap for anything under 5 GB. E recommend 2 GB swap. The upgrade documentation warn say machines with small RAM fit get out of memory errors during upgrades, where tools/webpack usually na the step wey fail. Na real failure wey you go meet during upgrade, not during installation.
• Synapse fit run when activity low. The idle memory cost small. The problem na the spike, and the federation section below explain where e dey come from.
• Rocket.Chat na the one to avoid for 2 GB, and MongoDB storage engine na the cause. WiredTiger set its internal cache to the larger value between 50% of (RAM minus 1 GB) and 256 MB. So for 2 GB machine, the cache fit grow reach about 512 MB alongside Node.js. This figure na maximum, not memory wey e reserve upfront. The cache go fill toward that limit as history dey grow. The result no be clean refusal. E install, e run, e slow down as history dey grow, and later the kernel out of memory killer go stop whichever process big pass at that time.

Check wetin you actually get before you decide, because providers dey count RAM differently from free:

free -h
swapon --show

Remember say chat server no be the only thing for the box. TLS (transport layer security) termination, backups, and container runtime all need memory. Put whichever server you choose behind reverse proxy wey you understand, Nginx, Caddy or Traefik, and if you deploy with containers, Docker Compose basics for VPS na the part wey you suppose get right first.

Mobile apps need una own push server?

Na this be the angle wey people discover after dem deploy, and na the one wey most times decide the answer.

Na so e work. Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM) go accept notification only from whoever get the signing credentials for that particular app. Your server no fit send push to app wey you no build. So self-hosted chat server wey dey use vendor App Store build must send its notifications to vendor gateway, and na vendor go set the terms.

• Mattermost. The free option na Test Push Notification Service (TPNS). The docs now offer am only to non-commercial self-hosted customers, no recommend am for production, and talk say e no get service level agreement (SLA). E work only with App Store and Play Store builds. Hosted Push Notification Service (HPNS) na production-grade option, and dem offer am to Professional, Enterprise and Cloud customers. The third option na to compile the push proxy yourself. That one require your own app builds with your own APNs and FCM credentials.
• Rocket.Chat. Push require you to register the workspace with Rocket.Chat Cloud, and community workspaces get limit of 10,000 push notifications per month. That na about 330 per day for the whole workspace. When quota finish, notifications stop to arrive until the month reset, so users go think say the app don spoil. The free Starter plan, for up to 50 users, list push notifications as unlimited.
• Matrix with Element. Synapse dey send notifications to a push gateway, and the official Element apps point to the gateway wey matrix.org dey run for https://matrix.org/_matrix/push/v1/notify. The payload carry event and room identifiers instead of message text, and the app go fetch the content from your server. So the gateway see metadata, not conversations. You fit run your own Sygnal gateway, but that means you must build and distribute your own apps. For Android, middle option dey: UnifiedPush with an ntfy server wey you host.
• Zulip. The free self-hosted plan include mobile push service for up to 10 users. Above 10 users, you need paid plan, unless your organisation qualify for free unlimited notifications as community, open source project, small non-profit, or similar group. Zulip 12.0, for April 2026, make end to end encrypted push notifications generally available. E go switch on when both server and app recent enough.

For ten users, all these options give you working notifications at no cost, except one: commercial Mattermost installation no qualify for the test service. For a hundred users, the situation change: Zulip require paid plan unless your organisation qualify for free community use; non-commercial Mattermost still dey work on test service with no SLA and no support; Rocket.Chat monthly cap become the limitation, and its free Community plan itself get documentation for up to 100 concurrent users; Matrix no get this problem because the gateway free to use.

Wetin dem give you single sign-on for free

Single sign-on (SSO) na where open core business model dey show itself pass.

• Zulip include SAML (security assertion markup language) and LDAP (lightweight directory access protocol) for the self-hosted server without charge. You no need buy separate tier.
• Synapse support OpenID Connect (OIDC), SAML and CAS for its own configuration file, free. Newer deployments dey increasingly use Matrix Authentication Service, wey be separate service with one-way migration from classic Synapse authentication, so plan that move instead of discovering am later.
• Rocket.Chat no include directory login and SSO for its free Community plan, but small team still fit get dem without payment. Its plans page list only basic identity management for Community, and put Active Directory and LDAP authentication, single sign-on and multi-factor authentication for Starter plan, wey free and self-managed for up to 50 users. The paid plans na Commercial, Government and Defense. The authentication docs add deadline for version 9.0.0 and later: LDAP, SAML and Custom OAuth require premium plan, and Community workspace wey sign users in that way must upgrade its plan or move those users to another login method before updating, otherwise dem no go fit log in. The plans page define premium plans as those three paid ones, while e still list directory login and SSO under Starter, so confirm wetin Starter workspace still keep before you move am to 9.0.0. Version 9.0.0 never ship as of 20 October 2026, so treat LDAP and SAML for Community as something wey you go lose, not something to build on.
• Mattermost change its free offer with v11.0 for October 2025. The open source Team Edition no get SSO again: GitLab SSO remove from am, and e target teams under 250 activated users. The free Mattermost Entry build include SAML, AD/LDAP and OpenID Connect, but Mattermost dey target am at teams under 50 users and limit am to the latest 10,000 channel messages for history. Once you pass those limits, SSO mean paid plan.

If you plan run several services behind one login, put self-hosted Authentik identity provider for front of dem and check which one of the four fit actually talk to am with the licence wey you get.

Wetin federation really cost you

Federation na the main reason Matrix dey exist. Your user fit join room wey dey for another person server and talk to people wey their accounts dey there, just as mail servers dey exchange mail. No other option for here fit do this. If you need am, nothing else for this page fit replace am.

Na federation still make Synapse be different kind workload. When your user join federated room, your server go keep copy of the room state and events, and e go cache media wey users for other servers post: avatars, images and files. Your disk usage go then depend on rooms wey you no create and people wey no get accounts for your server. Na why Synapse installations fit grow media store wey far bigger pass the volume of messages wey their own users send. Na still why the docs connect joining large public room with specific memory requirement.

Set retention policy from day one, no be when disk don full:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse gain media_retention for version 1.61, with separate lifetimes for local and remote media. Remote media na cache, so if user ask for purged file again, Synapse go request am again from the server wey e come from. Local media no be cache, so short local_media_lifetime go permanently delete uploads wey your own users make.

The honest summary be say: if your users dey only talk to each other, federation no give you anything, but e go use disk, bandwidth and make upgrades more difficult. Turn am off, or choose another server.

How upgrades dey go

Zulip na the easiest. One script, and the documented downtime na under 30 seconds unless large database migration dey involved. Installation and upgrade dey look like this, and na you go run am for 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 register the server with the mobile push service during installation. E also ask you to accept the terms of service at that time, so read dem before you start.

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

Later upgrades na 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 dey predictable. Replace the binary, restart am, and migrations go run when e start. The Extended Support Release (ESR) track dey release every 9 months with 12 months of support. ESR to ESR upgrades na the path wey dem don test. You fit skip several ESRs at once, but dem never test am. For practical terms, na you go test am.

Rocket.Chat dey join three upgrades together. As of October 2026, the 8.x line na the current one. 8.9.0 come out on 5 October 2026, and e require MongoDB 8.0 plus matching Node.js version. If you skip a major version, you fit end up with database wey the application refuse to open. Before the next major version, 9.0.0, check how your users dey sign in, because that release dey move LDAP, SAML and Custom OAuth behind a premium plan. The Rocket.Chat Docker Compose installation guide pin these things together for you. Na the main reason to use the container route here.

Synapse need careful reading. Every release get upgrade notes, and you must read the notes for every version wey you pass through, no be only the version wey you land on. After the upgrade, Synapse dey run background updates against the database. For small server, this fit make the machine slow for hours. Na expected behaviour, no be fault.

Licence terms, for plain language

Mattermost dey distribute im compiled Team Edition builds under MIT licence, while dem dey offer the source under AGPLv3 or commercial licence. Some parts of the repository dey under Mattermost Source Available License, wey require paid licence before you fit run am for production. Rocket.Chat na MIT except for the ee/ directories, wey get their own enterprise licence. Synapse move from Apache 2.0 go AGPLv3 for version 1.99.0, and contributors dey sign CLA wey allow Element sell exceptions to that licence. Zulip na Apache 2.0, and e no get enterprise directory. Na why im SSO story no get asterisk.

The practical meaning be say AGPL require something from you if you modify the server and allow other people use am through network, or if you give anybody copies of am, whether you modify am or not, because you must give the source along with the copies. If you run am without modification for your own team, none of these requirements apply. The thing wey matter pass for small team na the open core line: which features no dey for the free build. Zulip get the fewest, while Mattermost get the most.

Which one you suppose pick

For internal team tool. Mattermost. E cover the widest range of users for 2 GB machine, e get the most straightforward upgrades, and e get familiar interface wey no need plenty explanation. Plan for Mattermost Entry or paid plan on the day SSO become requirement, because that day dey come for most teams and Team Edition no offer any SSO again.

For community server. Zulip. Topics dey keep busy public channel readable even after months, SAML and LDAP no cost anything, and upgrade na one command. If your community dey closer to posts and replies than live chat, compare self-hosted forum software first, because forum dey index better for search and no need push infrastructure at all. Pick Rocket.Chat instead when you want voice, video, and omnichannel features, and you fit give am the 8 GB wey the documentation ask for.

For network wey must interoperate. Matrix with Synapse and Element. Accept the media growth, set retention from day one, give am PostgreSQL and more disk than you think you need, and get real value from talking to servers wey you no control. If you choose Synapse for team wey never federate, you dey pay that cost for nothing.

FAQ

Which self-hosted Slack alternative dey best for small team?

Mattermost, for most internal teams. E documentation cover 1 to 1,000 users for one server with one vCPU and 2 GB RAM, so e fit the entry-size VPS plan wey most providers dey sell. The catch na single sign-on: since v11.0, open source Team Edition no get am, and SAML, AD/LDAP and OpenID Connect dey either for paid plan or free Mattermost Entry build. That build target teams wey get below 50 users and limit message history to the latest 10,000 channel messages. If free SSO without those limits matter pass Slack-like interface, run Zulip instead.

I fit run self-hosted chat server for 2 GB VPS?

Mattermost yes, and Zulip yes for below 100 users if you add swap, because Zulip own docs require am below 5 GB. Rocket.Chat na the one wey go disappoint you, because MongoDB WiredTiger engine fit make e cache grow reach the larger of 50% of (RAM minus 1 GB) or 256 MB. For 2 GB machine, that mean roughly 512 MB fit go the cache as history dey build up, apart from the application itself. E go install, then performance go reduce as history grows, until out of memory kill happen. Rocket.Chat smallest published tier na 4 GiB for the app plus 4 GiB for MongoDB.

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 sign the app, so vendor app dey use vendor gateway. The terms no be the same. Mattermost give non-commercial self-hosted users free test service with no SLA, and e offer paid hosted service. Rocket.Chat limit community workspaces to 10,000 push notifications per month. After that, delivery go stop until the month reset. Zulip include push free for up to 10 users and require paid plan above that, unless the organisation qualify for free community use. Matrix homeservers push through the gateway wey Element apps dey use, at no cost. You only need your own gateway if you also ship your own app builds.

I suppose self-host Matrix and Synapse for team wey never dey talk to other servers?

No. Federation na wetin Synapse dey for, and na also wetin make am heavier to run. Joining rooms for other servers go pull their state and cache their media for your disk, so storage go grow for reasons wey no relate to your own users. Set media_retention with short remote_media_lifetime before that happen. Team wey only dey talk among themselves go carry the operational cost without any benefit, and Mattermost or Zulip go do the same work with less hardware.

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

Zulip and Synapse, with no hidden condition. Zulip include SAML and LDAP for the self-hosted server at no cost, and Synapse support OpenID Connect, SAML and CAS for its configuration. Newer installs dey move to the separate Matrix Authentication Service. Mattermost free Entry build include SAML, AD/LDAP and OpenID Connect, but e target teams wey get below 50 users and limit message history. Its open source Team Edition no get SSO since v11.0. Rocket.Chat list only basic identity management for its free Community plan and put LDAP and single sign-on for its Starter plan, wey free and self-managed for up to 50 users. Its docs also talk say from version 9.0.0, LDAP, SAML and Custom OAuth require premium plan. Its plans page use that term for paid Commercial, Government and Defense tiers.