--- title: "Scaling Rocket.Chat with Microservices" slug: "microservices" description: "Explore Rocket Chat microservices to boost secure communication and performance. Scale collaboration with flexible architecture and reliable deployment." tags: ["Enterprise"] updated: 2026-10-21T15:42:12Z published: 2026-10-21T15:42:12Z canonical: "docs.rocket.chat/microservices" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.rocket.chat/llms.txt > Use this file to discover all available pages before exploring further. # Scaling Rocket.Chat with Microservices ![](https://cdn.us.document360.io/6ae79a05-7252-45d0-96e8-8f375e07b1b2/Images/Documentation/Premium(1).svg) In a monolithic deployment, Rocket.Chat runs as a single application process where all core components (WebSocket handling, authentication, presence, etc) operate together. This model is straightforward to deploy and manage at a small scale. However, as usage grows, resource contention becomes a concern. When one component experiences heavy load, it can impact the performance of the entire application. In a microservices architecture, these core components are separated into independent services. Each service runs in its own container and can be scaled, updated, or restarted without affecting the others. For example, if WebSocket connections become a bottleneck, you can scale only the WebSocket service while leaving authentication, presence, and other services unchanged. This approach provides better resource isolation and more controlled scaling at larger workloads. > [!NOTE] > Rocket.Chat officially supports deploying microservices using [Kubernetes](https://kubernetes.io/) with the [official Helm chart](https://github.com/RocketChat/helm-charts/tree/master/rocketchat). Direct Docker microservice deployment is not supported. In this guide, you’ll learn: - [When you should scale with microservices](/v1/docs/microservices#when-you-should-scale-with-microservices) - [The key components of the Rocket.Chat microservice architecture](/v1/docs/microservices#key-components-of-rocketchat-microservices) - [Step-by-step instructions for scaling your existing Rocket.Chat workspace with microservices](/v1/docs/microservices#scaling-your-rocketchat-workspace-with-microservices) ## When you should scale with microservices Consider scaling up your workspace if: - You’re seeing performance degradation during peak usage. - You need high availability. - You want to scale individual bottlenecks (e.g., WebSocket connections) without scaling everything. --- ## Key components of Rocket.Chat microservices Rocket.Chat’s microservices architecture includes several components, each focused on a specific feature. These components work together to create a fully operational workspace. | Component | Description | | --- | --- | | authorization (`rocketchat/authorization-service`) | Manages role and permission validation, ensuring users only access what they’re authorized to. | | accounts (`rocketchat/accounts-service`) | Handles user account management and login authentication. | | presence (`rocketchat/presence-service`) | Tracks and manages [user presence status](/v1/docs/user-status) across the workspace. | | ddp-streamer (`rocketchat/ddp-streamer-service`) | Handles all WebSocket connections using the Distributed Data Protocol (DDP). | | nats (`docker.io/nats`) | A high-performance messaging system that acts as a central message bus for all microservices. Instead of services communicating directly with each other, requests are routed through NATS, which forwards them to the correct destination. To learn more about NATS, see [the official documentation](https://docs.nats.io/nats-concepts/overview). | | The central Rocket.Chat monolith (`rocketchat/rocket.chat`) | In a microservice deployment, the features of each individual service are disabled within the central monolith. This allows the dedicated microservice to take over its respective function. | Rocket.Chat's microservices deployment is illustrated in the diagram below. ![Diagram of the Rocket.Chat microservices deployment](https://cdn.us.document360.io/6ae79a05-7252-45d0-96e8-8f375e07b1b2/Images/Documentation/micro.png) --- ## Scaling your Rocket.Chat workspace with microservices This guide explains how to scale an existing Rocket.Chat microservices deployment that is already running with a single replica. > [!TIP] > If you have not yet deployed Rocket.Chat on Kubernetes, start with the [Deploy with Kubernetes guide](/v1/docs/deploy-with-kubernetes). To scale your deployment, you'll need to modify the `values.yaml` file and then upgrade your Rocket.Chat deployment using Helm. For the other parameters you can set, see [Configure your deployment](/v1/docs/deploy-with-kubernetes#configure-your-deployment). ### Step 1: Configure replicas A replica is a running copy of a service. Running multiple replicas means that if one copy fails or becomes overloaded, the others continue to serve traffic. To configure replicas, choose between setting a global count for all services or specifying a count for each service individually. **Set a global replica count** Setting a global replica count is the quickest approach and works well if you want uniform scaling across your deployment. It means setting the same number of replicas for all microservices at once. To scale all services to the same number of replicas, modify the `replicaCount` in your `values.yaml` file. For example, to set two replicas for all services: ```yaml microservices:  enabled: true  # Enable microservices replicaCount: 2 ``` **Set replica for individual services** For more granular control, you can specify a unique number of replicas for each service. This is useful if certain services need to handle more load than others. Locate the microservices section in the `values.yaml` file, remove `replicaCount` and specify replicas for each service. NATS replicas are set in the top-level `nats` section: ```yaml microservices:  enabled: true  presence:    replicas: 2  ddpStreamer:    replicas: 2  account:    replicas: 2  authorization:    replicas: 2 nats:  cluster:    replicas: 2 ``` > [!NOTE] > - For the `ddp-streamer`, plan **1 pod per 500 concurrent users**. > - Remove `replicaCount` when you define replicas for each service. ### Step 2: Apply the changes 1. After saving your changes in `values.yaml`, upgrade your deployment to apply them: ```bash helm upgrade rocketchat -f values.yaml rocketchat/rocketchat -n rocketchat ``` Helm returns the release details with `STATUS: deployed`. 2. Verify the new pods: ```bash kubectl get pods -n rocketchat ``` If you set a global replica count, the list shows that number of pods for Rocket.Chat and for each microservice, all with the status `Running`. If you set replicas for individual services, each service shows the number of pods you configured for it. 3. Confirm the number of running instances in the workspace: A list of all active Rocket.Chat instances is displayed. 1. Go to **Manage** > **Workspace**. 2. Under **Deployment**, click **Instances**.