Self-hosted Slack alternative after the Free plan history limit

Self-hosted Slack alternative after the Free plan history limit: the short answer

If your small team is losing visible history on Slack Free and wants to keep it under its own control, self-hosted open-source chat can do that. Three candidates fit this situation: Mattermost Team Edition, Zulip's free self-hosted plan and Rocket.Chat Starter. Each keeps messages on a server you run, but each differs in user caps, feature gating and the effort of operating it, so the choice should follow from your facts rather than from a feature checklist. The 90-day visible history and the one-year deletion rule are plan settings, not properties of Slack itself. Slack's own help center describes the Free plan changes, and the export rules also depend on plan: every plan can export public channels, while private channels and direct messages need Business+ or Enterprise. That means a small team on Free may not be able to take its full history out of Slack without an upgrade, which is the first thing to check before choosing a destination.

Start with three questions. First, how many people need accounts, since Mattermost Team Edition is aimed at teams under 250 users and Rocket.Chat Starter allows up to 50 users. Second, whether you need single sign-on or directory sync now, because Mattermost places SSO and AD/LDAP sync in its paid Professional plan, Rocket.Chat includes LDAP, AD and SSO on Starter, and Zulip's self-hosted server includes SAML and LDAP without a paid plan. Third, whether you want to pay a subscription or run a server; either way, budget for upgrades and backups. Before you commit, export a sample of your Slack history, confirm which plan you are on, and ask each vendor to confirm the current limits for your user count. Those three checks will narrow the field quickly and show what you will need to migrate before the one-year deletion window closes for older content.

What a history-retention constraint requires from a replacement

Slack's Free plan limits how far back visible history reaches and how long content survives, so a replacement has to keep history on infrastructure you control. The cards below set out the requirements that follow from that limit and the supplied facts that bear on each one.

Retain history beyond 90 days

Slack Free shows 90 days of message and file history, so anything older is out of view for members. A self-hosted server keeps what you store, but the retention window is a setting you must confirm, not a default you can assume. Check whether each candidate applies message retention to all channels and direct messages, and whether it deletes content automatically or only when an admin acts. Ask the vendor how retention interacts with file storage, since files often take more space than text.

Keep content beyond one year

Slack states that content on Free workspaces older than one year is permanently deleted. A replacement should be set to keep records for the period your policies require, and that period should be written down before migration begins. Confirm that backups follow the same retention rules, so a deleted message is not preserved in an unmanaged copy. Treat a retention decision as a records decision, and involve legal or compliance staff early.

Export every conversation you own

Slack's export rules depend on plan: every plan exports public channels, but private channels and direct messages require Business+ or Enterprise. Before choosing a replacement, decide which conversations your organization must be able to extract, and whether a departing employee's DMs count. Ask each vendor whether its import path carries private channels and DMs, not only public channels. Test a full export and re-import on a sample workspace before relying on it.

Plan around user caps

Caps change which replacement fits a small team. Mattermost Team Edition is aimed at teams under 250 users without single sign-on, and Rocket.Chat's free Starter plan allows up to 50 users. Zulip's free self-hosted plan includes all features, but mobile push notifications are limited to 10 users for most organizations. Count active users, not just licensed seats, and confirm whether guests or bots count toward the limit.

Add single sign-on and LDAP early

A team that grows past a handful of people usually needs one identity source for logins and offboarding. Mattermost places SSO and AD/LDAP sync in paid Professional plans, while Rocket.Chat's Starter plan includes LDAP, Active Directory and single sign-on. Zulip documents SAML, LDAP and SCIM on its self-hosted server without a paid plan. Confirm which identity features are in the edition you choose, and test that disabling an account in your directory removes access in chat.

Budget for the server you run

Keeping history longer means storing more data and running backups, upgrades and security patches yourself. Rocket.Chat's support windows of six months for standard releases and twelve months for LTS releases make upgrades a recurring task. Mattermost publishes a server version monthly and separate extended support releases, so plan a patch cadence and a test environment. Ask any implementation partner for the upgrade and backup responsibilities in writing before you sign.

Which self-hosted option fits a small team after the Free limit

This table compares Mattermost Team Edition, Zulip's free self-hosted plan and Rocket.Chat Starter on license, user limits, history behavior, SSO and LDAP, and upgrade paths. Read each row as a fit check against your team size, identity setup and retention needs, and confirm any retention detail with the vendor before you commit.

