Rocket.Chat high availability starts with user count and a paid plan
High availability for Rocket.Chat means running more than one application instance, backed by a three-member MongoDB replica set and shared file storage. The multi-instance and microservice designs require a paid plan, so deciding whether a single server is enough starts with two questions: how many people will use Rocket.Chat at peak, and whether the business can accept an outage of the messaging service. Rocket.Chat's reference architectures suggest one instance with a MongoDB replica set for up to 500 concurrent users, load-balanced instances linked by NATS above 500, and microservices on Kubernetes with the official Helm chart above 5,000.
Treat those thresholds as guidance, not as a sizing result. Concurrent users are not the same as headcount, so count the peak number of people online at once, then add the load from bots, integrations, large file shares and mobile push activity. Confirm the design against your own environment and load profile before you buy a plan. A single application node with a healthy replica set still has the application tier as a single point of failure, so the decision should be driven by the outage your staff and operations teams can tolerate, written down as a recovery target before the architecture is chosen.
Three areas make the design harder than the reference diagram suggests. First, session state: confirm how logins, presence and session tokens are shared across instances, and what a user sees when the instance serving them fails. Second, file storage consistency: uploads must land in a store that every instance can read and write, so confirm the storage backend, its locking and replication behavior, and how partial uploads are handled. Third, MongoDB failover: a three-member replica set survives one failed member, but writes can fail or stall during an election, so confirm the driver and connection settings Rocket.Chat uses and how long reconnection takes. Check each of these against the current Rocket.Chat documentation and your vendor contracts, because the behavior changes between releases.
A design is only proven when failures have been tested under load. Plan scripted tests that stop one application instance during active traffic, force a MongoDB primary step down, and simulate loss of a node or zone. For each test, record message loss, reconnect time for users, errors in file uploads and whether integrations recover without manual action. Repeat the same tests after each Rocket.Chat upgrade and MongoDB version change, because a design that passed last quarter can behave differently after a release. Ask any implementation partner to deliver these test results as part of the written scope, not as an informal check at go-live.
Which components carry the availability design
A highly available Rocket.Chat deployment depends on five components that must work together. Each one covers a different failure, and a weak link in any of them can leave users disconnected or missing messages even when the application itself stays up.
Rocket.Chat application instances
The application runs as several instances behind one address, or as microservices on Kubernetes at larger scale. Each instance runs on Node.js, which is bundled in the official Docker image and Helm chart, so you do not install it separately. If one instance fails, users should reconnect to another, but that only works when every instance reads the same database and the same file store. Confirm that your chosen plan and deployment method support a multi-instance design before you size the cluster.
MongoDB replica set
MongoDB stores messages, users, channels and settings, so it is the component that cannot be lost. 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. With three members, the two surviving members can elect a new primary when one fails. Ask your team to confirm member placement across failure domains and how backups are taken from the set.
NATS messaging between instances
NATS carries events between application instances, so a message posted through one instance reaches users connected to another. Without it, users on different instances would miss updates. This is the component most often overlooked in capacity planning. Confirm how NATS is deployed for your version, whether it has its own redundancy, and what happens to events in flight during an instance restart.
Load balancer or ingress
The load balancer or ingress is the single entry point for browsers, desktop and mobile clients. Its health checks remove a failed instance from rotation, so users stop being routed to it. It also terminates TLS in most designs. Verify that it supports WebSocket connections and any session affinity setting required by the Rocket.Chat release you deploy, and test a forced instance stop to confirm that clients reconnect cleanly.
Shared file storage for uploads
Uploaded files and avatars must be readable from every application instance. If uploads sit on the local disk of one node, that node's failure removes attachments for all users, and a failover that moves users to another instance will show broken links. Shared storage removes that single point of loss. Ask your team which storage backends fit your plan and environment, and confirm how the storage layer itself is replicated and backed up.
Which high availability design fits the user count and team
This table compares the three high availability designs for Rocket.Chat, plus the MongoDB placement and hosting decisions that apply to all of them. Read each row against your peak concurrent users and the team that will run the platform. The main takeaway is that user count sets the minimum design, while your Kubernetes and MongoDB skills decide whether the next design up is workable.
| Design | Fits when | Operational cost | Remaining failure modes |
|---|---|---|---|
| Single instance on a MongoDB replica set | Up to 500 concurrent users per the reference architectures | Fewest moving parts and one upgrade path; staff need MongoDB replica set skills | Application host or process failure stops service until recovery; no application-level failover |
| Load-balanced instances linked by NATS on VMs or containers | Above 500 concurrent users per the reference architectures; requires a paid plan | Paid plan license; load balancer and NATS settings to maintain; upgrades must roll across all instances | Instance or NATS failure degrades traffic; confirm how sessions and failover behave in your setup |
| Microservices on Kubernetes with the official Helm chart | Above 5,000 concurrent users per the reference architectures; requires a paid plan | Kubernetes cluster, storage class and Helm skills; more monitoring surface; coordinated chart upgrades | Cluster, ingress or service-level failures; scaling individual microservices adds misconfiguration risk |
| MongoDB members across separate failure domains | All designs; three members strongly recommended for high availability | Three hosts or zones to pay for and patch; confirm inter-zone latency with your database team | Losing two members of a three-member set halts writes; one zone outage can remove quorum if members share it |
| In-house MongoDB or managed database service | Managed suits teams without MongoDB operations depth; in-house suits teams already running MongoDB | Managed: recurring service fees; in-house: staff time for backups, upgrades and failover tests | Managed failover and maintenance windows follow the provider; confirm replica set and MongoDB 8.0 support first |
How to build the cluster in order
This sequence takes an empty set of servers to a Rocket.Chat deployment where several application instances share one MongoDB replica set, shared file storage and NATS, with TLS on every hop. Each step ends with a check you can run before moving on, so a fault found early is cheaper to fix than one found during cutover.
Confirm the plan, version and architecture
Before any infrastructure is built, the platform owner confirms the Rocket.Chat plan, because multi-instance and microservice designs require a paid plan, and confirms the target release line against the version durability documentation so it sits inside a supported window. The team also confirms the MongoDB version required by that release line, which for Rocket.Chat 8.x is MongoDB 8.0 or later. Output: a written record of the plan, the exact Rocket.Chat version, the MongoDB version and the expected concurrent user count, which determines whether a multi-instance design is needed at all.
Provision the three-member MongoDB replica set
The infrastructure team provisions three MongoDB members, each on a host that sits in a separate failure domain such as a different availability zone, rack or data center, and initiates them as one replica set. Confirm the member count and placement with your database and platform leads before provisioning, since the placement decides what survives a single failure. Check: run rs.status on any member and confirm one PRIMARY and two SECONDARY members, all reporting healthy, before going further.
Enable authentication and test failover
Create administrative and application users, enable authorization on all three members, and restrict network access so that only the Rocket.Chat hosts and administrators can reach the database ports. Then test the replica set by stepping down the current primary in a maintenance window and confirming that one of the remaining members is elected. Check: a connection without credentials is refused, rs.status shows a new primary after the step-down, and the old primary rejoins as a secondary once it recovers.
Provision shared file storage for uploads
Provision file storage that every Rocket.Chat instance can reach at the same time, using the storage option your chosen release documents as supported for multi-instance deployments. Confirm the supported options and any performance or permission requirements with Rocket.Chat's documentation and your storage vendor, since storage that only one node can see will break uploads on the others. Check: upload a file through instance A, then download it through instance B by direct address, and confirm the content matches.
Deploy two or more instances on shared services
Deploy at least two Rocket.Chat instances, or the Helm microservices if you are running on Kubernetes, and point every instance at the same MongoDB replica set connection string and the same NATS deployment. Keep instance configuration identical apart from host names, and confirm that all instances report the same Rocket.Chat version. Check: the health or status endpoint documented for your release answers successfully from each instance when it is called directly, and a message sent from one instance appears on a client connected to another.
Place the load balancer or ingress with session routing
Place a load balancer or Kubernetes ingress in front of the instances and configure the routing behavior your Rocket.Chat release requires. Some releases depend on session-aware or sticky routing for real-time connections, and others do not, so confirm the requirement for your exact version in the official documentation rather than assuming it. Check: repeated requests through the front end succeed across all instances, real-time message delivery keeps working through the balancer, and a reconnect after a single instance is stopped completes without users being logged out.
Enable TLS on every connection
Issue and install certificates so that clients connect over TLS to the load balancer, and enable encryption between the load balancer and each instance, plus between the instances and MongoDB and NATS where your design supports it. Confirm the certificate chain with your security team and check that the mobile and desktop clients accept it without manual trust changes. Check: a scan of the public endpoint shows a valid chain and no plaintext listener, each internal hop connects with TLS enabled, and a desktop and a mobile client both sign in and send messages.
How to prove failover works before go-live
A Rocket.Chat high availability design is only proven once each failure has been staged on purpose, observed and recorded before users depend on it. Build the test plan from the failure modes in your own topology: the MongoDB replica set, the load-balanced instances or Kubernetes microservice pods, NATS and the file storage backend. Run the full plan first in a staging copy that matches production in replica set size, instance count, NATS layout and storage design, then repeat the critical cases in production during an agreed window. Give each test a named owner, a start condition, the log line or metric that proves success and a rollback step. Keep monitoring open during every test so the evidence comes from the platform, not from memory.
Start with the database. Stop the MongoDB primary in the three-member replica set and confirm that the remaining members hold an election and report a new primary. Check the replica set status output and the Rocket.Chat application logs to see how long the election took and how long users saw errors. Then stop one Rocket.Chat instance, or one microservice pod on Kubernetes, while test accounts hold active sessions and an active call. Confirm that the load balancer or ingress stops routing to the failed unit, that affected users reconnect to a surviving unit without signing in again, and that their channel memberships and unread state are intact afterward.
Next, break and restore NATS connectivity between instances. Block traffic to one NATS node, then watch presence, typing indicators and live message delivery across instances. Record which behavior your design produces while NATS is unreachable, because that decides what users see and what the business has to accept. Restore the connection and confirm that delivery recovers without a restart. Then simulate loss of a file storage node. Upload and download test files before, during and after the outage. Confirm that files on the surviving path stay available and that uploads during the outage fail with a clear error rather than appearing to succeed. Verify the exact behavior for your storage backend with its vendor and with Rocket.Chat's documentation.
The most important check is data integrity. Send a numbered sequence of test messages from several accounts before, during and after each failure, then compare what each recipient received against the sent log. Gaps point to lost messages, and repeated entries point to duplication. Check message order within a channel as well. Before testing begins, agree with the business owner how long reconnection may take and what interruption is acceptable for chat, calls and file sharing. Those limits belong to the business. Set the pass criteria from them, not from whatever the system happens to do on the day of the test.
Write every result into the handover record: test ID, date, environment, the exact fault injected, observed timings, pass or fail, and a named follow-up owner for each failure. Keep raw logs and monitoring exports beside the summary so an auditor or the next operator can check the claim. Repeat the suite after any Rocket.Chat upgrade, MongoDB version change or topology change, because a failover path that passed on one release can behave differently on the next. Ask your operations team which of these steps they can run alone during an incident, and record that as well.
How the design changes between VMs, Kubernetes and air-gapped networks
Running several identical instances on virtual machines or containers keeps the same application code on each node, with a load balancer in front. Rocket.Chat's reference architectures place this design above 500 concurrent users, and it requires a paid plan. Every instance must reach the same MongoDB replica set and the same file storage, and the instances must share real-time messages through NATS.
- NATS linkage: instances publish and receive messages through NATS, so a message posted on one instance reaches users connected to another. Confirm how the NATS server is deployed and whether it needs its own redundancy.
- Sticky routing: decide whether the load balancer keeps each client on one instance. Test long-lived connections during instance restarts before you choose a method.
- Shared storage mount: every instance mounts the same file storage path, so an upload made on one node opens on all others. Use a storage type that supports concurrent access from several hosts.
- Stateful dependencies: the MongoDB replica set stays outside the application instances, with three members on separate hosts.
Verify failover by stopping one instance during an active session and confirming that messages, file downloads and presence still work. Ask Rocket.Chat which NATS and load balancer settings its current version expects, and ask your platform owner which file storage option meets the concurrency requirement.
The official Helm chart runs Rocket.Chat as separate services, so each component can be scaled, restarted and upgraded independently. Rocket.Chat's reference architectures place microservices on Kubernetes above 5,000 concurrent users, and the design requires a paid plan. Most of the work sits in the cluster platform, so storage, database placement and scaling choices carry more weight than they do in a virtual machine design.
- Storage classes: each persistent volume needs a storage class that matches its access pattern and backup method. Confirm the access modes the chart version requires.
- MongoDB placement: if MongoDB runs in the cluster, spread the three replica members across separate nodes or zones, and protect them from voluntary evictions during node maintenance. Confirm whether your database is hosted in the cluster or outside it.
- Scaling the streamer and other services: scale the ddp-streamer and other microservices from load test results, not from user counts alone. Set their replica counts through chart values, and record each change.
- Upgrade practice: chart and image versions move with Rocket.Chat releases. Test each chart upgrade in a staging cluster before production.
Verify node drains, a single node failure and a rolling upgrade while a load test runs. Ask Rocket.Chat which Kubernetes versions and chart values its current release supports, and ask your cluster owner which storage classes and node pools are approved for database workloads.
In an air-gapped network, the servers or cluster have no route to the internet, so Rocket.Chat cannot pull images, updates or cloud services at runtime. Air-gapped deployment is a paid-plan capability and is not available on the Starter plan. The high availability design still applies, but every image, chart, dependency and update must cross the gap through an approved transfer process.
- Image and update transfer: container images, chart packages and release files move through an approved transfer method into an internal registry or repository. Keep a dated record of each transfer and the version it contains.
- Lack of cloud services: the push notification gateway, Marketplace and Omnichannel integrations depend on cloud services that cannot be reached from an isolated network. Confirm which mobile notification path your users will have.
- Internal replica set and storage: MongoDB, NATS and file storage all stay inside the isolated network, so backups and replica member placement must be planned internally.
- Update lead time: because each update crosses the gap, schedule transfers well before a version reaches end of life, since unsupported versions lose security fixes.
Verify a full restore from backup and a failover of one application instance inside the isolated network, with no outbound connections permitted during the test. Ask Rocket.Chat in writing which features need outbound connectivity and what transfer process it expects for images and updates, and ask your network owner which transfer route and approval steps apply.
What drives the effort and cost of a high availability build
This table lists the drivers that change how much work a Rocket.Chat high availability build takes and what it costs to run. Read each row as a question to answer during scoping: the first column names the driver, the middle column explains why it matters, and the last column shows how to keep it under control. The main takeaway is that peak concurrent users, environment count and identity integration are usually the first items to pin down in a written scope.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Concurrent users | Reference architectures move from one instance with a replica set to load-balanced instances above 500 concurrent users, and to Kubernetes above 5,000. | Size to measured peak concurrent users, not total headcount, and confirm which band that peak falls in before choosing the design. |
| Number of environments | Production, staging and disaster recovery each need their own replica set, file storage, backups and monitoring, which multiplies build and run work. | Scope a smaller staging replica set only where the test plan allows it. Put the environment list in the written scope. |
| MongoDB data volume | Message history and logs grow storage on every replica set member and lengthen initial sync and restore tests. | Agree retention settings before go-live. Confirm the backup window and restore test size with the data owner. |
| File storage | Uploaded files sit on shared storage that every instance must reach, so storage choice and throughput shape the whole design. | Estimate upload volume and file retention with the business owner. Choose shared storage the team can back up and restore. |
| Integrations that depend on uptime | Webhooks, bots and business systems that post into Rocket.Chat need their failover behavior tested, not just the server. | Inventory each integration and its tolerance for downtime. Test failover with each integration running against the cluster. |
| Identity provider complexity | LDAP or Active Directory sync, SAML group mapping and MFA each add configuration and test cases that apply across all nodes. | Document group-to-role mapping before the build. Confirm which identity features your plan includes. |
| Compliance evidence requirements | Assessors often ask for failover test records, restore results and audit trail settings, collected for each environment. | Agree the evidence list at scoping. Independent auditors, not the implementer, decide whether the evidence is sufficient. |
| Customization of the deployment | Private apps, custom branding and unusual integrations add code to maintain and retest on every Rocket.Chat upgrade. | Limit custom code to what the business needs. Plan app and integration tests into each upgrade window. |
Securing the cluster without breaking failover
Each control below protects a different part of the cluster, and each one can stop failover if it is applied without checking the others. Member authentication, network paths, certificates and secret handling must all work for MongoDB elections, NATS messaging and instance restarts to succeed. Confirm the order of changes with your platform team before applying them to a running system.
MongoDB authentication and member trust
Enable authentication on the three-member MongoDB replica set and secure member-to-member traffic with a keyfile or certificates. Without this, any host that can reach the set may be able to join it or read its data. If the keyfile differs between members or a certificate expires, members cannot hold elections, and the primary may fail to recover. Confirm which method your platform team uses, who rotates the key or certificate, and whether a rotation is rehearsed on a non-production replica set first.
Network isolation for the database and NATS
Allow only Rocket.Chat instances to reach MongoDB and NATS, and block other workloads, user subnets and the internet from those ports. Rocket.Chat instances rely on both services to share state and messages, so a rule that is too strict breaks instance-to-instance communication, and a rule that is too loose exposes the data tier. Confirm the exact ports and source groups for each tier with your network team, and test a failover after every firewall or security group change.
TLS on the load balancer and between components
Terminate TLS at the load balancer with certificates your users trust, and decide whether traffic between the load balancer, Rocket.Chat instances, MongoDB and NATS is also encrypted. Mixed configurations are common in clusters. An instance that rejects a certificate chain can drop out of rotation while the others stay healthy, which hides the fault until load rises. Confirm certificate chains, expiry monitoring and which internal hops use TLS, and check the health endpoint after each change.
Secrets stored outside configuration files
Keep database credentials, replica set key material, OAuth and LDAP bind secrets, and storage keys in a secrets manager or the orchestrator's secret store. Do not place them in environment files committed to source control or in plain configuration files. Each Rocket.Chat instance needs the same values at startup, so a secret updated on one instance but not the others causes intermittent login or database errors after a restart. Confirm where each secret lives, how instances receive it, and how a rotation reaches every instance.
Shared file storage access
Rocket.Chat instances must read and write uploaded files from shared storage, so every instance needs the same storage path or bucket with matching permissions. Storage that is open to users or to unrelated applications exposes uploads. A permission error on one node causes upload failures only for users routed to that instance, which makes the fault hard to trace. Confirm the storage type with your platform team, the identity each instance uses to access it, and whether access is limited to the Rocket.Chat service accounts.
Administrative access to failover runbooks
Limit who can run failover, restart members, change replica set configuration or edit load balancer pools, and keep those steps in a runbook with named approvers. Shared or unrecorded administrative accounts make it hard to tell whether a failover was planned or whether someone changed the topology without approval. Confirm who holds each role, whether those roles require multi-factor authentication, how actions are logged, and when the runbook was last tested against the Rocket.Chat release you run.
What to monitor, back up and document after the cluster is live
The cluster is not finished when the first failover test passes. Handover should leave the operations team with monitoring for each layer, backups they have restored at least once, and a runbook that names who acts at each step. Start with the replica set. Watch MongoDB replica set health, replication lag between the three members and election events, because an election that nobody saw is often the first sign of a flapping primary or a network problem between members. Alert on any member that drops out of the set, and confirm the alert reaches a person who can act on it during off-hours.
Next, monitor the application tier. Track instance and pod health for each Rocket.Chat instance or Kubernetes pod, including restarts, failed readiness checks and memory growth. Watch NATS connectivity between instances, since a broken message bus can make the workspace look healthy in a browser while real-time delivery fails for some users. Add load balancer error rates, especially upstream timeouts and connection resets, and file storage capacity on the shared volume. Ask your team to confirm which of these signals their existing tooling already collects and which need new dashboards or alert rules.
Backups need two separate paths. Back up the data of all three MongoDB members, not only the primary, so that a restore does not depend on which member happened to be healthy on the night of the backup. The shared file storage used for uploads needs its own backup schedule and retention, and the two backups must be taken close enough together that messages and the files they reference can be restored to a consistent point. The restore path matters more than the backup job. Run a restore into a separate environment on a schedule, measure how long it takes, and record what had to be done by hand.
Write the runbook as a table of failover steps, each with a named owner, a trigger, a verification command or dashboard check, and a rollback decision. Include who can declare an incident, who approves a manual failover of MongoDB and who confirms that clients have reconnected. Pair the runbook with an upgrade plan. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and after end of life a version gets no security or bug fixes. Upgrades for each Rocket.Chat instance and for MongoDB must be planned together, because version pairs that were tested together may not be tested apart. Unsupported versions can also lose the ability to connect with the official mobile and desktop clients, so the calendar for upgrades should be owned and reviewed, not left to whoever notices first.
Questions teams ask before building Rocket.Chat high availability
Is a single Rocket.Chat instance enough for our number of users?
A single instance can be enough at smaller scale, but the answer depends on concurrent users, not total headcount. Rocket.Chat's reference architectures suggest one instance backed by a MongoDB replica set for up to 500 concurrent users, and multiple load-balanced instances linked by NATS above that level. Above 5,000, the reference architectures point to microservices on Kubernetes with the official Helm chart. Measure your peak concurrent sessions, message volume, file sharing and integrations, because those push load as well. Treat the thresholds as a starting point and confirm the sizing against your own usage pattern before you commit to a design.
Does high availability in Rocket.Chat require a paid plan?
Yes, the multi-instance and microservice designs require a paid plan. The free Starter and Community tiers cover single-deployment use within their user limits, but load-balanced instances and Kubernetes microservices fall under the Commercial, Government or Defense plans. Rocket.Chat lists built-in redundancy with automated failover as a paid-plan feature. Confirm the exact plan that matches your user count, deployment model and any air-gapped requirement with Rocket.Chat before you finalize the budget, since paid plans are priced by quote.
How long does a Rocket.Chat high availability build take?
The duration depends on the scope you agree in writing, and no fixed timeline applies to every environment. The main drivers are the number of Rocket.Chat instances or microservices, whether you run on Docker or Kubernetes, the MongoDB replica set build and its backup design, the identity integration, shared file storage, TLS and reverse proxy setup, and the number of failover scenarios to test. Existing infrastructure such as a Kubernetes cluster, storage classes and monitoring reduces the effort. Ask for a scoped plan that lists each phase and its exit criteria.
What does the high availability build need from our own team?
Expect to supply people who can approve access and make infrastructure decisions. Typically this includes a platform or infrastructure owner for the target network, cloud or data center accounts, a DNS and certificate contact, an identity administrator for LDAP, Active Directory or SAML settings, and a storage owner for shared files. Security or compliance staff should review the design and the evidence produced. Agree on these contacts in the scope so that approvals do not delay the build, and confirm who receives the runbooks and alerts after handover.
Can our own engineers build Rocket.Chat high availability without a partner?
Yes, if your team already runs MongoDB replica sets, container platforms, reverse proxies and identity integrations. The work is well documented, but it has several moving parts that fail in combination, such as replica set elections, NATS connectivity, sticky sessions and shared file storage. Be realistic about the skills gap and the time your engineers can give the project alongside operations. Many teams split the work, keeping ownership of the platform while a partner handles the design review, the build sequence and the failover tests.
How do you test failover for a Rocket.Chat high availability setup?
Failover is tested by deliberately causing failures and checking that users, data and integrations keep working within the limits you agreed. Typical tests include stopping one Rocket.Chat instance under load, stopping the primary MongoDB member and confirming the election, restarting NATS and the reverse proxy, and losing a node or storage path. For each test, record the expected behavior, the observed user impact, message and file integrity, and recovery steps. Repeat the tests after upgrades, because a version change can alter behavior.
What do we receive at handover from a high availability build?
A complete handover should let your team operate the system without the builder present. Ask for the architecture diagram, the configuration and infrastructure as code, the MongoDB replica set and backup procedures, the failover test plan with recorded results, monitoring and alert definitions, the upgrade procedure, and a runbook for common incidents. Confirm in writing which items are included in the fixed scope, which are optional, and how knowledge transfer sessions are delivered. Ongoing support, upgrades and continuous testing are available as separate retainers.
How DeployOpen scopes, builds and hands over a Rocket.Chat cluster
DeployOpen plans, implements, tests, documents and supports self-hosted Rocket.Chat inside your own cloud accounts, data centers or air-gapped networks. For high availability, we start from a written scope that matches your user count and architecture, then build and verify the cluster in your environment before handing it over.
How we scope
- Engagements are fixed-scope, with the cluster design, deliverables and timeline agreed in writing before work starts.
- We confirm your concurrent user count to choose between load-balanced instances and a Kubernetes microservice design.
- We confirm the plan tier needed for multi-instance or microservice designs, since those designs require a paid plan.
How we build
- We deploy a three-member MongoDB replica set on MongoDB 8.0 or later, with members placed to survive a single node failure.
- We configure multiple Rocket.Chat instances linked through NATS, with shared file storage and a reverse proxy in front.
- We run failover tests, such as stopping an instance or a MongoDB member, and record how sessions and file uploads behave.
How we hand over
- You receive architecture documentation, configuration records, runbooks for failover and restore, and the test results.
- We walk your platform and security teams through daily checks, backup restore steps and the upgrade path for the cluster.
- We agree on the handover acceptance criteria in the written scope, so both sides know when the work is complete.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering failover retests after changes.
- Upgrades are planned around Rocket.Chat's standard and LTS support windows, with apps and integrations retested first.
- Your team keeps control of the environment, and we document every change so the cluster remains operable without us.
