Rocket.Chat follows a structured release lifecycle and uses semantic versioning in the format Major.Minor.Patch for its version numbers. Each release type serves a different purpose and follows a defined support timeline. This document explains the release types, support durations, Long-Term Support (LTS) policy, end-of-life implications, and upgrade best practices.
Release types, versioning, and expected content
Release Type | What It Is | What It Includes |
|---|---|---|
Major Release: Indicated by a bump in the first digit of the version, for example | A foundational upgrade that can introduce breaking changes, such as new system requirements, deprecated features, or database migrations. Treat major releases as planned events. | Significant new or reworked features, performance improvements, or architectural changes. Includes cumulative fixes from prior minors and patches. May require configuration changes, client-side updates, or additional regression testing. |
Minor Release: Increments the second digit of the version, for example | An update in the same major version that remains backward-compatible while adding new features. | New or enhanced capabilities, such as integrations, admin settings, or UI and UX improvements. May also include performance, stability, and security improvements. Features may be deprecated for removal in the next major release, but existing integrations in the same major series should continue to work. |
Patch Release: Changes the third digit of the version, for example | A low-risk update focused on stability and security. Patch releases should generally be applied quickly. | Bug fixes for regressions or defects in the current major or minor release, security vulnerability patches, and vulnerable dependency updates that are exploitable in Rocket.Chat. Patch releases do not introduce new features or intended behavioral changes. |
Long-Term Support (LTS) Release: A regular semantic version explicitly designated as LTS in release notes and lifecycle documentation | A stable release line with an extended support window for customers who prefer a slower upgrade cadence. | Includes all features available up to the LTS designation date. After entering maintenance mode, the release receives patch-only updates for security fixes and critical stability issues. No new features or minor enhancements are added after LTS designation. |
Understanding both the version bump and the expected content of each release type helps administrators plan upgrades, allocate testing effort, and balance innovation with operational stability.
Support duration by release type
Rocket.Chat provides time-bound support windows for each release line. During a release’s support window, Rocket.Chat provides security updates and critical fixes. Once that window closes, the release reaches end of life and is no longer supported.
Release Type | Example Version | Support Duration | What It Means |
|---|---|---|---|
Major Release |
| 6 months from the release date | Standard releases receive support for 6 months from the date they are released. For example, if a release ships in January, it remains supported until June 30 of that year. Administrators should plan upgrades within that support window to remain on a supported version. |
Minor Release |
| 6 months from release date | Minor releases follow the same 6-month support window as major releases. |
Patch Release |
| Inherits the support window of its parent major or minor release | Patch releases do not create a new support window. They provide fixes within the support lifecycle of the release line they belong to. |
LTS Release |
| 12 months from release date | Starting with Rocket.Chat 7.10.x, LTS releases are supported for 12 months from their release date. During this period, Rocket.Chat backports security fixes and critical stability fixes to the LTS line. For exact end-of-support dates, refer to the Version Durability Matrix. |
Security fixes, including vulnerability patches and related dependency updates, are backported to supported release lines during their support period. Dependency fixes are backported only when the vulnerability is exploitable in Rocket.Chat.
Long-Term Support (LTS) policy and usage
Cadence
Rocket.Chat designates selected releases as Long-Term Support releases based on release planning and stability criteria. LTS designations are communicated through release notes, lifecycle documentation, and the Version Durability Matrix. Because release planning may evolve over time, administrators should use the Version Durability Matrix as the authoritative source for currently supported LTS versions and end-of-support dates.
Support Window
Starting with Rocket.Chat 7.10.x, each LTS release is supported for 12 months from its release date. During this window, Rocket.Chat provides maintenance updates only, including security fixes and critical bug fixes. No new features or minor enhancements are added after an LTS line enters maintenance mode.
Earlier releases continue to follow the support policy that applied when they were designated, unless Rocket.Chat announces otherwise.
Intended Use Cases
LTS releases are best suited for organizations that prioritize stability, predictability, and controlled change management. This includes enterprise environments, business-critical production systems, and teams with strict testing or change approval processes.
An LTS release allows teams to remain on a stable baseline for a longer period while continuing to receive essential fixes. The tradeoff is that new features, non-critical improvements, and most general maintenance changes continue to ship through standard releases and future LTS versions.
Security fixes are backported to supported LTS releases, while security improvements and new features are typically delivered through newer standard releases.
An LTS release is a good fit for environments where frequent upgrades are difficult, but maintaining supported and secure software remains essential.
Security fixes are backported to LTS releases, while security enhancements and new features are available only in standard releases (Major or Minor).
An LTS release allows you to delay full version upgrades while continuing to receive patches for verified vulnerabilities. It's ideal for environments where frequent updates are challenging but maintaining essential security is critical.
Depending exclusively on LTS versions may result in non-security issues going unresolved.
Security fixes vs. security improvements
Rocket.Chat release notes may distinguish between security fixes and security improvements. These terms are related, but they are not the same.
Security fixes are patches that resolve specific identified vulnerabilities or security-related bugs. These are reactive changes that address known weaknesses, such as authentication bypasses, cross-site scripting issues, or other exploitable flaws. Because they address active risk, security fixes are prioritized and backported to supported release lines.
Security improvements are proactive changes that strengthen the overall security posture of the application, but are not necessarily tied to a known exploitable vulnerability. Examples include stronger defaults, additional validation, configuration hardening, or broader permission checks. These changes improve security over time, but they are generally treated as forward-looking product improvements rather than emergency fixes.
In simple terms, security fixes patch holes that have been found. Security improvements make the system harder to break in the future.
From an administrator’s perspective, both matter. If a release includes a security fix, apply it as soon as possible if your version is affected. Security improvements are also valuable, but they may not be backported to older release lines.
Backporting policy (What gets backported and what doesn’t?)
Change Type | Backported? | Guiding Principle | What You Can Expect |
|---|---|---|---|
Security fixes | Always | Protect every deployment that is still within its support window. | A patch is released for all supported lines, including supported LTS lines. You should not need to jump to a new major or minor release just to stay secure. |
Critical bug fixes | Usually | Keep supported versions stable and usable. | Rocket.Chat evaluates impact and prevalence. If the issue affects production stability, a patch release may be issued for each affected supported version. |
General bug fixes and minor enhancements | No | Focus development effort on forward progress. | Routine UI updates, performance tuning, refactoring, and other non-urgent work are delivered through newer standard releases. |
Security improvements | No | Treat improvements as forward-moving changes rather than emergency fixes. | These changes appear in future releases and are not generally backported unless an actual vulnerability is involved. |
Practical implications for administrators
Running LTS? You will receive security fixes and critical stability fixes for the duration of the LTS support window. Starting with 7.10.x, that window is 12 months from release.
Running a standard release? You remain covered for 6 months from the release date. After that, upgrade to continue receiving fixes.
Need a non-critical bug fix or minor enhancement? In most cases, the answer is to upgrade to a newer standard release. That is where non-urgent improvements are delivered.
Rocket.Chat backports what is necessary to keep supported instances secure and stable. Everything else moves forward through the normal release train.
This policy means that if you prefer not to upgrade frequently, using an LTS release is advantageous because you’ll receive security fixes for a longer period. However, even on LTS, you will not get non-security improvements until you move to a newer release. Conversely, those who track the latest releases will get improvements sooner, but must update more often and still need to stay within the 6-month support window to receive fixes.
Always consult Rocket.Chat’s official security advisories and announcements. In some cases (especially for critical vulnerabilities), Rocket.Chat might even provide out-of-band patches or workarounds. The Version Durability Matrix will list which versions are currently supported and receiving patches. Use that as authoritative guidance on where backports will apply. If your version is not on that list, it will not receive any fixes and an upgrade is required to maintain security.
End-of-Life (EOL) and implications
When a Rocket.Chat release reaches the end of its support window, it becomes End-of-Life (EOL). Standard releases follow the standard support timeline, while LTS releases starting with 7.10.x are supported for 12 months from release. Always refer to the Version Durability Matrix for the exact end-of-support date of your release line.
Running an EOL release has important consequences:
No Official Updates or Fixes: Once EOL, the development team no longer provides patch releases for bugs or security vulnerabilities on that version. Any known issues will remain unresolved unless you upgrade to a supported version. This leaves EOL installations increasingly vulnerable over time.
Loss of Cloud Services Integration: Rocket.Chat has implemented policies to disable cloud-dependent services for EOL servers. Hosted services such as the Push Notification Gateway, Marketplace (app marketplace), and Omnichannel Citizen Engagement integrations will cease to function for that particular version once it is out of support end of life date.
Mobile and Desktop Apps Access: Similarly, official Rocket.Chat mobile and desktop clients will not connect to EOL servers. The mobile and desktop applications enforce version checks to ensure the server is within the supported range. If users attempt to use a modern Rocket.Chat mobile/desktop app against an outdated server, they may encounter errors or warnings preventing login. (In practice, the existing installed app may continue working with an out-of-support server until the app itself updates to a version that enforces the block. But administrators should assume that once the server is EOL, any update of the clients could cut off connectivity.)
Security and Compliance Risks: An unsupported version that no longer receives security patches is vulnerable. For organizations subject to security standards or data protection compliance, running an EOL version can be a liability. It’s generally considered best practice to upgrade before the EOL date to ensure continued security hardening and compliance.
For uninterrupted service, plan upgrades before the EOL date.
Once your workspace release reaches End of Life (EOL) and exits the support window, access to the Mobile and Desktop apps will no longer be available for users.
End-of-life means the Rocket.Chat instance is effectively frozen in time and disconnected from the support ecosystem. For uninterrupted service administrators must keep the server within a supported release. Always plan upgrades before the EOL date to avoid any disruption.
Running unsupported (EOL) versions violates our support terms, voids any applicable warranties, and significantly increases the risk of compliance and security vulnerabilities.
Upgrade practices and recommendations
Keeping Rocket.Chat up to date is essential for stability and security. System administrators and IT decision-makers should establish a regular upgrade process. Below are the recommended best practices for planning and executing Rocket.Chat upgrades:
Track releases and schedule updates: Monitor Rocket.Chat release announcements through official release notes and lifecycle documentation. Keep track of your release line’s support status and end-of-support date. Plan upgrades according to your release track. Teams on standard releases should upgrade well within the standard support window. Teams on LTS should plan their next upgrade before the 12-month LTS support window ends.
Review release notes: Before upgrading, read the release notes for the target version and any relevant intermediate versions. Pay attention to breaking changes, new features, deprecations, and security fixes. Release notes will also call out required manual steps such as configuration changes, migrations, or removed settings.
Backup your data: Always perform a full backup of your Rocket.Chat instance prior to any upgrade. This includes the MongoDB database, uploaded files/attachments, and any custom configuration or scripts. A current backup ensures that you can restore the previous state if something goes wrong. Verify your backups are valid and accessible.
Test in a staging environment: If possible, set up a staging or test instance of Rocket.Chat that mirrors your production environment (use a copy of your database, if feasible, and similar configuration). Perform the upgrade on the staging instance first. This allows you to catch potential issues (like compatibility problems with custom integrations, apps from the marketplace, or performance changes) in a controlled setting. For example, if you use webhooks or bots, ensure they still function after the upgrade in the test environment.
Verify client and dependency compatibility: Check the system requirements for the new version. Major releases may require updated dependencies (e.g., a newer MongoDB version or Node.js runtime). Ensure your infrastructure meets these requirements ahead of time. Also, verify that your users’ web browsers or the desktop/mobile apps are compatible with the new server version. (Rocket.Chat usually maintains backward compatibility with recent app versions, but if you lag very far behind, clients might auto-update and expect a newer server API.)
Schedule downtime or maintenance window: For production upgrades, perform the update during a planned maintenance window when user activity is low. Notify end-users in advance about the expected downtime. This helps prevent surprises and gives you uninterrupted time to perform the upgrade and initial post-upgrade checks.
Execute the upgrade: Follow the official upgrade guides for your installation method (Docker, Podman, Snap, manual, etc.). It often involves steps like downloading the new release, installing dependencies, migrating the database (if the release notes indicate), and restarting the Rocket.Chat service on the new version. Monitor the upgrade process closely for any error messages.
Post-upgrade testing: After upgrading, do a sanity check on core functionalities. Have a checklist: users can log in, send messages, upload files, notifications work, any critical integrations (LDAP, OAuth, etc.) authenticate properly, and so on. Also, ensure that background jobs (like push notifications) are operating. Check the server logs for any warnings or errors that might indicate issues to address.
Rollout to users and follow up: Once you’re satisfied that the new version is running well, inform users that the system is updated. Encourage users to update their Rocket.Chat client apps to the latest version to ensure optimal compatibility. Keep an eye on performance and user feedback in the days following the upgrade. If any unexpected bug appears, you may need to report it upstream or look for a patch release that fixes it.
Maintain regular cadence: Make upgrades a routine part of system maintenance. This prevents the scenario of having to jump multiple versions in one go (which can be more complex). By staying within supported versions, you ensure access to support and avoid the disruptions associated with EOL (as discussed above).
By following these practices, administrators can reduce downtime risk, avoid unsupported configurations, and keep Rocket.Chat secure and stable.
Additional resources:
Monitor the releases through the Rocket.Chat GitHub releases page. The Version Durability document lists the releases and the end-of-life for each release.
The detailed release notes help you understand the latest improvements so you can determine processes for your workspace updates based on your organization's needs.
Check out the Support Center for details on Rocket.Chat’s support services.
The Support Prerequisites document helps you understand the requirements your workspaces must meet to receive and maintain support from our team.