Criterion	Mattermost Team Edition	Zulip (self-hosted, free)	Rocket.Chat Starter
License	MIT for compiled binaries, per Mattermost's license documentation	Apache License 2.0	MIT outside enterprise directories, with a separate enterprise license for ee code
Intended user size	Teams under 250 users that do not need SSO	No stated cap in the supplied facts; confirm with Zulip for your size	Up to 50 users on the free Starter plan
SSO and LDAP	SSO and AD/LDAP sync sit in paid Professional and higher editions, so a team needing SSO falls outside Team Edition	SAML, LDAP and SCIM are available without a paid plan on self-hosted servers	LDAP, Active Directory and single sign-on are included in Starter
Message history and retention	Entry's 10,000-message channel cap applies only to the commercial build, not Team Edition; confirm Team Edition retention settings in your version	Confirm retention and export behavior for your self-hosted configuration	Retention is listed as a Starter capability; confirm the settings and default periods in the admin console
Compliance and audit features	Compliance export is a paid edition feature	Data exports are listed on the paid Business plan for Zulip Cloud-style support; confirm what the free server exposes	Tamper-evident audit trails are listed on paid plans, not Starter
Mobile push notifications	Confirm push delivery path for your mobile clients	Free plan limits mobile push notifications to 10 users for most organizations	Confirm push gateway behavior on your deployment
Slack import path	Documented migration with mmetl and mmctl; integrations and user groups do not move	Zulip's help center documents a Slack importer	Full Slack workspace exports can be imported through the built-in importer
Upgrade path	New server versions ship monthly, and an ESR line exists for longer support windows	Zulip Server 12.3 was the latest release supplied; plan regular upgrades	Standard releases get 6 months of support and LTS releases 12 months; plan upgrades on that cycle
Database and operations	PostgreSQL with a single Linux binary	Ubuntu or Debian install, or Docker	MongoDB 8.0 or later as a replica set, which adds operational work

What you gain and lose when Slack history stops being the limit

A self-hosted server keeps messages for as long as your own retention settings allow, and nothing is deleted on a vendor's schedule. That gain is real only if you accept the duties Slack carried for you: backups, upgrades, access control and recovery. Slack Free deletes content older than one year on its own timetable, so a self-hosted deployment replaces that deletion with a choice you must document. Decide the retention period per channel type before cutover, write it into your policy, and confirm which settings each candidate platform exposes for it. Mattermost, Rocket.Chat and Zulip each handle retention and export differently, so check them against your own compliance requirements rather than assuming parity.

The history you can migrate depends on the Slack plan you export from, and this is the step most teams underestimate. On Free, Slack's export covers public channel content only, so private channels and direct messages may not come across at all. Exporting private channels and DMs requires Business+ or Enterprise, which means a plan change or an approved request before you start. Ask your Slack administrator which export type is available to you and inventory the private channels and DMs your team relies on. Mattermost, Rocket.Chat and Zulip each document Slack import paths, but none of them can import what the export does not contain. Plan for that gap explicitly, and tell the business owners of those conversations what will and will not move.

Choosing between Mattermost, Zulip and Rocket.Chat Starter by team situation

A small team that does not need single sign-on is the case Mattermost Team Edition is built for. The MIT-licensed binary is free, self-hosted and aimed at teams under 250 users, so the license cost is zero and the work shifts to running the server. This keeps the choice focused on chat features and admin effort rather than on a paid seat count.

User ceiling: Team Edition targets teams under 250 users. Above that, confirm with Mattermost whether the free edition still fits your use.
Message history: Team Edition is not subject to the 10,000-message cap that applies to the Entry tier of the commercial build, so history stays under your own retention settings.
Missing paid features: SSO, AD/LDAP sync, clustering and compliance export are not part of Team Edition. If any of them become requirements later, Professional or a higher plan would be the path.
Migration: Slack exports move through mmetl and mmctl, but integrations, custom emoji images and user groups must be rebuilt by hand.
Operations: You own PostgreSQL, backups and upgrades. Mattermost publishes server versions monthly, so plan a regular upgrade window.

Confirm the user count, the need for SSO and the retention rules in writing before you choose this path.

Deploying the chosen server and moving history off Slack

This sequence turns the edition choice into a tested server with imported history, verified mappings, retention and backups in place, and a controlled cutover from Slack.

