When self-managed or Rocket.Chat cloud fits your team
The first question is whether your Rocket.Chat workspace can be cloud hosted at all. Rocket.Chat's hosting FAQ limits cloud hosting to the premium Commercial, Government and Defense plans, while self-managed deployment is available on all workspaces. If you are on the free Community workspace or the Starter plan, self-managed is your only option, and the decision is about who runs the servers, not which vendor you buy from.
Choose Rocket.Chat cloud hosting when data location is handled by a contract you can enforce and when you would rather not staff database and upgrade operations. Rocket.Chat's cloud hosting SLA places Premium and Dedicated workspaces at 99.9% availability excluding scheduled downtime, and the tier you buy determines how much you control. Standard runs in a shared resource cluster with best-effort availability, so it suits teams that accept that trade. Premium and Dedicated allow you to choose regions, but confirm the exact regions available to your tier before you sign, because Standard runs only in the default region.
Choose self-managed when your rules require the database and message store to stay inside infrastructure you control, when you need to decide the exact day an upgrade lands, or when the workspace must run in an air-gapped network. Upgrade control is the sharpest difference. Premium cloud offers a 30-day postponement for major versions and Dedicated customers can freeze versions within the supported window, but patches apply continuously with no opt-out. Self-managed teams set their own patch cadence, which is also the job they then own. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, so plan a recurring upgrade window either way.
Which Rocket.Chat cloud tier matches which requirement
Standard cloud is the entry point into Rocket.Chat's hosted offering. Each customer gets a single-tenant workspace, but that workspace runs inside a shared resource cluster, and the SLA describes its availability as best-effort rather than as a committed percentage. Standard workspaces run in the default region, so you have no choice of location. This tier suits teams that want a managed chat workspace without an availability commitment and can tolerate interruptions during shared-cluster load.
- Tenancy: a single-tenant workspace on shared cluster resources.
- Availability: best-effort, with no 99.9% commitment in the SLA.
- Region: the default region only.
- Upgrades: managed by Rocket.Chat, so confirm with your account team how version timing is set for this tier.
- Good fit: internal chat where brief outages are acceptable and no regional choice is required.
Before you commit, ask Rocket.Chat to confirm the default region, the exact upgrade notice you will receive, and what happens to your data if you later move tiers.
Premium cloud moves each workspace into an isolated environment with pre-allocated resources, which reduces the risk that other customers' load affects yours. The SLA states 99.9% availability excluding scheduled downtime, and Premium workspaces can be placed in select regions. Upgrade control is more explicit than on Standard: major version upgrades are scheduled, and you can postpone a major upgrade by 30 days, while patches apply continuously with no opt-out. This tier suits regulated teams that need a stated availability target and some say in upgrade timing.
- Tenancy: isolated workspace with pre-allocated resources.
- Availability: 99.9% excluding scheduled downtime.
- Region: select regions, which may carry rate adjustments.
- Upgrades: major versions can be postponed by 30 days; patches cannot be declined.
- Good fit: production chat that needs a documented availability target but not custom DevOps work.
Before you commit, confirm which regions are offered, how the 30-day postponement is requested, and whether your compliance evidence needs to cover the continuous patch schedule.
Dedicated private cloud is the most controlled hosted option. It runs in a dedicated environment with custom regional hosting, and it carries the same 99.9% availability excluding scheduled downtime as Premium. Dedicated customers can freeze versions within the supported window, which gives the most control over when changes land, but patches still apply continuously. Custom DevOps services are available only on this plan, so it is the only cloud tier where Rocket.Chat's team can tailor operations to your environment.
- Tenancy: dedicated environment, not shared.
- Availability: 99.9% excluding scheduled downtime.
- Region: customer-selected regions with custom hosting.
- Upgrades: versions can be frozen within the supported window; patches still apply.
- Custom DevOps: available only on Dedicated.
Before you commit, ask what the supported window is for version freezes, how custom DevOps scope and fees are set, and which responsibilities stay with your own team.
A self-managed workspace runs on infrastructure you control, and Rocket.Chat states that self-managed deployment is available on all workspaces, including the free plans. Under this model you decide the region, the upgrade timing and the database operations, but you also carry the work of keeping Rocket.Chat 8.x on a MongoDB 8.0 or later replica set and patching it within the support windows. Rocket.Chat's version durability policy means unsupported versions lose security fixes and may stop connecting to the official mobile and desktop clients, so regular upgrades are part of running this model.
- Control: you choose the region, hosting and upgrade timing.
- Database: MongoDB 8.0 or later as a replica set, with three members strongly recommended for high availability.
- Support windows: standard releases get 6 months and LTS releases get 12 months of support.
- Upgrade effort: your team schedules and tests each upgrade.
- Good fit: teams with platform engineers who can own availability, backups and upgrades.
Before you commit, confirm which Rocket.Chat plan your self-managed design needs, since high availability and multi-instance designs require a paid plan, and ask a partner to scope the operating work.
How self-hosted and cloud Rocket.Chat compare on the factors that matter
This table sets Rocket.Chat cloud hosting against a self-managed workspace on the factors that change ownership, risk and exit cost. Read each row as a question to answer for your own workload, and treat the items marked to confirm as points to settle with Rocket.Chat before you sign.
| Factor | Rocket.Chat cloud hosting | Self-managed Rocket.Chat |
|---|---|---|
| Plan eligibility | Available only on the premium Commercial, Government and Defense plans | Available on all workspaces, including the free Starter plan and Community workspace |
| Tenancy | Standard is a single-tenant workspace in a shared resource cluster; Premium uses isolated workspaces with pre-allocated resources; Dedicated is a dedicated environment | Your infrastructure, your tenancy model, set by your own architecture decisions |
| Availability commitment | Premium and Dedicated carry 99.9% availability excluding scheduled downtime; Standard is best-effort (Rocket.Chat cloud hosting SLA) | No vendor SLA; uptime depends on your MongoDB replica set, load balancing and failover design |
| Region choice | Standard in the default region, Premium in select regions, Dedicated in customer-selected regions, with rate adjustments for region choice | Wherever you run it; confirm any residency requirement against your own environment |
| Upgrade control | Premium schedules major upgrades with a 30-day postponement option; Dedicated can freeze versions within the supported window; patches apply continuously on Premium and Dedicated | You choose when to upgrade, but unsupported versions lose security fixes and client connectivity, so the schedule is yours to keep |
| Licensing | Hosted under Rocket.Chat's terms for the chosen plan; confirm which enterprise code is included | Core code is MIT licensed; the apps/meteor/ee and ee directories fall under a separate enterprise license, which you need for paid features |
| Data location | Hosted by Rocket.Chat in the region selected under the plan; confirm where backups and support access are held | Stored in your cloud account, data center or air-gapped network |
| Custom DevOps access | Custom DevOps services are available only on the Dedicated Hosting plan | Available through any implementation partner you engage; scope it in writing |
| Exit path | Request a MongoDB export of messages, users, channels and metadata from Rocket.Chat Support; disable two-factor authentication first if the data will be reused | Your database is already yours; confirm backup and restore procedures in your own runbooks |
Where data lives and what compliance means in each model
Cloud hosting and self-managed Rocket.Chat differ in who operates the servers, who holds administrative access and where the data sits. Those differences shape the evidence you can collect, but they do not produce certifications, which belong to the vendor or to an independent auditor.
Data location and regions
Rocket.Chat cloud hosting places Standard workspaces in the default region, Premium workspaces in select regions and Dedicated workspaces in customer-selected regions, with rate adjustments for region choices. In a self-managed deployment, your own cloud account, data center or air-gapped network decides where messages and files are stored. Before you choose, confirm in writing which regions are available to your tier and where backups are kept.
Administrative access to the platform
On cloud hosting, Rocket.Chat operates the infrastructure, so your administrators control workspace settings but not the underlying servers or database. Self-managed deployments give your own team root access to the hosts, MongoDB and backups. Document who can reach the database, who can request a data export and how those requests are logged, since both models leave a different trail for an auditor to review.
Audit trail on paid plans
Rocket.Chat's paid plans list tamper-evident audit trails covering messages, files and sessions. Free Starter and Community workspaces do not include this feature, so a team that needs audit evidence must budget for a paid plan regardless of hosting model. Ask for a sample audit export and confirm retention periods and who can read the logs before relying on them in an assessment.
Air-gapped deployment is a paid capability
Air-gapped deployment is available only on paid plans and is not offered on Starter. If your network must have no outbound connection, the self-managed route on a paid plan is the path to evaluate, since cloud hosting depends on the vendor's connected environment. Confirm with Rocket.Chat which plan and license terms apply to your isolated network before scoping the installation.
Certifications belong to the vendor or auditor
Neither hosting model makes a workspace compliant by itself. Certificates and attestation reports are issued by the vendor's certification body or an independent auditor, and they cover a defined scope and period. Your own control mapping, evidence and configuration decide whether your use of the platform meets a framework, so treat the vendor's compliance package as an input to your assessment rather than a finished result.
Requesting documentation and confirming controls
Ask Rocket.Chat for its current compliance documentation, the scope of any certifications it holds and the hosting tier each one covers. Then map each control your framework requires to a configuration you own, such as retention, MFA, SSO and export handling. Record which controls the vendor supports, which you operate and which need a compensating measure, and confirm that mapping with your auditor.
What your team runs in each model
This table compares who carries each operating task under Rocket.Chat cloud hosting and under a self-managed workspace. Read each row as a question to put to Rocket.Chat and to your own team: the cloud column shows what the vendor documents, and the self-managed column shows what your organization must staff and maintain.
| Task | Rocket.Chat cloud hosting | Self-managed Rocket.Chat |
|---|---|---|
| Upgrades | Major version upgrades on Premium are scheduled with a 30-day postponement option. Dedicated customers can freeze versions within the supported window. | Your team plans and runs every major and minor upgrade, and must stay within a supported release line. |
| Patching | Patches apply continuously with no opt-out on cloud plans, per the cloud SLA. | Your team applies patch releases, such as 8.6.3 and 8.5.4 published October 16, 2026, on its own schedule. |
| Database operation (MongoDB 8.0 or later as a replica set) | Rocket.Chat operates the MongoDB layer inside the cloud workspace. Confirm backup and restore terms in writing. | Your team runs MongoDB 8.0 or later as a replica set, with three members recommended for high availability, plus backups and failover tests. |
| Scaling by reference architecture | Scaling design is handled by Rocket.Chat. Ask which architecture and capacity apply to your plan and region. | Up to 500 concurrent users: one instance with a MongoDB replica set. Above 500: load-balanced instances linked by NATS. Above 5,000: Kubernetes with the official Helm chart. Multi-instance and microservice designs require a paid plan. |
| Support windows (6 months standard, 12 months LTS) | Rocket.Chat tracks release support for cloud workspaces. Confirm which version your workspace runs and when it leaves support. | Your team must move to a supported line within 6 months for standard releases or 12 months for LTS releases, or lose security and bug fixes. |
| Client compatibility after end of life | Rocket.Chat manages the workspace version, so client compatibility follows its upgrade schedule. Confirm mobile and desktop client support in writing. | Once a version is end of life, cloud services stop and official mobile and desktop clients may disconnect, so your team must plan upgrades to keep users connected. |
How to move a workspace out of Rocket.Chat cloud
The sequence gets a cloud-hosted workspace into a self-managed Rocket.Chat instance with its messages, users, channels and metadata intact, and with a clear check at each stage that the data arrived and the clients still connect.
Confirm the current plan and hosting tier
Start by checking which cloud tier the workspace runs on: Standard, Premium or Dedicated. Cloud hosting is offered only on the premium Commercial, Government and Defense plans, so the account owner should confirm the plan in writing with Rocket.Chat before asking for an export. Record the workspace version, the region and any custom DevOps arrangements, because Dedicated customers may have agreed terms that affect the handover. The step is done when the account owner has a written record of the plan, tier and version that the rest of the project can work from.
Request the MongoDB export from Rocket.Chat Support
The workspace owner asks Rocket.Chat Support for a MongoDB export covering messages, users, channels and metadata. The request should name the workspace and the target, and it should state whether the data will be reused in a new workspace, since that changes the next step. Ask Support to confirm the export format, the delivery method and any retention or handling terms for the file. The step is done when the export file has been received and its contents have been checked against the workspace's known channel and user counts.
Disable two-factor authentication before export
If the data will be reused in a new workspace, two-factor authentication must be disabled before the export is taken. Administrators should plan this with the identity team, because users will need a way to sign in to the target system once it is live, and they should record who turned it off and when. Re-enable it on the target through the new identity configuration rather than carrying the old setting across. The step is done when the export has been taken under the agreed setting and the change is logged in the migration record.
Plan the target replica set and version
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. The platform team should size the self-managed host or cluster against the reference architectures, which suggest a single instance with a MongoDB replica set up to 500 concurrent users, and confirm whether the design needs multiple instances or the Helm-based microservices, which require a paid plan. Choose a supported release line and check its end-of-life date before import. The step is done when the target architecture, MongoDB version and Rocket.Chat release are written down and approved by the owner.
Import the export into the self-managed workspace
Restore the MongoDB export into the target environment and bring up Rocket.Chat against it, following the installation steps for the chosen deployment method. Note that moving data in is a separate path: the supported importers cover full Slack workspace exports, Slack users from CSV and a CSV importer for other sources, and Mattermost data is converted to CSV first. The migration effort depends on the target environment, including hosting, identity and storage choices, so confirm the steps with the vendor documentation and your own environment before running them. The step is done when the workspace starts cleanly and the record counts match the export.
Validate users, channels and client connections
Sign in with a sample of accounts from each group, including administrators, and confirm that channel membership, permissions, files and message history look correct. Check that the official mobile and desktop clients connect to the new URL, since unsupported versions can lose that ability, and confirm push notifications work with the chosen setup. Reconnect single sign-on and directory sync where the paid plan provides them, and re-enable two-factor authentication for users. The step is done when a documented test sign-off shows the sampled users and clients working and the account owner accepts the result.
Close the cloud account and keep the export
Once the self-managed workspace has passed validation, agree the cut-over date with Rocket.Chat and communicate it to users. Ask the vendor to confirm the cloud workspace's final state and how long any remaining data is retained, and keep the export and the migration record under your own retention policy. Confirm with the vendor what cloud-side services, such as the push notification gateway or Marketplace integrations, stop when the workspace closes. The step is done when the cloud subscription has been ended in writing and the export and validation records are stored in your own systems.
Questions buyers ask before choosing a Rocket.Chat hosting model
Is Rocket.Chat cloud hosting available on the Starter or Community plans?
No. Cloud hosting is available only on the premium Commercial, Government and Defense plans, according to Rocket.Chat's hosting FAQ. The free Starter plan (up to 50 users) and the free Community workspace (up to 100 concurrent users) can only be self-managed, on infrastructure you run yourself. If you want Rocket.Chat to host the workspace, the paid plans are the starting point, so confirm the current plan options and eligibility with Rocket.Chat before you plan around them. Self-managed deployment is available on all workspaces, which keeps the free plans viable for teams that already operate their own MongoDB and hosting.
What drives the cost of Rocket.Chat cloud hosting versus self-managed?
The cost splits into three components. Cloud hosting is a paid plan priced by quote, so the figure depends on the plan tier, user count, region and hosting level you choose. Self-managed Rocket.Chat carries infrastructure costs for servers or cloud instances, a MongoDB replica set, storage and backups, plus the staff time to install, patch and monitor it. Rocket.Chat does not publish prices for these tiers on the pages we reviewed, so ask for a written quote that lists the plan, hosting tier, region, support level and any custom DevOps work. Ask the vendor which costs recur monthly or annually and which are one-time migration charges.
How long does it take to move a Rocket.Chat workspace between hosting models?
The duration depends on the size and shape of your data, the hosting tier involved, and how much you need to rebuild around the workspace. Cloud-hosted workspaces can be updated from the Rocket.Chat Cloud portal in typically 15 to 30 minutes, according to the hosting FAQ, but that covers routine updates, not a platform move. Moving to self-managed also means provisioning a MongoDB 8.0 or later replica set and reconnecting integrations, and moving away from cloud means requesting an export from Rocket.Chat Support first. Ask the vendor for a written migration plan with a timeline and dependencies before you commit to a cutover date.
What does a move to or from Rocket.Chat cloud hosting need from our team?
Expect your team to own several decisions. You need an owner for user and identity mapping, for integrations such as Marketplace apps and Omnichannel connections, and for sign-off on the cutover window. Self-managed operation also needs people who can run MongoDB as a replica set, keep Rocket.Chat within a supported version, and handle backups and restores. Rocket.Chat says unsupported versions may lose the ability to connect with the official mobile and desktop clients, so upgrades are an ongoing duty. Standard releases are supported for 6 months and LTS releases for 12 months, so plan a recurring upgrade calendar.
Can our team run Rocket.Chat ourselves without a vendor hosting plan?
Yes, if your team has the skills, because self-managed deployment is available on all workspaces. The work includes a MongoDB 8.0 or later replica set (three members is strongly recommended for high availability), a Node.js runtime bundled in the official Docker image and Helm chart, and upgrades on the 6-month or 12-month support cycle. Reference architectures suggest one instance with a replica set up to 500 concurrent users, but multi-instance and Kubernetes microservice designs require a paid plan. Confirm your staffing, on-call and patching capacity honestly before choosing this route. DeployOpen can plan, implement, harden, back up and document a self-hosted platform inside your own infrastructure under a written scope, and offers ongoing support and upgrades as retainers.
What happens to the MongoDB export if two-factor authentication is enabled?
Disable two-factor authentication before you request the export if the data will be reused in a new workspace. To leave cloud hosting, you ask Rocket.Chat Support for a MongoDB export of messages, users, channels and metadata, and the hosting FAQ says two-factor authentication must be turned off first for that reuse. Plan for users to re-enroll their second factor after the move, and check with Rocket.Chat Support how the export handles files and other data you need before you start. Record who approved the change, because turning off MFA temporarily lowers the account security of the workspace.
Which cloud hosting tier gives upgrade control, and does it matter for us?
Upgrade control differs by tier, and it matters most if you have change-freeze windows or regulated release approvals. On Premium cloud, major version upgrades are scheduled with a 30-day postponement option, and patches apply continuously with no opt-out. Dedicated customers can freeze versions within the supported window, which suits teams that must test before each change. Standard runs on a shared resource cluster with best-effort availability. Premium and Dedicated carry 99.9% availability excluding scheduled downtime, according to the cloud hosting SLA, so read that document for the exact terms that apply to your contract.
What changes for your team after you pick a model
The choice between cloud hosting and a self-managed workspace decides who carries the upgrade calendar, and that calendar never stops. Rocket.Chat 8.9.0 was published on October 5, 2026, and patch releases for older supported lines followed on October 16, 2026. Standard releases are supported for 6 months and LTS releases for 12 months, so a self-managed team must schedule a move onto a supported line before the current one ends. On Rocket.Chat Premium cloud, major upgrades can be postponed for 30 days, patches apply continuously with no opt-out, and Dedicated customers can freeze versions only within the supported window. Confirm with Rocket.Chat exactly which patch and major-version decisions your contract leaves to you.
Version durability has a sharper edge than a missed security fix. After end of life, a version stops receiving security and bug fixes, and cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Rocket.Chat also warns that unsupported versions may lose the ability to connect with the official mobile and desktop clients. Your mobile fleet therefore inherits the server's age. Before you pick a model, list the clients your users run, test them against the next server line on a staging workspace, and assign an owner for that test each release cycle.
Incident response is where the two models diverge most. On cloud hosting, Rocket.Chat operates the environment and its SLA sets availability targets, but your security team still owns the decisions about user access, export requests and any data that leaves the cloud. On a self-managed workspace, your team owns the MongoDB replica set, backups, Node.js runtime updates and the on-call rota. Write a runbook that names who declares an incident, who contacts Rocket.Chat Support, and who approves a MongoDB export, and test it before go-live. Confirm the support response commitments in writing with Rocket.Chat, because the plan you buy determines them.
How DeployOpen scopes and supports self-hosted Rocket.Chat
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For Rocket.Chat, that means working out whether a managed Rocket.Chat Cloud plan or a workspace you run yourself fits your data, identity and upgrade requirements, and then doing the work in writing.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which hosting model applies, where data and backups live, and which identity provider Rocket.Chat must integrate with.
- Ask for the scope to list the Rocket.Chat edition and MongoDB replica set topology, since both drive the work.
How we build
- Self-managed workspaces are deployed in your own infrastructure, with MongoDB 8.0 or later as a replica set configured to your availability target.
- Authentication, backup, and upgrade procedures are implemented and tested against the Rocket.Chat release line you select.
- Reference architecture choices, such as single-instance or multi-instance designs, are documented with the paid plan they require.
How we hand over
- Handover includes documentation of configuration, data stores, backup and restore steps, and the upgrade runbook.
- Migration steps for moving data in or out, including the MongoDB export path, are written up with the prerequisites your team must meet.
- Ask for a written list of what is handed over, what remains your responsibility, and what each side must verify before cutover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover tracking Rocket.Chat release and end-of-life dates so your team plans upgrades before a line stops receiving fixes.
- Confirm with DeployOpen which support tasks sit inside a retainer and which are quoted separately before you sign.
