When is the free Rocket.Chat plan enough, and when do you need a paid plan?
The free Community and Starter plans suit many internal deployments, and a paid plan becomes necessary once you need high availability, tamper-evident audit logs or air-gapped deployment. Start by writing down which of those three requirements are mandatory for your workspace, not merely desirable. If none of them are, the free plans are usually the better fit, because you avoid a quote cycle and keep the option to upgrade later. Per Rocket.Chat's plans documentation, upgrading to a premium plan does not require a data migration, so a free start does not lock you in. Choose Community when you run a small, self-managed workspace with core messaging, up to 100 concurrent users, and you can accept basic identity management and 10,000 push notifications per month. Choose Starter when you need LDAP or Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts, with up to 50 users added and unlimited push notifications. Confirm the current user counting rules with Rocket.Chat before you commit, because Starter caps users added while Community caps concurrent connections. Also confirm that your intended clients, including the official mobile and desktop apps, will connect on the version you deploy.
Move to a paid plan when the risk profile changes. Commercial is the entry point for the multi-instance microservices architecture used for high availability and disaster recovery, and for tamper-evident audit trails covering messages, files and sessions. Government and Defense add the air-gapped deployment option, which is not available on Starter or Community. Because Rocket.Chat publishes no prices for these plans, ask for a written quote that lists the plan, user count, architecture, support tier and any professional services, and ask what recurs annually and what is one-time. Plan for the operating cost too: Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, and support is not included on free plans, so budget for your own on-call and upgrade cadence.
Which Rocket.Chat features sit in Community, Starter and paid plans?
This table sets out the documented split between the free Community workspace, the free Starter plan and the paid Commercial, Government and Defense plans. Read the first two columns for what you can run at no cost, and the last column for what makes a paid agreement necessary. Where a cell says to confirm, the public plan documentation does not settle the point, so get the answer from Rocket.Chat in writing before you commit.
| Capability | Community | Starter | Commercial, Government and Defense |
|---|---|---|---|
| User limit | Up to 100 concurrent users | Up to 50 users added, then new users are blocked | Set by the plan agreement, confirm the limits in writing |
| Authentication (LDAP, AD, SSO, MFA) | Basic identity management only | LDAP, Active Directory, single sign-on and multi-factor authentication | LDAP and SAML group mapping, SSO, Active Directory and MFA |
| Push notifications | 10,000 per month | Unlimited | Confirm the allowance in the plan terms |
| Video calls | Jitsi or BigBlueButton | Pexip, Jitsi, BigBlueButton, Google Meet or Zoom | Confirm the supported call integrations for your plan |
| End-to-end encryption and retention | Confirm in the plan documentation | Included | Confirm how each paid plan handles both |
| Audit trails | Not listed in the plan split | Not listed in the plan split | Tamper-evident audit trails of messages, files and sessions, listed for paid plans |
| Multi-instance architecture and failover | Single instance only | Single instance only | Commercial adds a multi-instance microservices design for high availability and disaster recovery |
| Air-gapped deployment | Not available | Not available | Available only on paid plans, confirm which plan and terms apply |
How licensing, support and updates differ by edition
Rocket.Chat splits its code across an MIT-licensed core and a separately licensed enterprise directory, and its support and upgrade obligations change with the plan. The cards below cover what each layer means for a free workspace, a Starter workspace and a paid deployment, and what to confirm before you commit to an upgrade path.
MIT-licensed core
The core of Rocket.Chat is MIT licensed, so the code outside the enterprise directories can be used, modified and redistributed under permissive terms. This is the foundation of the free Community workspace. Check which features you depend on live in the enterprise directories, because the license of a feature follows the directory it sits in, not the plan name on the pricing page. Ask your legal team to read the LICENSE file against the features in your design.
Separate enterprise license
Code in the apps/meteor/ee and ee directories sits under a separate Rocket.Chat enterprise license rather than the MIT terms. Any feature built from that code carries those restrictions, even when you run the same version of the core. Before you plan a self-managed deployment, list each capability you need and confirm with Rocket.Chat which directory it comes from and what the enterprise license permits for your use.
No paid support on free plans
Community and Starter include no paid support. Your only path to a vendor response on those plans is the public community, so an outage or security question on a free workspace has no contracted response time. Teams with an uptime target or regulated change control should treat this as a fixed gap and either staff the run book in-house or move to a premium plan. Ask whether any support tier applies to your specific plan before you rely on it.
Premium support and professional services
Premium plans include Standard support, and Mission Critical support and professional services are sold as add-ons on top. Each add-on is a separate purchase, so the quote should name the support tier, response commitments and any services hours in the written scope. Ask what is included in professional services, who delivers it, and whether it covers upgrades, migrations or incident response, because those duties vary by contract.
Six-month standard and twelve-month LTS windows
Standard releases receive support for 6 months and LTS releases for 12 months. After end of life, a version gets no security or bug fixes, and cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Plan an upgrade cadence that stays inside a supported line, and schedule time for testing each move, since the window is the constraint, not the release date.
Starter by default and Pro as legacy
Every workspace deployed on Rocket.Chat 6.5 or later is provisioned as a Starter workspace, so a new install starts on Starter unless you choose otherwise. The Pro plan is legacy and no longer accepts new purchases. If you have an older Pro contract or are migrating from an earlier deployment, confirm which plan your workspace is registered under, since it determines which support and features you can claim.
What happens when a Starter workspace hits its user limit
At the Starter limit of 50 users, Rocket.Chat stops new users from being added, but existing users, their conversations and stored data stay accessible. The workspace is not locked or emptied when the cap is reached, so the risk is operational: a growing team cannot onboard the next person until the workspace moves to a paid plan. Before the count gets close, have your administrators confirm in writing with Rocket.Chat how the limit counts deactivated accounts, bots and guests. The free Community workspace uses a different measure, concurrent connections, so it is not a practical fallback for a team that is still growing.
Moving to a premium plan does not require a data migration, which keeps the decision about capacity and architecture rather than export and re-import. Rocket.Chat's reference architectures suggest one instance backed by a MongoDB replica set for up to 500 concurrent users, multiple load-balanced instances linked by NATS above 500, and microservices on Kubernetes with the official Helm chart above 5,000. The multi-instance and microservice designs require a paid plan, so a team that expects to pass 500 concurrent users should check the reference architectures and the plans documentation before the user count forces the choice.
Plan the upgrade as an infrastructure change, not a license click. Confirm which plan includes the architecture you need, since Commercial is the plan that includes the multi-instance microservices design for high availability and disaster recovery. Measure peak concurrent connections, not just total users, and check that the MongoDB deployment meets the Rocket.Chat 8.x requirement of MongoDB 8.0 or later as a replica set, with three members recommended for high availability. Ask Rocket.Chat for a written quote that states what the plan includes, how support and professional services are priced, and what changes in your hosting and operating effort once the workspace scales.
Which edition fits which team situation?
A small team that runs its own chat on one server and does not need directory integration can usually start on the free Community workspace. Community is free and MIT licensed for up to 100 concurrent users, is self-hosted only, and includes core messaging. Its limit is concurrent connections rather than a count of named accounts, so the team should think about peak online activity rather than headcount. Community offers basic identity management, 10,000 push notifications per month, and Jitsi or BigBlueButton calls for video.
- Cost profile: Software is free, but the team pays for the server, backups, and the staff time to upgrade it.
- Push limit: The 10,000 monthly push notifications cap can be reached quickly in busy groups with many mobile users.
- Support: Community includes no paid support, so problems are handled through public channels and internal skill.
- Upgrade discipline: Standard releases are supported for 6 months and LTS releases for 12 months, so the team must plan regular upgrades.
Confirm with Rocket.Chat the current concurrent-user limit wording, the push notification allowance, and whether any feature you need is restricted to Starter before you build on Community.
An organization that must sign staff in through its existing directory or identity provider usually needs the Starter plan. Starter is free for up to 50 users on a self-managed workspace and adds Active Directory and LDAP authentication, single sign-on, read receipts, unlimited push notifications, and video calls through Pexip, Jitsi, BigBlueButton, Google Meet, and Zoom. It also lists multi-factor authentication, end-to-end encryption, and retention among its included capabilities.
- Headcount ceiling: Starter stops new users from being added at its user limit, while existing users and data remain accessible.
- Upgrade path: Upgrading to a premium plan does not require data migration, which lowers the cost of outgrowing Starter.
- Provisioning: Every workspace on Rocket.Chat 6.5 or later starts as Starter, so most new installations begin here.
- Identity design: Confirm which LDAP or SSO option matches your directory, since SAML user group mapping is listed on the paid plans.
Before relying on Starter, confirm with Rocket.Chat the user cap that applies to your organization, how it counts users, and whether your identity provider configuration is covered on Starter.
A regulated or availability-sensitive deployment usually needs the Commercial plan. Commercial includes a multi-instance microservices architecture for high availability and disaster recovery, along with tamper-evident audit logs of messages, files, and sessions with message export. The paid plans also list built-in redundancy with automated failover and LDAP and SAML user group mapping. Rocket.Chat's reference architectures suggest a single instance with a MongoDB replica set up to 500 concurrent users, load-balanced instances linked by NATS above 500, and Kubernetes with the official Helm chart above 5,000, with multi-instance and microservice designs requiring a paid plan.
- Audit evidence: Tamper-evident audit trails help with logging requirements, but they do not by themselves make a deployment compliant.
- Operating burden: Multi-instance designs need MongoDB 8.0 or later as a replica set, with three members strongly recommended for high availability.
- Support tier: Standard support is included with premium plans, and Mission Critical support is an add-on.
- Quote basis: Commercial pricing is requested through a get-pricing form, so the cost depends on the scope you describe.
Confirm with Rocket.Chat the exact audit log retention and export format, the failover design it supports for your topology, and which support tier and professional services would be included in the quote.
Government and defense requirements, including air-gapped deployment, point to the Government or Defense plans. Air-gapped deployment is a paid-plan capability and is not available on Starter or Community. Government is priced by custom quote and Defense is handled through a contact form, so the buyer should expect a scoped conversation rather than a published price. Because no prices are published, any budget decision must rest on the written quote.
- Isolation: An air-gapped network cannot reach the cloud services that Starter and Community rely on for some features, so confirm which capabilities work offline.
- Upgrade access: Patches and new releases must reach an isolated network by a route your security team approves, which adds process overhead.
- Version lifecycle: Versions past end of life get no security fixes and some cloud services stop working, so confirm the support window for your chosen line.
- Contract scope: Ask whether the Government or Defense plan includes the same paid features as Commercial.
Confirm with Rocket.Chat exactly which features operate without internet connectivity, how updates are delivered into an isolated environment, and the support and continuity terms in the written quote before you commit to a design.
What does each Rocket.Chat plan cost to run?
This table separates the license, infrastructure, support and staff costs for Community, Starter and the paid Commercial, Government and Defense plans. Read it as a list of who gets paid for what, and which lines recur. Rocket.Chat publishes no paid plan prices, so the paid rows describe what to request in writing.
| Cost component | Community and Starter (free) | Commercial, Government and Defense (paid) |
|---|---|---|
| License fee | Zero. Community is MIT licensed and Starter is free for up to 50 users on a self-managed workspace. | Quote-based. Commercial uses a get-pricing request, Government a custom quote and Defense a contact form. No prices are published. |
| Infrastructure | You pay for hosting and run a MongoDB 8.0 replica set, with three members strongly recommended for high availability. Node.js is bundled in the Docker image and Helm chart. | Same MongoDB replica set base, plus the multi-instance or microservices footprint that the paid architectures require for high availability and disaster recovery. |
| Support | None included on Starter or Community. You rely on your own team and public community resources. | Premium plans include Standard support, with Mission Critical support and professional services sold as add-ons. |
| Staff time for upgrades | Recurring. Standard releases are supported for 6 months and LTS releases for 12 months, so upgrades are a regular task. | Recurring, but the same release cycle applies. Ask how much upgrade and failover testing the quote assumes. |
| Staff time for paid features | Lower on Starter, where LDAP, SSO and MFA are included. Community needs more manual identity work. | Ask who configures SAML group mapping, audit trail export and automated failover, and whether that work is in scope. |
| What to request in a written quote | Not applicable. Confirm the Starter user limit and that your workload stays within it. | Named plan and tier, user count, deployment type, support level, air-gapped or not, and whether migration and upgrades are priced separately. |
How to move from Community or Starter to a paid plan
The sequence moves a workspace from a free plan to a paid tier with its users and data kept in place, and ends with the architecture that the required concurrency actually calls for.
Confirm the workspace version is supported
Check which Rocket.Chat version the workspace runs and whether that line still receives security and bug fixes. Standard releases are supported for 6 months and LTS releases for 12 months, and an end-of-life version loses cloud services such as the push notification gateway, Marketplace and Omnichannel integrations. The workspace administrator owns this check, and it is done when the version appears on the supported list in the version durability documentation. If it does not, upgrade the workspace before any plan change, because the paid tiers do not fix an unsupported line.
List the paid features your workspace needs
Write down which capabilities drive the decision: high availability and disaster recovery, tamper-evident audit logs with message export, air-gapped deployment, LDAP and SAML user group mapping, or built-in redundancy with automated failover. Starter already covers LDAP, SSO, MFA and read receipts, so list only the gaps. Confirm each item against the current plan documentation and the pricing page, since feature tables change. The output is a short requirements list that the vendor can quote against, and a note on which items are optional for the first phase.
Request a written quote for the plan
Commercial uses a get-pricing request, Government a custom quote and Defense a contact form, and Rocket.Chat publishes no prices for these plans. Send the requirements list, the expected user count, the number of instances and the hosting model, which is your own infrastructure or the vendor's cloud. Ask the quote to state the subscription term, what support tier is included, whether Standard or Mission Critical support and professional services are add-ons, and how renewals are priced. The step is done when you hold a quote that names every feature in the list.
Activate the paid plan on the existing workspace
After the subscription is signed, apply the license to the existing workspace in the administration console. Rocket.Chat states that upgrading to a premium plan does not require data migration, so channels, users, files and history stay where they are. Your administrator confirms the plan name shows in the workspace settings and that the paid features on your list are visible. Record the change in your change log together with the version, the date and the license holder, because this is the baseline for any later downgrade discussion.
Configure the newly enabled features and test them
Enable the paid features your team needs, such as SAML user group mapping, tamper-evident audit trails or redundancy settings, and test each one with a small group of accounts. For SSO and LDAP, sign in with users from each group and confirm that group membership maps to the right roles. For audit logs, export a test set of messages and confirm the export opens in your review tooling. The step is complete when each feature has a recorded test result and an owner who will run it after changes.
Check concurrency against the reference architecture
Measure peak concurrent users over a representative period and compare the figure with Rocket.Chat's reference architectures. A single instance with a MongoDB replica set is suggested up to 500 concurrent users, load-balanced instances linked by NATS above that point, and microservices on Kubernetes with the official Helm chart above 5,000. The multi-instance and microservice designs require a paid plan. Your platform team owns the measurement, and the output is a documented decision on which architecture the workspace needs now and which it will need later.
Deploy the multi-instance or microservice architecture
If concurrency or availability requirements call for it, build the multi-instance or microservice design on your infrastructure. Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, and a three-member replica set is strongly recommended for high availability. Node.js is bundled in the official Docker image and Helm chart. Test failover by stopping one node in a staging environment and confirming that users reconnect and messages persist. The step is done when the failover test passes and the runbook is stored with the architecture diagram.
Confirm downgrade terms in writing
Data and users stay accessible when a workspace reaches a plan limit. On Starter, when the user limit is reached, Rocket.Chat stops new users from being added while existing users and data remain available. Before you sign, ask the vendor in writing what happens to features, support and multi-instance deployments if the subscription ends or you move back to a lower plan, and whether any paid-only settings become read-only. Keep the answer with the contract. This is the step that protects the workspace if priorities or budgets change, and it is done when the terms are on file and reviewed by your legal or procurement team.
Why upgrade discipline matters on every plan
Upgrade discipline is a cost of running Rocket.Chat on any plan, including the free Community and Starter workspaces. A version past its end of life gets no security or bug fixes. Rocket.Chat also states that cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working after end of life, and unsupported versions may lose the ability to connect with the official mobile and desktop clients. For a self-managed workspace, the operator carries that risk, so a free plan does not make a version choice optional. Standard releases are supported for 6 months and LTS releases for 12 months, so the support window is the first number to check before you commit to a line.
Rocket.Chat 8.9.0 was published on GitHub on October 5, 2026, and patch releases such as 8.6.3 and 8.5.4 followed on October 16, 2026 for older supported lines. Those patch lines show that more than one branch can receive fixes at once, but the branch you run must still be on the supported list in the version durability documentation. Before you choose a plan, confirm which line your workspace runs, its end-of-life date, and whether your mobile and desktop client versions still connect to it. Decide who owns the upgrade calendar and who signs off on a move to a new standard or LTS release.
Upgrade effort also depends on the architecture you run. Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, so a database change is part of the same window as an application change. Ask your team to test upgrades in a staging copy with a restored backup, and to record how long a rollback would take. If you later move to a Commercial plan for multi-instance deployment, the upgrade procedure changes as well, so ask the vendor to document it in the quote before you sign.
Questions buyers ask before choosing a Rocket.Chat plan
What does Rocket.Chat Starter cost to run?
Starter has no license fee for up to 50 users on a self-managed workspace, according to Rocket.Chat's plans documentation. The cost you still carry is infrastructure, including servers or cloud accounts, a MongoDB replica set, backups, and the staff time to patch, monitor and upgrade the platform. Those costs recur every month and rise with user count, message volume and the number of environments you run. Before you commit, estimate the infrastructure and labor for your own environment, since Rocket.Chat does not publish figures for that.
How long does a Rocket.Chat paid plan quote take?
Rocket.Chat does not publish prices for Commercial, Government or Defense. Commercial uses a get-pricing request, Government a custom quote and Defense a contact form, according to its pricing page. No turnaround time is published in the sources we reviewed, so confirm the expected lead time directly with Rocket.Chat. Prepare your user count, deployment model, high availability needs, audit log requirements and whether you need air-gapped operation, because those inputs shape the quote.
Can a team run Rocket.Chat Starter without outside help?
Yes, a team with Linux, container and database experience can run Starter itself, since the official Docker image and Helm chart bundle Node.js. The harder part is the ongoing work. 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. Starter and Community include no paid support, so your team carries troubleshooting alone unless you buy a support tier or outside services.
What does running Rocket.Chat require from our team day to day?
Plan for three recurring areas: database operations, upgrades and identity integration. Rocket.Chat 8.x depends on a MongoDB replica set, so someone must own its backups and failover behavior. Standard releases are supported for 6 months and LTS releases for 12 months, and an unsupported version loses security fixes and may stop connecting to the official mobile and desktop clients. Starter includes LDAP and Active Directory authentication and single sign-on, so test those integrations against your directory after each upgrade.
Can we migrate chat history from Slack or Mattermost to Rocket.Chat?
Rocket.Chat supports migration from Slack. Its import tools accept full Slack workspace exports, Slack users from CSV, and a CSV importer for other sources. Mattermost data is migrated by converting its export into the CSV format, according to the import documentation. Test the conversion on a copy of your data first, check how users, channels and attachments map, and confirm the result with Rocket.Chat or the import documentation before you schedule a cutover.
When does a paid Rocket.Chat support tier become worth it?
A paid support tier becomes worth considering once chat is operationally critical and an outage or upgrade failure would stop work. Starter and Community include no paid support, while premium plans include Standard support, with Mission Critical support and professional services sold as add-ons. Weigh the support terms against your internal on-call capacity and your tolerance for downtime. Ask Rocket.Chat exactly which response commitments each tier includes before you decide.
When do we need Commercial, Government or Defense instead of Starter?
Move to a paid plan when you need a capability Starter does not provide. Commercial adds a multi-instance microservices architecture for high availability and disaster recovery, and tamper-evident audit logs with message export. Air-gapped deployment is not available on Starter or Community. Rocket.Chat's reference architectures place multi-instance and microservice designs on paid plans, and suggest a single instance with a MongoDB replica set up to 500 concurrent users. If your requirements fall within that range and do not need audit trails, Starter may remain sufficient.
What happens if our Starter workspace reaches its user limit?
Rocket.Chat stops new users from being added, while existing users and data stay accessible, according to its plans documentation. Upgrading to a premium plan does not require a data migration. Because growth can stall onboarding, track your user count against the 50-user Starter limit and plan the upgrade conversation before you reach it. Ask Rocket.Chat to confirm how the upgrade is activated in your deployment model.
How DeployOpen scopes a Rocket.Chat edition decision
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For Rocket.Chat, that means the edition decision is made against a written scope: which plan's features are needed, where the workspace will run, how identity is wired to LDAP, Active Directory or SAML, how the MongoDB replica set is built and backed up, and who performs the upgrades that keep the workspace inside a supported release line. Most engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
DeployOpen does not publish prices for Rocket.Chat or for its own services. A quote follows from the written scope, so the inputs that move cost are the ones to settle first: the number of users, whether high availability or tamper-evident audit logs are required, whether the deployment must run air-gapped, and whether ongoing support, upgrades or continuous testing will be retained after go-live. Rocket.Chat itself publishes no prices for its Commercial, Government or Defense plans, so ask Rocket.Chat for its licensing terms in parallel. Confirm with the vendor which plan covers each requirement before the scope is signed.
DeployOpen is not a Rocket.Chat partner, reseller or certified provider. Licensing for the paid plans comes from Rocket.Chat, and the decision on whether a Starter or paid edition is required stays with your team and that vendor. What DeployOpen can contribute is the implementation and operating work under the chosen edition, documented against your own controls. Ask any implementation provider, including DeployOpen, to state in the scope which licensing questions are out of its hands.
How DeployOpen delivers Rocket.Chat on either edition
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Rocket.Chat, that means working out which plan your user count, identity model and availability needs actually require before any build work begins.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- We record user counts, identity sources, push and call requirements, and whether high availability or audit logs are required.
- The written scope states which plan the design assumes, so Starter and paid-plan features are not confused in the build.
How we build
- We deploy Rocket.Chat on your own infrastructure, with MongoDB configured as a replica set per the current system requirements.
- We configure LDAP or Active Directory, single sign-on and multi-factor authentication where the chosen plan includes them.
- We test push notification, video call and import paths against the limits of the plan you selected before handover.
How we hand over
- Deliverables include architecture notes, configuration records, backup and restore procedures, and an upgrade runbook.
- Documentation states the plan limits in force, so administrators know when a user cap or feature gate applies.
- We confirm with your team which plan and licensing terms are in effect before the workspace is handed over.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades are planned around Rocket.Chat's support windows, since unsupported versions lose security fixes and client compatibility.
- If you later move from Starter to a paid plan, we plan that change with you, and you should confirm with Rocket.Chat that no data migration is needed.