Confirm users, SSO and edition fit
The team lead and the identity owner confirm the active user count, whether single sign-on or directory sync is required, and whether retention or compliance export is needed. Compare those answers with the edition limits: Mattermost Team Edition is aimed at teams under 250 users without single sign-on, Mattermost places SSO and AD/LDAP sync in its Professional plan, and Rocket.Chat Starter allows up to 50 users with LDAP, SSO and retention. The output is a written edition decision and a list of required identity integrations, signed off before any build work starts.
Export the Slack workspace at the held plan level
A Slack workspace owner exports the data the current plan allows. On Free, the export covers only what the plan permits, and public channel content is the only category every plan can export. If private channels and direct messages must move, the workspace needs a Business+ or Enterprise export, which requires an approved application. Store the export archive in a restricted location, then record which channel types, date ranges and file contents it contains. Done means the team has an inventory matching the scope agreed in step one.
Provision the server and database
The platform or infrastructure team builds the production-grade host in the organization's own environment. Mattermost runs as a single Linux binary backed by PostgreSQL. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Confirm the database versions, backup tooling and TLS certificates with the vendor documentation before installation. Done means the application starts, connects to the database, and passes a basic login test on a non-production hostname.
Run the import into a test instance
Load the export into a separate test server first, never into production. For Mattermost, the documented path converts the Slack export with mmetl and loads it with mmctl. For Rocket.Chat, use Manage, Workspace, Import, and split large exports into files under 15 MB as its documentation recommends. Keep the import log and any failed records. Done means the test instance holds the users, channels, direct messages or threads and attachments that the scope in step two promised, with the expected gaps recorded.
Verify user and channel mapping
Two or three pilot users and one admin check the imported data against the Slack workspace. They confirm account matching by email, channel names and membership, thread structure, attachment access and direct message visibility. Record each mismatch and fix the mapping or import file, then rerun the test. Integrations, custom emoji images, user groups and Slack Connect channels do not transfer in the Mattermost path, and Rocket.Chat requires a separate CSV path for some sources, so list those gaps with the owners who will rebuild them. Done means a signed checklist shows every mapping check passed or has an accepted exception.
Set retention, backups and restore tests
The platform team sets message and file retention to match the policy the business agreed, and configures scheduled database and file storage backups. For Mattermost high availability, file storage must be shared on Amazon S3, an S3-compatible service or NAS on each node, because local storage will not work correctly. Run one restore of the backup into a separate environment and confirm that messages and attachments return. Done means a dated restore record exists and retention settings match the written policy.
Cut over and plan the upgrade cadence
Announce a cutover window, freeze Slack posting for the agreed channels, run a final import of the delta, then point users to the new address and retire the Slack export link. Mattermost publishes server releases in binary form on the 16th of each month, and Mattermost v11.7 is an Extended Support Release supported until 2027-05-15. Rocket.Chat standard releases are supported for six months and LTS releases for twelve months, and unsupported versions can lose mobile and desktop client connectivity. Confirm the chosen release line, its end-of-support date and the upgrade owner with the vendor before go-live. Done means the cutover is logged and the upgrade calendar is assigned.

Questions teams ask before running their own chat server

How much does running a self-hosted chat server cost compared with Slack Pro?

No open-source option has a fixed cost, so the honest comparison is components, not a single number. Slack Pro is a recurring per-user subscription. Self-hosting replaces that with server and storage costs, backups, admin time and, if you buy one, a vendor subscription. Zulip publishes per-user prices for its self-hosted plans: the Basic plan costs $3.50 per user per month billed monthly, and the Business plan costs $6.67 per user per month billed annually or $8 billed monthly with a 25-user minimum (Zulip plans page). Mattermost does not publish prices for its paid plans, and Rocket.Chat prices its Commercial, Government and Defense plans by quote. Compare your Slack Pro invoice with these figures and with your own hosting and labor estimates.

What drives the total cost of self-hosted team chat?

Five components drive the total. Infrastructure is the server, database and file storage, and it grows with user count and retained history. Licensing depends on the edition, since paid tiers add SSO, clustering or compliance export. Administration covers upgrades, backups, monitoring and user changes. Migration covers export handling, mapping and rebuilding integrations. Support covers any vendor subscription and whoever answers when something breaks. Mattermost high availability needs redundant application servers, database servers and load balancers, plus shared file storage such as S3 or NAS, so clustered designs cost more than a single node. Rocket.Chat's multi-instance designs also require a paid plan.

How much admin time does a self-hosted chat server need, and who does it?

