When a Rocket.Chat Kubernetes Helm deployment is the right choice
A Helm deployment suits teams with cluster skills who want Rocket.Chat under their own change control, managed through the same reviews, pipelines and rollback habits they apply to other services. If your platform team cannot yet explain how the cluster handles persistent volumes, certificates and node drains, a simpler single-host deployment is the safer first step. Settle scale first, because Rocket.Chat's reference architectures tie the required topology to the number of concurrent users you expect at peak.
Rocket.Chat's reference architectures set three bands. Up to 500 concurrent users, one instance with a MongoDB replica set is the documented design. Above 500, multiple load-balanced instances linked by NATS are suggested. Above 5,000, microservices on Kubernetes using the official Helm chart are the reference design. The multi-instance and microservice designs require a paid plan. The free Starter plan allows up to 50 users, and the free Community workspace allows up to 100 concurrent users, so a small pilot can run on free terms, but it will not show how the production topology behaves under load. Ask Rocket.Chat or your partner to confirm which band your peak concurrency falls into before you commit to a chart layout.
The harder part sits beneath the chart. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is the recommended layout for high availability. Decide early whether MongoDB runs inside the cluster through an operator, as a managed service, or on dedicated virtual machines outside it. That choice shapes backups, failover behavior and network paths between the application and the database. Confirm the exact MongoDB and chart versions against the system requirements before you draft the values file, since a mismatch discovered during cutover is expensive to unwind.
Storage classes and ingress are the other decisions that are hard to reverse. Uploaded files, MongoDB volumes and any shared file store depend on the storage class's access modes, reclaim policy and snapshot support, and changing them later usually means a data migration. The ingress controller, TLS termination and WebSocket handling at the proxy determine how real-time connections behave for every user. Test these with a load profile close to what you expect in production, not only with a few test accounts, so problems surface before users depend on the service.
Upgrades close the loop. Standard Rocket.Chat releases are supported for 6 months and LTS releases for 12 months. After end of life, a version receives no security or bug fixes, cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working, and unsupported versions may lose the ability to connect with the official mobile and desktop clients. Build a recurring upgrade window into your change process, test MongoDB compatibility and your custom apps before each move, and ask any implementation partner to show how they will meet the next support cutoff.
Which Rocket.Chat and cluster components the Helm chart puts in place
The official Helm chart deploys more than the Rocket.Chat pod itself. Each component below depends on the others, so changes to one usually affect scaling, availability or upgrades elsewhere. Confirm the exact values keys against the chart version you install before you write your own overrides.
Rocket.Chat application pods
These pods run the main Rocket.Chat server, which serves the web app, the API and realtime connections for users. Their replica count and resource requests set how many concurrent sessions one release can carry. Node.js is bundled in the official Helm chart and Docker image, so your team manages the Rocket.Chat release and its values, not a separate Node runtime. Check the image tag and chart version together before every upgrade.
Optional microservices and ddp-streamer
For large deployments, the chart can split selected functions out of the main pods into separate microservices, including ddp-streamer, which handles realtime message streaming. Each service is enabled and scaled through its own values block, and each adds pods to monitor and upgrade. Rocket.Chat's reference architectures place microservices on Kubernetes above 5,000 users, and that design requires a paid plan. Confirm the enablement keys for your chart version.
MongoDB replica set
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 chart can deploy MongoDB, but many teams point it at a managed or separately operated replica set instead. Decide where the members run, how they are backed up and which storage class they use before you install, because the database is the hardest component to move later.
NATS messaging layer
NATS carries messages between Rocket.Chat instances when you run several load-balanced instances or microservices, so every instance sees the same events. It is not needed for a single-instance deployment. Reference architectures call for NATS above 500 concurrent users with multiple instances, and the design needs a paid plan. Confirm how the chart configures the NATS URL and whether it deploys NATS or expects an external broker.
Ingress controller and TLS certificate
The ingress controller routes browser, API and websocket traffic to the Rocket.Chat service, and the TLS certificate secures that path for users and mobile clients. Websocket support, request body size limits for file uploads and sticky session behavior depend on the controller you choose, so test them with your chosen ingress class. Confirm the ingress and TLS keys in the chart values, and decide who renews the certificate and how.
Persistent volumes for uploaded files
Persistent volumes hold files that users upload, so pods can restart or move without losing them. The access mode and storage class decide whether several Rocket.Chat pods can share the same files, which matters once you run more than one instance. Size the volume for expected upload volume and retention, and confirm the storage class supports the access mode your design needs. Back these volumes up on the same schedule as MongoDB so messages and their attachments stay in step.
Which Kubernetes topology and MongoDB placement to choose
This table compares the three Rocket.Chat topologies on Kubernetes and the two places to run MongoDB, so you can match the design to your concurrent user count and to the operations work your team can sustain. Read each row for when it fits, whether a paid plan applies, and what your team must run after go-live.
| Option | When it fits | Paid plan required | Operational cost your team takes on |
|---|---|---|---|
| Single instance with a MongoDB replica set | Up to about 500 concurrent users, per Rocket.Chat reference architectures; a small, simple deployment with one application workload | Not required for this design; confirm against your user count and plan limits | One application deployment to upgrade, one three-member replica set to back up and test for failover, and one ingress and TLS certificate path |
| Multiple load-balanced instances linked by NATS | Above about 500 concurrent users, per Rocket.Chat reference architectures; suits growth in user count without moving to microservices | Required; confirm the current plan tier with Rocket.Chat before design | Adds NATS to run and monitor, session handling across instances, and shared file storage to verify under failover |
| Microservices via the official Helm chart | Above about 5,000 users, per Rocket.Chat reference architectures; suits teams that need to scale components such as ddp-streamer independently | Required; confirm the current plan tier with Rocket.Chat before design | Many more workloads to version, scale and monitor, plus per-service upgrade checks in each Rocket.Chat release |
| MongoDB inside the cluster under an operator | Teams with Kubernetes platform skills who want backups, scheduled upgrades and replica set management handled through Kubernetes objects | Not applicable; MongoDB is a separate component from the Rocket.Chat plan | Your team owns operator upgrades, storage class performance, backup schedules, restore tests and failover drills inside the cluster |
| MongoDB on dedicated virtual machines or a managed service outside the cluster | Teams with an established database operations function, or policies that keep data stores outside the Kubernetes cluster | Not applicable; MongoDB is a separate component from the Rocket.Chat plan | Network paths, credentials and TLS between cluster and database, plus version upgrades coordinated with Rocket.Chat 8.x requirements; confirm backup and failover terms with the provider |
How to build the Rocket.Chat Helm deployment in order
This sequence takes one Rocket.Chat deployment from licensing decisions to a working workspace on Kubernetes. Each step closes with a check you can run, so each layer is proven before the next one is built.
Confirm the license plan and user count
Your team confirms which Rocket.Chat plan covers the expected number of users and the features the deployment needs, such as LDAP, single sign-on or multi-factor authentication. The free Starter plan allows up to 50 users, and multi-instance and microservice designs require a paid plan. Record the decision in writing before any infrastructure is created. Done when the plan, user count and enabled features appear in a signed-off design note.
Provision a three-member MongoDB replica set
Deploy MongoDB 8.0 or later as a three-member replica set, because Rocket.Chat 8.x requires a replica set and three members is the recommended layout for high availability. Enable authentication and restrict network access to the Rocket.Chat namespace, following your MongoDB operator or vendor documentation. Run rs.status() and confirm that one member reports PRIMARY and the other two report SECONDARY. Do not continue until the election completes and the set stays healthy after one member restarts.
Choose a storage class for uploads
Select a storage class that supports the access mode and performance your file uploads need. Confirm the options with your cluster administrator, since availability varies by cloud provider and data center. Create the persistent volume claim for uploads and reference it from the chart values. Check that the claim shows Bound in the output of kubectl get pvc. A claim stuck in Pending usually means the storage class or provisioner does not match the cluster, so resolve that before moving on.
Set ingress class and TLS certificate
Set the ingress class your cluster uses and attach a TLS certificate issued for the public hostname, including any intermediate certificates the chain requires. Your security team should own the certificate lifecycle and renewal process. From a machine outside the cluster, open a TLS connection to the hostname and confirm that the served chain is complete, the name matches and the certificate is valid. Done when the check passes without local trust overrides.
Install the official Helm chart from version control
Store the values file in version control, pin the chart version and the Rocket.Chat image version, and install the official chart into its own namespace. Keep secrets in your secret management tooling and out of the values file. Run the install with the values file and wait for the rollout to finish. Check that every pod reports Ready and that helm status shows the release as deployed. Keep this file as the baseline for every later upgrade.
Configure the external URL and verify endpoints
Set the external URL in the chart values and in workspace settings so links, callbacks and client redirects use the public hostname. Then test the web client in a browser and the endpoint that mobile and desktop clients use to connect. Check both: the web client loads over HTTPS without certificate warnings, and the mobile client endpoint responds to a request from outside the cluster. Confirm the exact endpoint path against the Rocket.Chat documentation for your version.
Enable microservices after the baseline passes
Turn on microservices such as ddp-streamer only after the single-deployment baseline passes every check above. Confirm that your plan covers multi-instance and microservice designs, and change one setting at a time in the version-controlled values file. Check that each new service pod reports Ready, that messages still deliver in a test channel and that the baseline checks still pass. If a check fails, roll back that single change before adding another.
How to scale ddp-streamer and other microservices on Kubernetes
Splitting Rocket.Chat into microservices on Kubernetes is a design for large workloads. Rocket.Chat's reference architectures place the microservices design with the official Helm chart above 5,000 users, and that design requires a paid plan. Before you split any service, run the single deployment long enough to collect actual usage data: peak concurrent connections, message volume, file upload activity and the times users report slowness. That baseline shows whether user load is the constraint at all. A team that splits early takes on more services to deploy, monitor, back up and upgrade, and gains little if the single deployment was never saturated. Write down the metric and threshold that would justify the change before any scaling work is scoped.
The chart separates the streaming service, ddp-streamer, from the other Rocket.Chat services so that each can run as its own deployment and be scaled independently. ddp-streamer carries the persistent real-time connections that clients keep open, so its load tracks connected users more closely than message volume. The other services handle work such as background jobs and presence-related traffic. Confirm the current list of separable services and their values keys in the chart release notes for the exact chart version you plan to deploy, and check them again before every upgrade, because the set of separable services can change between releases. Do not copy keys from older examples or blog posts into your values file.
Decide which service to scale first by reading signals from each component under normal peak load. For ddp-streamer, watch concurrent connections per pod, CPU and memory pressure, restarts and the connection count at which latency starts to rise. For the other services, watch queue depth or processing time where your monitoring exposes it, along with pod resource pressure. Then compare these against user-visible symptoms such as delayed message delivery or reconnect storms. The component whose saturation lines up with those symptoms is the one to scale first. Set thresholds from your own baseline and your monitoring stack, not from figures copied from this page or any other source, and test each change in a staging environment that carries realistic traffic patterns.
Scaling one component without checking MongoDB capacity can move the bottleneck into the database. Each additional streaming pod opens more connections and generates more reads, writes and change stream activity against the replica set, which Rocket.Chat 8.x requires to run on MongoDB 8.0 or later. Before scaling, record MongoDB connection counts, CPU, disk IOPS, oplog window and replication lag at peak. After each change, check whether those figures rise faster than user load or whether replication lag grows. Confirm with your database team and the chart documentation how connection pool sizes are set and whether the chart caps them per pod, because uncapped growth across many pods can exhaust the database's connection limit.
What drives the effort and cost of a Rocket.Chat Kubernetes project
This table lists the factors that move the effort and cost of a Rocket.Chat deployment on Kubernetes with Helm, and how to keep each one contained. Read each row as a question to settle in the scope before work starts. The main takeaway is that most cost growth comes from scope decisions made early, such as user count, environment count and whether the cluster and MongoDB already exist.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Concurrent users and plan | Reference architectures tie user count to design: one instance with a MongoDB replica set up to 500 concurrent users, multi-instance above 500, and microservices above 5,000. Multi-instance and microservice designs require a paid plan. | Confirm the peak concurrent count, not total headcount, and size the first release to the lowest design that covers it. Ask for the plan requirement in writing. |
| Number of environments | Each environment (dev, test, production) needs its own Helm values, secrets, MongoDB and upgrade test cycle, so effort grows with each one added. | Limit the first release to one production environment and a single non-production copy used for upgrade testing. Add others later as separate scope items. |
| Existing cluster and MongoDB | A new cluster and a new MongoDB replica set add platform build, node sizing and operations work. Reusing them lowers the setup scope but raises questions about shared capacity and access. | Confirm whether a cluster with suitable storage classes and a MongoDB 8.0 or later replica set already exists, and scope only the gaps. |
| Storage and backup design | Rocket.Chat keeps uploaded files and database content that need persistent volumes, backup schedules and restore tests. Storage class choice affects both performance and recovery time. | Use the storage class and backup tooling the platform team already runs. Define one restore test as a deliverable rather than an open-ended review. |
| Ingress and certificate integration | Public TLS, internal certificate authority issuance and reverse proxy rules each add configuration and testing. Mismatched certificate chains are a common cause of client connection failures. | Reuse the cluster's existing ingress controller and certificate manager. Confirm the internal PKI issuer and the mobile and desktop client trust requirements early. |
| Identity integration | LDAP or Active Directory sync, SAML or OAuth single sign-on, and group to role mapping each need directory access, test accounts and sign-off from the identity team. SSO and LDAP are listed on the Starter plan, while SAML user group mapping is a paid-plan feature. | Start with one identity method and a defined group map. Add MFA and extra providers as later items. Confirm the plan that includes each method before scoping. |
| Data import from another chat tool | Slack exports use the Slack importer, while Mattermost and other sources are converted to CSV. Identity mapping, channel mapping and large history files drive the work. | Limit the first import to active channels and a bounded history window. Treat the rest as a separate, later import job. |
| Microservices and scaling | Running ddp-streamer and other microservices adds separate workloads, scaling rules and monitoring. Each one needs its own tuning and failover checks. | Defer microservices until measured load requires them. Start with the single-instance design and document the trigger for moving to a larger design. |
| Compliance evidence | Assessors expect records of configuration, access control, backup and restore tests, and upgrade history. DeployOpen prepares this evidence, but independent auditors decide whether controls meet a framework. | Agree the evidence list before build starts, such as configuration baselines, access reviews and restore test records. Confirm which framework the auditor will assess against. |
How to verify the Helm deployment works and fails safely
Before go-live, the team should run a fixed set of acceptance tests against the Helm release, and each test should have a written expected result. A green pod status is not proof that Rocket.Chat is usable. Check that the Rocket.Chat deployment and its supporting pods reach the Ready state, then restart a pod deliberately and confirm that it rejoins without manual steps and without repeated restarts in the pod events. Repeat the same exercise for the microservices you scaled, such as the ddp-streamer, because a service can look healthy while it fails to receive real-time traffic.
The data layer needs its own tests. Stop one member of the MongoDB replica set and confirm that the set elects a new primary, that Rocket.Chat continues to send and receive messages, and that the member rejoins cleanly when it returns. Upload a file, delete the Rocket.Chat pod that served it, let Kubernetes reschedule the workload, and then download the file from a different client session. Confirm the storage class and volume claim that hold uploads are the ones your design names, because a file stored on ephemeral container storage will appear to work until the first reschedule.
Verify access from outside the cluster. Test the public hostname over TLS from a network location that is not inside the cluster, and check the certificate chain, expiry date, and hostname match with a standard client. Then connect the desktop client and the official mobile apps through the same hostname, sign in with an account from each identity source you configured, and send messages in both directions. Mobile push depends on the push gateway configuration, so confirm with Rocket.Chat and your own network team which outbound paths are required, since this is an area to verify in your environment rather than assume.
Rehearse the rollback before you need it. Upgrade the release to a newer chart or image version in a staging copy, simulate a failed rollout such as a bad image tag or a failing readiness probe, and run the Helm rollback command. Confirm that the release returns to the previous revision, that messages and uploads created before the failed upgrade are still present, and that MongoDB has not been left with an incompatible schema state. Test a MongoDB outage separately: the expected behavior is a clear error to users and a logged failure, not a message that appears sent but is never stored.
Write each check as a numbered test with the command or action, the environment, the expected result, and the evidence to keep, such as a log excerpt or screenshot. Store these records with the change ticket so that the go-live decision and any later audit can point to the same results. Ask your implementation partner or internal team to confirm the exact Helm and MongoDB versions used in the rehearsal, because the test results only apply to the versions you actually ran.
Which secrets, access and network controls the Kubernetes deployment needs
A Rocket.Chat deployment on Kubernetes holds database credentials, administrative access and user traffic, and each of these needs its own boundary. The controls below cover where credentials live, who can read them, which pods can reach MongoDB, and who can change the release. Application settings and identity are covered in the security hardening and SSO topics.
Store MongoDB credentials in cluster or external secrets
The MongoDB connection string, including its username and password, should live in a Kubernetes Secret or in an external secret store that syncs into the cluster, never in values files committed to Git. Confirm how the official Helm chart expects existing secrets to be referenced, so the chart uses your secret rather than generating one from plain values. Also record where the MongoDB root or administrative credentials are kept, separate from the application user.
Restrict namespace and service account reads
Any identity that can read a Secret in the Rocket.Chat namespace can read the database password. Limit get and list permissions on Secrets to the service account the Rocket.Chat pods run as and to a small platform group. Review whether MongoDB backup jobs, monitoring agents or other workloads in the same namespace need access, and move them to their own namespace if they do not.
Limit network paths to MongoDB
Use Kubernetes NetworkPolicy, or the equivalent in your CNI, to allow ingress to the MongoDB pods only from Rocket.Chat pods and any approved backup or replica set peers. Confirm that your cluster network plugin enforces NetworkPolicy, because a policy object that is not enforced gives no protection. Test the policy by attempting a connection from an unrelated pod in the same cluster.
Decide where TLS terminates
Ingress terminates TLS for users in most designs, but you should decide whether traffic between the ingress controller and Rocket.Chat pods, and between Rocket.Chat and MongoDB, must also be encrypted. Internal encryption adds certificate issuance and rotation work to the platform team. Record the decision in the design document, including which certificate authority issues internal certificates and how renewal is monitored.
Control who can run helm upgrade
A helm upgrade can change images, replicas, ingress rules and secret references in one command, so it is a privileged action. Restrict release permissions to named operators through RBAC on the release namespace, and require review of values changes before they merge. Keep a record of who ran each release, and confirm that rollback rights are held by the same group that can deploy.
Separate cluster and chart admin roles
Cluster administrators who manage nodes, storage classes and the ingress controller are a different group from the people who operate Rocket.Chat releases. Give the Rocket.Chat operators rights only in their namespace, and confirm with your platform team which shared components they may change. This split keeps a chart change from becoming a cluster-wide change.
What to monitor, back up, upgrade and document after go-live
The first weeks after go-live decide whether a Rocket.Chat Kubernetes deployment stays healthy, so the operating routine should be written down before users arrive. Monitoring needs to cover three layers: pod health for the Rocket.Chat deployment and its microservices, including the ddp-streamer pods that carry real-time traffic; the MongoDB replica set, where the primary, secondaries and replication lag should be visible at all times; and storage usage on both the MongoDB volumes and the file storage backing uploads. Alert on restarts, unready pods, lost replica set members and volumes approaching capacity, and confirm with your platform team which metrics the chart exposes in your cluster and which need an exporter.
Backups have two parts that must be restored together: the MongoDB database and the file storage that holds attachments and uploads. Set a schedule for each, store copies outside the cluster and in a location your retention policy allows, and encrypt them. A backup that has never been restored is an unverified assumption, so run a restore into a separate namespace on a regular cadence, confirm that messages, files and user accounts match, and record the time it took. Ask the MongoDB operator or team who owns snapshot consistency across the replica set, since a file backup taken at a different moment from the database backup can leave references pointing at missing objects.
Track Rocket.Chat release support windows as an operational input, not a calendar reminder. Standard releases are supported for 6 months and LTS releases for 12 months. After end of life a version receives no security or bug fixes, and cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Rocket.Chat also notes that unsupported versions may lose the ability to connect with the official mobile and desktop clients. Rocket.Chat 8.9.0 was published on October 5, 2026, with patch releases for older supported lines on October 16, 2026. Before each upgrade, confirm which lines are currently supported and check the MongoDB compatibility of the target release, because Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set.
Pin the Helm chart version and the Rocket.Chat image tag in version control, and deploy only from committed values files. Unpinned charts and floating image tags make it impossible to say which build is running or to roll back to a known state. Keep the values files for each environment in the same repository as the infrastructure code, and require a reviewed change for every version bump. Record the chart version, app version and MongoDB version in the change record so that an incident responder can reconstruct the stack from the repository alone.
Keep a runbook that a second engineer could follow during an incident. It should state the upgrade order (typically MongoDB compatibility checks, then the Rocket.Chat release in a staging environment, then production), the rollback path including how database changes are handled, the test steps to run after each change, and who approves changes at each risk level. Name the approvers by role, such as the platform owner for infrastructure changes and the security owner for authentication or retention changes. Review the runbook after every upgrade and after every restore test, and treat gaps found during those exercises as open items with owners and dates.
What buyers and platform teams ask before a Helm deployment
What drives the cost of a Rocket.Chat Kubernetes deployment with Helm?
Scope, the number of environments and the architecture decide most of the cost. One-time work covers cluster readiness checks, storage classes, MongoDB replica set placement, ingress and TLS, Helm values design, identity connection, testing, documentation and handover. Recurring work covers upgrades, patch cycles and any ongoing support retainer. A single instance with a MongoDB replica set is simpler than a microservices layout, which Rocket.Chat's reference architectures place above 5,000 concurrent users and which requires a paid plan. Infrastructure, MongoDB hosting and any paid Rocket.Chat plan are billed separately from the implementation work. Ask the quote to itemize each of these lines so you can see what changes if scope shifts.
How long does a Rocket.Chat Helm deployment take to complete?
Duration depends on scope, and the written statement of work sets the timeline. A single Helm release into an existing cluster with a ready MongoDB replica set moves faster than a build that adds single sign-on, a Slack or Mattermost import, staged environments and scaled microservices. The biggest variables are how quickly cluster access, storage classes and DNS are approved, how many review rounds your security team needs, and whether a test cutover window is available. DeployOpen does not publish durations. Ask for a phased plan that lists each client dependency and its owner, so delays show up early and can be managed.
What must our internal team provide before outside implementation work starts?
Your team provides the access, decisions and approvals the work depends on. Cluster access means a kubeconfig or a role scoped to the target namespace, plus approval for the storage classes and ingress controller to be used. MongoDB decisions cover where the replica set runs, the MongoDB version (Rocket.Chat 8.x requires 8.0 or later), member count, authentication, and backup ownership. Identity contacts are the people who run your LDAP, Active Directory or SAML provider. Other inputs include DNS records, the TLS certificate source, and a named sign-off approver with a change window. Confirm the owner of each item in the quote, since missing owners are a common source of schedule slippage.
Can an internal platform team deploy Rocket.Chat on Kubernetes alone?
Yes, a platform team with the right skills can do it, but the skills need to cover more than Helm. The team needs Kubernetes operations that include Helm values, storage classes, ingress and certificate management, and pod scheduling. It needs MongoDB administration for replica sets, authentication, backup and restore, and version upgrades. It also needs identity administration for LDAP, Active Directory or SAML, plus Linux and networking skills for the reverse proxy and network policies. Release testing of apps and integrations is often the gap. Before deciding, inventory these skills, and ask whether anyone has rehearsed a restore. Most teams find one or two areas to fill with a partner or training.
Can Rocket.Chat Starter or Community plans be deployed this way?
The answer depends on the plan and architecture, so confirm it with Rocket.Chat before you plan. Starter allows up to 50 users and includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts. Community allows up to 100 concurrent users with core messaging. Rocket.Chat's reference architectures reserve multi-instance and microservice designs for a paid plan, and air-gapped deployment is also a paid-plan capability. Confirm in writing whether the official Helm chart and your intended design are supported on the plan you hold. If you expect growth, ask for the paid plan price in the same quote so both paths can be compared.
What does ongoing support and upgrade work involve after go-live?
Standard Rocket.Chat releases are supported for 6 months and LTS releases for 12 months. After end of life, a version gets no security or bug fixes, cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working, and the official mobile and desktop clients may lose connectivity. Each upgrade involves reading release notes, checking MongoDB compatibility, testing apps and integrations in a non-production environment, taking a backup, and keeping a rollback path. Ongoing support can be bought as a retainer, which covers upgrades, patch monitoring and testing. Scope and price come from a quote, based on how many environments and integrations you run.
What should we check in Helm values before each Rocket.Chat upgrade?
Start by confirming that the chart version and the Rocket.Chat application version are a supported pairing. Diff the values file against the new chart defaults, and review changes to image tags, ingress annotations, storage claims and resource limits. Check that the MongoDB version meets the target release's minimum and that the replica set reports a healthy primary and secondaries. Take a backup of the database and any file storage before you apply the change. After the upgrade, run smoke tests covering login, message send, file upload, notifications and each critical integration. Keep the previous release values in version control so a rollback is a known action.
How DeployOpen scopes, builds and hands over a Rocket.Chat Kubernetes deployment
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Rocket.Chat on Kubernetes with Helm, we start from your user count, plan and availability needs, then agree the work in a written, fixed-scope document before any build begins.
How we scope
- Confirm the Rocket.Chat plan and user count first, since multi-instance and microservice designs require a paid plan.
- Record the target Kubernetes platform, storage classes, ingress controller, and where MongoDB 8.0 replica set members will run.
- Agree in writing which deliverables, environments and cutover steps are in scope, with timelines fixed before work starts.
How we build
- Install the official Rocket.Chat Helm chart with values for storage classes, ingress, TLS termination and scaling of microservices such as ddp-streamer.
- Verify the three-member MongoDB replica set, persistent volumes and failover behavior before any user traffic is routed to the cluster.
- Test the upgrade path against a staging copy so the chart version, Rocket.Chat release and MongoDB version move together.
How we hand over
- Deliver Helm values files, manifests and a runbook covering deploy, rollback, backup and restore steps in your environment.
- Document the scaling settings, monitoring points and the criteria your team should use to decide when to add capacity.
- Walk your platform and security engineers through the build and confirm they can run an upgrade without DeployOpen present.
How we support
- Offer ongoing support, upgrades and testing as a retainer if your team wants DeployOpen to keep the cluster current.
- Plan upgrades inside the 6-month standard or 12-month LTS support window so the deployment never runs an end-of-life version.
- Confirm with your team what support scope, response expectations and change process apply, as these are set in the retainer agreement.
