Rocket.Chat Review 2026: Free Plans, Seats & Hosting

The current plans guide makes the lifecycle change explicit: Pro moved to legacy status on April 29, 2026 and is unavailable for new purchases. Do not calculate a new deployment from an older $8 Pro article. Existing subscribers must check their own legacy terms.

The purchasable paid families are Commercial, Government, and Defense, all requiring custom pricing. Their deployment and governance scope differs, and the documentation identifies additional services such as AI, VoIP, professional services, and support add-ons. Request the exact configuration rather than treating every listed premium capability as an included entitlement.

Starter and Community remain distinct $0-license options. The paid quote should identify seats, hosting responsibility, implementation, support, renewal terms, and optional services before comparison. If the main requirement is ordinary hosted team messaging rather than deployment control, include Pumble in the shortlist.

The free-edition comparison gives Starter up to fifty users and Community up to 100 concurrent users. Starter limits the roster through its seat definition; Community limits how many users can be connected simultaneously. These units cannot be exchanged. A team cannot justify seventy Starter seats by saying that only thirty people normally open the app at the same time.

Community is the MIT open-source edition with basic messaging, limited integrations, and 10,000 push notifications per month. That notification limit is not a 10,000-message storage limit. Starter instead lists unlimited push notifications and a broader feature set, including more meeting-provider options. Neither free edition supports the paid air-gapped deployment capability. Open-source availability does not mean every identity, governance, integration, or support feature is identical across editions.

The vendor specifically cautions against Community for organizations relying on it for business-critical operations, compliance, or reliability. Starter also uses community and self-service support, with no paid support add-on, and its entry page specifies one workspace per organization. Assess the hosting and DevOps requirements before interpreting a larger concurrent-user allowance as a free production upgrade.

The Seats FAQ defines a seat as a user with Active or Pending status, whether or not that person has logged in. Guests, deactivated users, and app users are excluded. Login activity and online presence are therefore the wrong measures for Starter planning. Check account states and legitimate guest access needs before a bulk invitation, rather than discovering the boundary during employee onboarding.

For example, forty-two Active users plus eight Pending users already occupy fifty seats, even if only twenty people have ever signed in. The plans guide says reaching Starter's limit prevents adding new users while existing users and data remain accessible. A paid upgrade is documented as not requiring a data migration. Plan growth before the next required invitation.

Fifty eligible Starter seats cost $0 in license fees, not $0 to operate. Budget compute, database and attachment storage, backups, monitoring, domain and email services, and staff time; add meeting-provider or commercial services where required. The Pumble versus Slack comparison provides a separate hosted-billing lens.

The room-options guide documents threads, discussions, mentions, files, pins, and message search. Search can use authors, dates, links, and other filters. Global search, when enabled by an administrator, searches rooms the user belongs to; it should not be described as universal access to every conversation. Available room actions also vary by room type and permission, so the same menu need not appear for every participant.

These capabilities can support asynchronous work, but Rocket.Chat does not impose an asynchronous communication culture. Decide which updates deserve a thread, where decisions are summarized, and what warrants a mention. Teams comparing Slack should evaluate notification conventions as well as feature presence. Room preferences distinguish desktop, mobile, email, and group mentions; configure a realistic mobile and desktop journey rather than treating a notification allowance as proof of successful delivery.

Meetings require attention to the selected integration. Starter lists Pexip, Jitsi, BigBlueButton, Google Meet, and Zoom; Community lists Jitsi and BigBlueButton. The room guide describes configuring supported providers, not unlimited free hosting for those services. For a meeting-led organization, compare the complete workflow with Microsoft Teams, including identity, guest access, recordings, and the provider's own terms.

The permissions matrix assigns capabilities to roles. Administration, invitations, integration management, personal access tokens, auditing, and history pruning are distinct permissions. One particularly useful distinction is that viewing room-administration statistics does not itself include viewing conversations or archives. Buying or operating a server should not be represented as automatically authorizing every operator to inspect every employee's private communication.

Starter documents LDAP/Active Directory, single sign-on, MFA, and role-based controls, but Community's basic identity offering is different. Confirm the selected edition's entitlement before promising an enterprise integration. End-to-end encryption is also a configured capability, not evidence that every room, attachment, export, notification, backup, or connected service receives identical protection. The appropriate question is which data each component receives and under whose authorization it operates.

For an evaluation, separate a workspace administrator, a room owner, an ordinary member, and a guest. Review incoming and outgoing integrations, invitation rights, and access after deactivation. External email, meeting, push, or AI services can introduce additional processing and cost; self-hosting the chat server alone does not demonstrate that all information stays inside one infrastructure boundary or satisfies a particular law.

The room export documentation distinguishes several routes. Selected messages can be sent as HTML email; an emailed downloadable archive can use HTML or JSON and a date range; direct download saves selected messages as JSON. Availability depends on permissions and settings. These are useful retrieval mechanisms, but a route offering an export does not grant access to unrelated private rooms or authorize sending their contents to outside addresses.

The separate User Data Download guide requires the feature to be enabled. Requests enter a queue, produce a ZIP, and generate an email download link. Its Message Limit per Request setting actually limits messages included from each room the user belongs to. An archive created successfully can therefore still be incomplete for a migration, and export processing also requires writable storage and server resources.

Check attachment recovery, encrypted-room handling, date coverage, and import compatibility using an authorized sample before committing to an exit. Follow the separate encrypted-room instructions. A message archive is not a backup of the application's configuration and infrastructure. The Slack alternatives guide is a useful shortlist aid, but each destination's actual migration path still needs validation.

The retention guide says messages are not deleted by default, then describes optional global and per-room policies. That is a default behavior statement, not a promise of infinite storage or protection from deliberate deletion. Global rules distinguish channels, private groups, and direct messages. Omnichannel conversations use separate controls, so this retention page should not be applied indiscriminately to every communication feature.

Where the capability is available, global configuration requires edit-privileged-setting and room configuration requires edit-room-retention-policy, assigned to administrators by default. Policies can override global settings or preserve selected pinned, discussion, or thread content. File-only pruning can leave a message while removing its attachment. The room documentation warns that pruned messages and files are permanently deleted; this is materially different from a hosted product merely hiding older history behind an upgrade.

Determine retention policy and recovery policy together, but do not confuse them. A backup process must cover the required database, files, and configuration, with protected access and an independently evaluated restore path. Use the hosting category to assess operating responsibility and Pumble versus Slack to compare visibility, retention, and exports as separate concepts. Exports cannot recreate data already pruned.

Rocket.Chat deserves consideration when controlled deployment is worth assigning real engineering and administrative ownership. Starter offers a useful small-team evaluation path, but the fifty-seat boundary must be checked against account status. Community supplies a different basic open-source option, not a free equivalent of the current paid plans. For production-critical requirements, obtain the scoped Commercial, Government, or Defense terms and assess them against the intended operating environment.

Compare Mattermost when self-management remains essential, or Slack when the team would rather evaluate a hosted communication service. The deciding factor is not simply which license can be obtained at zero cost. It is whether the complete arrangement meets the organization's access, conversation, integration, support, and recovery needs without leaving those responsibilities unowned.

A sensible next step is a bounded, authorized evaluation with representative identities, a documented user-count forecast, a supported meeting route, and an export-and-recovery checklist. Record who will maintain each dependency and what happens at the next capacity boundary.