This guide maps workspace size to a recommended Rocket.Chat architecture. It combines the minimum hardware baselines from System Requirements with the scaling patterns from the multi-instance and microservices guides.
These are minimum baselines. Exact sizing depends on your concurrent users and workload. For premium workspaces (Commercial, Government, Defense), consult Rocket.Chat Sales for tailored recommendations.
When to scale
As concurrent users increase, latency may begin to surface. Monitor your performance metrics: a common early indicator is the Rocket.Chat Node.js process nearing 100% CPU usage while overall host CPU utilization remains low. This is expected behavior, because Node.js is single-threaded and one process cannot use multiple CPU cores effectively.
When you see this pattern, move to the next tier. Your deployment method determines the path: Docker-based deployments scale by running multiple identical instances behind a load balancer, while microservices scaling requires Kubernetes.
Pick your tier
Concurrent users | Architecture | Deployment method |
|---|---|---|
Up to 500 | Single instance, no high availability | Docker Compose or Podman |
500 and above | Multiple instances behind a load balancer, high availability | Docker Compose per server, or Kubernetes |
Above 5,000 | Microservices with per-service scaling | Kubernetes with the official Helm chart |
Up to 500 concurrent users: single instance
One Rocket.Chat instance and a MongoDB replica set on modest hardware. This matches a Starter workspace or a small paid deployment.
Rocket.Chat: 2 vCPU (3.5 to 5.0 GHz), 4 GiB memory, 20 GiB storage.
MongoDB: 2 vCPU, 4 GiB memory, 10 GiB storage, 3 replica set members (MongoDB Atlas equivalent: M30).
Follow Deploy with Docker and Docker Compose. The official compose repository includes a reverse proxy (Traefik or Nginx) for HTTPS and a monitoring stack with Prometheus, Loki, and Grafana.
Single-instance architecture (up to 500 concurrent users): one Rocket.Chat container behind a reverse proxy, backed by a three-member MongoDB replica set, with the bundled monitoring stack.
500 or more concurrent users: multiple instances with high availability
Running multiple instances requires a premium plan.
Several Rocket.Chat instances run concurrently, connected to a shared MongoDB replica set and load-balanced through a reverse proxy such as Traefik. NATS enables inter-instance communication. Each instance handles a portion of the incoming traffic, so the workspace uses multiple CPU cores on a single host or across a cluster of hosts.
Rocket.Chat (per instance): 4 vCPU (4.0 to 5.0 GHz), 8 to 12 GiB memory, 20 GiB storage.
MongoDB: 2 vCPU, 8 to 16 GiB memory, 20 to 80 GiB storage, 3 replica set members.
Servers: one for MongoDB and monitoring, one for Traefik, and two or more for Rocket.Chat instances.
To scale vertically on one large host instead, run N−1 Rocket.Chat instances where N is the number of CPU cores. Follow Running Rocket.Chat with Multiple Instances for the full procedure, including rolling updates that keep the workspace available.
High-availability architecture (500 or more concurrent users): Traefik load-balances across two or more Rocket.Chat instances that share one MongoDB replica set, with NATS carrying inter-instance events.
Above 5,000 concurrent users: microservices on Kubernetes
Microservices scaling requires a premium plan. Rocket.Chat officially supports microservices only on Kubernetes with the official Helm chart. Direct Docker microservice deployment is not supported.
Core components (WebSocket handling, authentication, presence, authorization) run as independent services, so you can scale a single bottleneck without scaling everything.
Rocket.Chat: 16 vCPU, 12 GiB memory, 40 GB storage.
MongoDB (per replica): 4 vCPU, 16 GiB memory, 80 GB storage.
ddp-streamer: plan 1 pod per 500 concurrent users.
Start with Deploy with Kubernetes, then follow Scaling Rocket.Chat with Microservices.
Microservices architecture (above 5,000 concurrent users): each core service runs and scales independently on Kubernetes, communicating through the NATS message bus. Scale ddp-streamer pods with concurrent users.
Recommendations for every tier
File storage: Use object storage such as Amazon S3, Google Cloud Storage, or MinIO. GridFS is not recommended for production.
Database: Always run MongoDB as a replica set. Three members are strongly recommended for high availability.
Network: Expose ports 443 (HTTPS) and 80 (HTTP redirect to 443) externally. See System Requirements for details.