What upgrades and support involve for Rocket.Chat
Rocket.Chat standard releases are supported for 6 months, and LTS releases are supported for 12 months. After a version reaches end of life, it receives no security or bug fixes, and cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Confirm the end-of-life date for your exact release line in the version durability documentation before you plan each upgrade, because that date sets the deadline for your change window.
Four events usually start an upgrade. A release line is approaching end of life. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so a database upgrade may need to happen first. A security advisory affects a version you run. An app or integration breaks after an update. The first two are scheduled work, the third is urgent, and the fourth requires a staging environment that mirrors your production apps and integrations.
Most teams with a Linux or Kubernetes operator can run routine patch and minor upgrades in-house, provided they keep a staging copy, a tested MongoDB backup and a documented rollback path. Teams with many integrations, a paid multi-instance or microservice design, or no spare operator time usually bring in a partner for the planned upgrade and an ongoing retainer. Ask for the planned upgrade and the retainer as separate line items, so you can see which costs are one-time and which recur.
Plan for unsupported versions to cost you more than security fixes. Rocket.Chat states that unsupported versions may also lose the ability to connect with the official mobile and desktop clients, which affects every user, not only administrators. Track your running version against the supported release lines, and include client compatibility in your check before each upgrade.
What the upgrade and support work includes
Upgrade and support work moves through a fixed sequence: review what is running, plan the target release, rehearse in staging, cut over with a rollback path, verify, and then keep the instance inside a supported line. The cards below describe each package and what the client receives.
Current-state review
We record the Rocket.Chat version, edition, deployment method (Docker, Helm or another method), MongoDB version and replica set health, and every app and integration in use. This inventory shows which upgrade path is open and which components could block it. Confirm who holds the admin and database credentials before the review starts.
Upgrade plan and target release
We select a target release on a line that is still supported, based on the version durability rules for standard (6 month) and LTS (12 month) releases. The plan sets the upgrade path, the order of component changes, and the go or no-go checks. Confirm the current end-of-life date for your running version with the Rocket.Chat documentation before planning.
MongoDB upgrade where required
Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set. Where your database is older, we plan the MongoDB upgrade as a separate step with its own backup, rollback point and compatibility checks. Confirm the MongoDB version and replica set member count with your database owner before scheduling.
Staging rehearsal and app testing
Before each Rocket.Chat release reaches production, we rehearse the full upgrade in a staging copy built from production configuration and data. Each installed app and integration is tested against the new release, and failures are logged with owners. Staging must match production closely enough that the rehearsal result can be trusted.
Production cutover with rollback
The production change follows the rehearsed runbook in a agreed maintenance window. Before the change we take verified backups of the database and file storage and define the rollback trigger and steps. If a check fails, the rollback path returns the service to the previous release and data state.
Post-upgrade verification
After cutover we verify web and desktop client sign-in, mobile push delivery, and every integration against the checklist from staging. We also confirm the replica set health and monitoring signals are normal. Unsupported versions can lose connections to official mobile and desktop clients, so client checks are part of sign-off.
Runbook, calendar and support retainer
We document the upgrade steps, rollback steps and ownership, and maintain a release calendar that tracks release and end-of-life dates. An optional support retainer covers monitoring of those dates, patch application and incident response. Scope, deliverables and timelines are agreed in writing before work starts.
How an upgrade project runs
The sequence moves a Rocket.Chat instance from its current release to a supported target with a tested rollback path and a support calendar that keeps it inside its support window.
Inventory the current deployment
We record the running Rocket.Chat version, the MongoDB version and topology, installed Marketplace and private apps, integrations and webhooks, connected clients, and any custom code. The output is a written inventory that your team signs off, and it becomes the baseline for every later decision.
Select the target version and MongoDB plan
We compare the current release against the 6-month standard and 12-month LTS support windows in the version durability documentation and recommend a target line. The same review produces a MongoDB upgrade plan, because Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set. The output is an agreed target version and an ordered MongoDB path, both confirmed in writing.
Rebuild staging from a backup
We restore a recent production backup into a staging environment that matches production's topology, then run the upgrade there first. App and integration tests cover the Marketplace apps, webhooks and business system connections found in discovery. The step closes when every test in the agreed list passes or each failure has a documented fix.
Agree a dated cutover plan
We write a cutover plan with a dated change window, a freeze window for new configuration changes, named owners, and explicit rollback criteria that state which failures trigger a return to the previous version. Your team approves the plan before production is touched. The output is a signed plan and a tested rollback procedure.
Upgrade production and verify
We run the upgrade in the approved window, following the staging procedure, then check login through your identity provider, message delivery, file access, push notifications, mobile and desktop client connections, and the integrations from the inventory. The step closes when the verification checklist is complete and the agreed rollback criteria have not been triggered.
Hand over to a support calendar
We deliver the updated inventory, the test results, the runbook and a calendar of upcoming Rocket.Chat release and end-of-life dates for your deployment. Your team receives the ownership list and the process for each future upgrade. The step closes when your team accepts the handover, and any ongoing support or retainer scope is recorded separately.
What drives upgrade cost and effort
This table lists nine drivers that change Rocket.Chat upgrade cost and effort, why each one matters, and how to reduce it.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Apps and integrations | Marketplace apps, private apps and custom code each need their own retest against every target release. | Remove unused apps, keep integrations on documented APIs, and record an owner for each one. |
| Version gap | Skipped releases add migration steps, and a version past end of life gets no fixes and loses cloud services. | Upgrade inside the support window of 6 months for standard or 12 months for LTS releases, and read each release's notes. |
| MongoDB topology | Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, so older clusters may need a database upgrade first. | Confirm the current MongoDB version and replica set health, then plan the database step before the application step. |
| Deployment type | Multi-instance above 500 and microservices above 5,000 concurrent users add components to upgrade, and both need a paid plan. | Confirm concurrent user count and plan tier first, then rehearse the upgrade in staging for the same deployment type. |
| Edition and enterprise license | Code under the apps/meteor/ee and ee directories is covered by a separate enterprise license, so confirm which terms apply to your work. | Confirm your plan and license scope in writing before the upgrade, and list which enterprise-licensed components you run. |
| Environments and staging fidelity | Staging must match production's MongoDB version, deployment type, apps and identity settings, or test results may mislead the go or no-go decision. | Keep a staging copy with masked data, the same app list, and a rehearsed rollback for each environment. |
| Identity and SSO configuration | LDAP, Active Directory, SAML or OAuth settings, group mappings and MFA can change behavior after a version change and must be retested. | Document each sign-in path and group mapping, and add login tests for each identity method to every upgrade run. |
| Compliance evidence | Assessors may ask for change records, test results and version history for each upgrade, which are easiest to capture during the work. | Agree the evidence list with your assessor before the upgrade, and store test output and approvals with the change ticket. |
| Mobile and desktop client support | Rocket.Chat says unsupported versions may lose the ability to connect with official mobile and desktop clients. | Check client compatibility for your target version, and ask users to update clients in the same window as the server. |
What usually goes wrong in Rocket.Chat upgrades
Most Rocket.Chat upgrade problems are scheduling, data and ownership problems, not software failures. Each risk below has a check you can put in place before the next release arrives.
Upgrading after end of life
A version that has passed end of life receives no security or bug fixes, and cloud-linked services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Prevention: map every running version against its published support end date and schedule the upgrade before that date, not after an incident forces it.
MongoDB upgraded out of order
Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so the database version and the application version must be planned together. Upgrading a single node without a verified backup removes the rollback path. Prevention: confirm the required MongoDB step order in the system requirements, take a tested backup, and rehearse the sequence on a copy.
Apps failing only in production
Marketplace apps and private apps are often built against one release and can break on the next without warning. Teams usually find this when users report it after cutover. Prevention: keep a written inventory of every installed app with its owner and version, and run each one against the new release in staging before production.
Integrations built on a changed API
Webhooks, bots and scripts that call the Rocket.Chat REST or Realtime API can fail when an endpoint, payload or permission model changes. These failures often look like silent message loss. Prevention: list each integration with its API calls and test them against staging after every release note review.
Clients locked out after upgrade
Rocket.Chat states that unsupported versions may lose the ability to connect with the official mobile and desktop clients. Staff then cannot reach conversations even though the server appears healthy. Prevention: define the minimum client versions your users need, communicate them with the release date, and check client connectivity in the staging rehearsal.
No owner for release tracking
When nobody owns release tracking, the team learns about end-of-life dates and breaking changes from the vendor or from a failure. Each skipped cycle makes the next upgrade larger and more urgent. Prevention: name one accountable owner, maintain a dated release calendar with support end dates, and set rollback criteria that state when a failed upgrade is reversed.
How upgrades differ by starting point
An older single-instance Docker deployment usually needs more than an image swap. Plan the path through the intermediate releases the vendor documents, and treat the MongoDB upgrade as its own project.
- Release path: Confirm whether the vendor documentation allows a direct jump to the target release or requires stops at intermediate versions.
- MongoDB: Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so the database may need several steps before the application upgrade.
- Backups: Take and test a full database and file backup before the first step, and keep each prior image available for rollback.
- Bundled runtime: Node.js ships inside the official Docker image, so confirm the image tag matches the target release and rebuild any custom image from it.
- Support window: Check that the starting version is still supported, since end-of-life versions lose security fixes and cloud-connected features.
On Kubernetes, the chart version drives most decisions. Compare the installed chart and application versions with the target before changing anything, because values files often change between releases.
- Chart version: Map the installed chart to the target chart and review every values change between the two.
- Ingress: Confirm the ingress controller and TLS settings still match what the target chart expects.
- Storage classes: Verify that the storage class names and access modes used for uploads and MongoDB exist in the target cluster.
- MongoDB placement: If MongoDB runs in the cluster, confirm that the operator or chart version supports the required replica set version.
- Cluster version: Check the Kubernetes version against the compatibility the chart documents for the target release.
Multi-instance and microservice deployments need a planned component order. Upgrading everything at once makes it hard to tell which component caused a fault. This design requires a paid plan.
- Component order: List every instance, microservice and NATS component, and confirm the vendor's required sequence.
- NATS: Upgrade the message bus in step with the components that depend on it, after confirming compatible versions.
- Rolling steps: Upgrade one instance or service at a time, keeping at least one healthy copy of each service running where the architecture allows.
- Database: Keep the three-member MongoDB replica set healthy throughout, and confirm the database version before the application steps begin.
- Failover test: Confirm failover behavior on a staging copy before production, because rolling steps can expose gaps in it.
Marketplace and private apps often set the schedule. Each app has its own compatibility with the target release, so testing can take more effort than the platform upgrade itself.
- Inventory: List every installed Marketplace and private app with its version, owner and the features it depends on.
- Compatibility: Check each app's stated support against the target release, and note any app the publisher no longer maintains.
- Test cases: Write test scripts for each integration, such as webhooks, bots and SSO sign-in, and run them on a staging copy.
- Private apps: Rebuild and retest private apps against the API and SDK changes the vendor documents for the target release.
- Sign-off: Assign an owner who approves each app before the production cutover.
In an air-gapped deployment, nothing starts until images, charts and packages cross the gap. Plan the transfer and verification before scheduling the upgrade. Air-gapped use is a paid-plan capability.
- Transfer process: Confirm the approved media process and who signs off each import into the isolated network.
- Artifacts: Collect every container image, chart and dependency for the target release, along with the MongoDB packages it needs.
- Integrity: Verify any checksums or signatures the vendor publishes before importing the files.
- Local mirror: Stage a local registry or package mirror inside the enclave so the cluster or hosts can pull the updates.
- Internet-dependent features: Identify which features need outside connectivity, and confirm the vendor's offline options for each one before testing.
What your team needs to provide
A written upgrade and support scope depends on what your team can give us before work starts. The partner needs the Rocket.Chat version, edition and plan in use, the MongoDB topology (a standalone node or a replica set, and its member count), and the deployment method, whether Docker, the official Helm chart or a manual install. Confirm these answers with your platform owner before the first call, because the upgrade path, test effort and rollback design all change with them.
On the infrastructure side, provide administrative access to the Rocket.Chat servers or cluster and to MongoDB, along with current backups and a restore path that your team has tested. A backup that has never been restored is not a rollback plan. Also provide a staging environment that matches production as closely as practical, including the same MongoDB major version, reverse proxy, identity provider connection and file storage. If staging differs, list the differences in writing so the test plan can cover them.
Your business side owns the decisions that keep an upgrade safe. Provide a list of workspace apps, integrations and webhooks with a named owner for each, so every item can be tested against the target release. Agree a maintenance window with business owners, name the people who make the go or no-go call and the rollback call, and get change control approval in writing. Also name one point of contact who will send user communication about downtime, changed behavior and mobile client updates.
Frequently asked questions about Rocket.Chat upgrades and support
How often do Rocket.Chat releases need upgrading?
Standard Rocket.Chat releases are supported for 6 months, and LTS releases are supported for 12 months. Once a version reaches end of life, it receives no security or bug fixes. Plan each move to a supported line before your current one expires, and track the end-of-life date for every version you run. An LTS line lowers how often you must upgrade, but each upgrade still needs testing. Confirm current support dates in the Rocket.Chat version durability documentation before you schedule work.
Can our team upgrade Rocket.Chat in-house, or do we need a support retainer?
Yes, many teams upgrade in-house if they can run the MongoDB replica set, the container or Kubernetes deployment, and the Rocket.Chat configuration. The work is mostly planning, backups, staging tests of each app and integration, and a written rollback plan. A support retainer suits teams that want ongoing upgrades, patch handling and testing without adding staff. Whichever path you choose, rehearse the upgrade on a non-production copy first, and confirm with each app author whether it supports the target release.
What drives the cost of a Rocket.Chat upgrade and how is a quote built?
The main cost drivers are the number of versions being crossed, the MongoDB step, the deployment model, the number of apps and integrations to retest, and the size of the data to back up. A quote follows from a written scope that names the target version, the environments in scope, the integrations to test and the deliverables, such as runbooks and rollback steps. You provide access, environment details, an integration inventory and named contacts for approvals. DeployOpen does not publish a price list, so ask every bidder to price the same written scope.
Do we have to upgrade MongoDB before moving to Rocket.Chat 8.x?
Yes. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so your database must meet that requirement before or as part of the Rocket.Chat upgrade. Check the system requirements for your exact target release, and treat the MongoDB step as its own tested change with a fresh backup beforehand. A three-member replica set is strongly recommended for high availability. Your current MongoDB version and deployment layout determine how much work this step involves, so confirm both before you set a date.
What happens to mobile apps and cloud features after end of life?
After end of life, cloud-linked services stop working. These include the push notification gateway, Marketplace and Omnichannel integrations. Rocket.Chat also says unsupported versions may lose the ability to connect with the official mobile and desktop clients. Users may see sign-in or notification failures before anyone raises a larger outage. Plan the upgrade so mobile and desktop clients are tested against the target server version, and tell users which client versions they need before cutover.
Does DeployOpen issue certifications or audit reports for our upgrades?
No. DeployOpen does not issue audit reports, attestations or certifications. It can prepare systems, controls and evidence, such as change records, test results, backup logs and configuration documentation, so that independent auditors or certification bodies can assess them. Ask which evidence your assessor expects before the upgrade starts, so the test and change records are captured as the work happens. Your assessor decides what is sufficient for your compliance program.
How DeployOpen scopes, delivers and supports Rocket.Chat upgrades
DeployOpen plans and carries out Rocket.Chat upgrades inside the client's own infrastructure, starting from the supported version and release window the organization must stay within. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Inventory the running Rocket.Chat version, its edition, deployment method and the MongoDB version in use.
- Map the current version against the published support window to set the target release and its deadline.
- Record every app, integration and webhook that must keep working, and agree which ones are tested before each release.
- Agree the written scope, deliverables and timeline before any upgrade work starts.
How we build
- Confirm the MongoDB upgrade path, including replica set health and a 8.x-compatible MongoDB version, before touching Rocket.Chat.
- Stage the upgrade in a non-production copy of the environment that mirrors your identity, storage and proxy settings.
- Test installed apps, integrations and mobile and desktop client connections against each release candidate.
- Take and verify backups of the database and file storage before each change, with a documented rollback path.
How we hand over
- Document the final versions, configuration changes, upgrade steps and test results in a runbook your team can repeat.
- Walk your administrators through the upgrade procedure and the checks that confirm a healthy post-upgrade state.
- Provide a schedule of upcoming support window dates so your team can plan future upgrades ahead of end of life.
- Record open issues, known limitations and the items your own team must confirm with the vendor.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, defined in writing before it starts.
- Monitor vendor release announcements and patch releases and flag when your running line needs attention.
- Repeat app and integration testing for each new release so custom and third-party functions keep working.
- Agree response expectations and service levels in the retainer scope, not assumed as standard.