Plan for recurring upgrades, backups, monitoring and user administration, and assign a named owner before cutover. Upgrade cadence differs by product. Mattermost releases a new server version in binary form on the 16th of each month, and its ESR line gives longer support. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and an unsupported version loses fixes and may stop connecting to official mobile and desktop clients. Zulip publishes server releases on GitHub. Confirm the exact upgrade procedure, backup tooling and on-call expectations with your chosen vendor or implementation partner before you commit to a staffing model.

Can a small team run its own chat server without outside help?

A small team with one person who is comfortable with Linux, Docker or Kubernetes, PostgreSQL or MongoDB, and a staged upgrade routine can often run a single-node deployment. The harder parts are reliability and migration. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Mattermost's high availability needs shared file storage on each node, since local storage risks corrupting files. If your team has no one to cover upgrades during an absence, the single-person risk is the real cost, and it should be weighed before choosing a product.

How long does a migration from Slack take, and what drives the duration?

The duration depends on workspace size, how much history you migrate, how many integrations you rebuild and how long both systems run in parallel. No supplied source gives a general timeline, so ask the vendor or partner for the steps in your environment. Mattermost migrates a Slack export through mmetl and mmctl, and integrations, custom emoji images, user groups and Slack Connect channels do not move. Rocket.Chat imports full Slack exports, and it recommends splitting large exports into files under 15 MB. Your export plan also matters: private channels and direct messages need Business+ or Enterprise.

Should we hire a partner to run the migration and the server?

A partner makes sense when your team lacks capacity or the required skills, or when you need the migration done before a Slack deadline. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. Keep the decision tied to your gaps, not to the tool choice.

What should we ask a partner for in a fixed-scope quote?

Ask for the scope written as deliverables, so that the quote can be compared with other offers. Request a list of the components covered, including the server, database, file storage, backups, monitoring, SSO and any Slack export and import work. Ask which integrations are in scope and how they will be rebuilt, what acceptance tests will prove the migration worked, and what happens to users who are not migrated. Confirm the upgrade and support model after go-live, any retainer terms, and who owns the documentation and credentials at handover. DeployOpen does not publish a price list, and a quote follows from the written scope.

Evidence that the retention change is working

Retention changes are only defensible if you can show the settings in force, the data you moved, and the systems you can restore. The six records below connect the chat server, the migrated history and the access model, so a reviewer can trace each claim to a file, a log or a test result. Ask your independent auditor which of them they expect before work starts.

Retention settings in effect

Record the message and file retention values configured on the server, and who approved them. Export the configuration at each change and keep it under version control with the change ticket. Check that the value you documented matches what the admin console shows, since a policy on paper that differs from the running server is a common gap. Confirm with the vendor which retention controls your chosen edition includes before you rely on them.

Backup and restore test records

Keep dated records of restores into a separate environment, showing which database and file store were restored and whether messages and attachments opened correctly. A backup you have never restored is not evidence. For Mattermost clusters, file storage must be shared (S3, S3-compatible or NAS), so include those buckets or mounts in the test. Record who ran the restore and how long it took.

Slack export files and import logs

Keep the Slack export archive you imported, the import log from the destination, and a reconciliation that compares channel, user and message counts between the two. Note what did not move, such as integrations, user groups or Slack Connect channels, and record that decision. Store the export securely, because it contains personal data from the period before cutover.

Access control and SSO configuration

Document how users sign in, which identity provider issues tokens, and which accounts hold administrator roles. Export the SAML or OIDC settings and the list of admins, and review them on a fixed schedule. Note which features need a paid edition, since SSO and directory sync are not included in every free tier. Remove accounts from the Slack export that should not carry over.

Upgrade record for the chosen version

Log each server version you run, the date it was installed, the release notes you reviewed and the support end date. Mattermost publishes monthly server releases and separate extended support releases, so state which line you follow. Record the test environment result before each production upgrade. A version past its support window is a finding in most reviews.

What running a team chat server costs compared with Slack Pro

The software licence is the smallest line item for a team that moves to an open-source server. Mattermost Team Edition is free and self-hosted, and Zulip's self-hosted Community plan includes all features, so the licence cost is zero for both until you need a paid tier. Zulip's self-hosted Basic plan costs $3.50 per user per month billed monthly, and its Business plan costs $6.67 per user per month billed annually or $8 billed monthly with a 25-user minimum, per the Zulip plans page. Rocket.Chat's Starter workspace is free for evaluation and small teams, but its paid Commercial, Government and Defense plans are priced by quote. Compare these figures with the Slack Pro price on Slack's own pricing page, and check the current figures before you decide, because plan prices change.

Hosting, database operations, backups, upgrades and admin time carry the recurring cost. Mattermost runs on PostgreSQL, and Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, with three members strongly recommended for high availability, so you pay for database servers, storage and the staff who patch them. Mattermost high availability requires shared file storage on Amazon S3, an S3-compatible service or NAS, and it is available only on its Enterprise and Enterprise Advanced plans. Rocket.Chat's support windows matter here: standard releases are supported for 6 months and LTS releases for 12 months, so upgrades recur on a schedule. Mattermost ships new server versions in binary form on the 16th of each month, and its Extended Support Release v11.7 is supported until 2027-05-15. Budget admin time for each of these cycles, not only for the first install.

Separate the one-time migration work from recurring operation before you ask for a quote. Migration covers the Slack export, the plan you need to export private channels and DMs, re-creating integrations, and testing. Ask any provider to price the following in writing: the hosting and storage assumptions, the database and backup design, the upgrade and patching cadence, the number of seats and whether paid features such as SSO, clustering or compliance export are in scope, support hours, and who performs each recurring task. Confirm with the vendor which edition covers your needs, because a free edition can leave a feature gap that a paid plan closes.

How DeployOpen deploys team chat under a retention requirement

This sequence takes a team from a Slack Free history limit to a self-hosted chat server inside the client's own infrastructure, with retention, identity and recovery checked before users move.

Agree the scope and retention rules in writing
DeployOpen and the client agree a fixed scope in writing before work starts. The document names the chosen platform (Mattermost Team Edition, Zulip or Rocket.Chat Starter), the hosting location, the number of users, which Slack channels and direct messages must survive, and the retention period the organization needs. Your compliance lead should confirm whether that period is set by policy or by an external obligation. The signed scope is the output of this step, and it decides which edition and plan are viable.
Confirm the edition fits the user and feature caps
Before any build, the team checks the chosen platform against the requirements in the scope. For example, Mattermost Team Edition is aimed at teams under 250 users without single sign-on, while Rocket.Chat Starter caps users at 50 and Zulip's free self-hosted plan limits mobile push notifications to 10 users for most organizations. Anything the requirements need that falls outside a free tier is flagged here, with the paid plan or license that covers it, so the client can approve cost before deployment. The output is a written fit decision.
Deploy inside the client's own infrastructure
DeployOpen builds the server in the client's cloud account, data center or air-gapped network, with PostgreSQL or MongoDB storage as the chosen platform requires. The team sets up backups, storage locations for uploaded files, TLS, and network access rules, and records the configuration in documentation the client keeps. Retention settings are configured at this stage so messages and files are kept beyond the Slack Free window. The output is a running staging environment and a configuration record.
Integrate the chosen identity provider
The server is connected to the organization's identity provider through SAML, OIDC, LDAP or Active Directory, depending on the platform and the plan. Account lifecycle rules are tested, including what happens when a person leaves, so accounts and their message history are handled according to policy. Multi-factor authentication settings are confirmed against the client's own requirements. The output is a test report showing login, group mapping and deprovisioning results for a set of test accounts.
Test the migration on a copy of the export
The Slack export is loaded into the staging server using the platform's documented import path, such as mmetl and mmctl for Mattermost, the built-in importer for Rocket.Chat, or Zulip's Slack importer. DeployOpen compares channels, threads, direct messages, attachments and user counts against the source export and logs anything that did not move, such as integrations, user groups, custom emoji images or Slack Connect channels. Missing items are assigned to a rebuild list. The output is a reconciliation report signed off by the client's workspace owner.
Document backup, restore and upgrade procedures
DeployOpen writes runbooks for backups of the database and file storage, a tested restore into the staging environment, and the upgrade path for the chosen release line. The runbook records each platform's support window, such as Mattermost's monthly release cadence and extended support releases, or Rocket.Chat's six-month standard and twelve-month LTS support, so the client's operators know when an upgrade is required. The output is a restore test record and an upgrade calendar that the client's operators own.
Cut over and hand over with optional retainers
After the client approves the reconciliation and restore tests, users are moved to the production server, and Slack access is kept during a period agreed in the scope. Operators receive training and the documentation package. The client may then choose a retainer for ongoing support, upgrades and continuous testing, which is priced separately from the fixed-scope build. The output is a production server, a signed handover and a written record of who owns each operational task.

Self-hosted Slack alternative after the Free plan history limit