Rocket.Chat

Last reviewed Aug 26, 2026 · 867 words

The price of Rocket.Chat is MongoDB. The application itself is the closest thing to Slack you can run on your own server, with channels, threads, DMs, voice and video, and an omnichannel module that turns it into a support desk. But it is a Meteor app, which means a MongoDB replica set is mandatory, the catalogue's 2048 MB floor turns into a 4 GB machine in practice, and every major upgrade is a two-database dance. If you accept that, it is 11 years of Slack-replacement engineering, dating from 2015; if you would rather not run Mongo, Mattermost on Postgres is the lighter road.

MongoDB with a replica set, or it will not start

Rocket.Chat reads the MongoDB oplog for real-time updates, and the oplog only exists on a replica set, even a single-member one. The official compose handles this with the Bitnami image, which accepts replica-set configuration as environment variables:

services:
  rocketchat:
    image: registry.rocket.chat/rocketchat/rocket.chat:latest
    environment:
      MONGO_URL: mongodb://mongodb:27017/rocketchat?replicaSet=rs0
      MONGO_OPLOG_URL: mongodb://mongodb:27017/local?replicaSet=rs0
      ROOT_URL: https://chat.example.com
      PORT: 3000
    ports:
      - "3000:3000"
    depends_on:
      - mongodb
    restart: unless-stopped

  mongodb:
    image: bitnami/mongodb:latest   # use the exact image/tag from Rocket.Chat's current official compose file
    environment:
      MONGODB_REPLICA_SET_MODE: primary
      MONGODB_REPLICA_SET_NAME: rs0
      MONGODB_ADVERTISED_HOSTNAME: mongodb
      ALLOW_EMPTY_PASSWORD: "yes"
    volumes:
      - ./mongo:/bitnami/mongodb
    restart: unless-stopped

ROOT_URL must be the public HTTPS address from the first boot. It is baked into every link, avatar URL, and OAuth callback, and changing it later leaves a trail of broken references. Put Caddy or another proxy in front for TLS and make sure websockets pass through; without them the client falls back to long-polling and the whole app feels 2 seconds late.

Upgrade Mongo one major at a time, and check the matrix first

Each Rocket.Chat release supports a specific range of MongoDB versions, and MongoDB itself refuses to jump more than one major version per upgrade. Skipping 6 months of releases can therefore mean stepping Mongo 5 to 6 to 7 with a feature-compatibility bump at each stage, before Rocket.Chat will even start. Read the supported-versions table in the release notes before every upgrade, snapshot the mongo volume, and upgrade monthly rather than annually. This is the single behaviour that separates the people with 5-year-old Rocket.Chat installs from the people who rebuilt from scratch.

Push notifications go through Rocket.Chat's gateway

Mobile push for the official iOS and Android apps is relayed through Rocket.Chat's own gateway, which requires registering your workspace with their cloud during setup. Registration is free, but the community tier caps monthly push volume (10,000 pushes a month at last check), and a busy 30-person team can hit that. The alternative is building your own mobile app with your own push certificates, which almost nobody does. Register the workspace, watch the counter in Administration, and decide early whether the paid tier is cheaper than the argument you will have when notifications stop mid-month.

LDAP and OAuth are free; check before promising the rest

The community edition ships with LDAP sync and custom OAuth, so hooking it to Authentik via OIDC takes 15 minutes and gives everyone one login. Beyond that, the catalogue's "some features gated to paid plans" is the polite version: the boundary between community and enterprise features has moved several times over the years, and it includes things like read receipts, advanced LDAP group sync, and audit tooling depending on the release. Before telling your org that Rocket.Chat does X, log into a test instance and confirm X is not a greyed-out menu with an Enterprise badge. The Slack alternatives page compares how each self-hosted option draws that line.

Where the resource use goes

Idle, a fresh install sits at roughly 1 GB across Node and Mongo. Under 50 active users with file uploads and a couple of integrations, expect 2 to 3 GB and a noticeable CPU draw on a 2-core VM during search indexing. File uploads default to storing in GridFS inside MongoDB, which bloats the database and slows backups; switch the storage type to a filesystem path or S3-compatible bucket in Administration before the first big upload, not after. Voice and video calls use WebRTC in-app and work for pairs and small rooms; for real meetings, the Jitsi Meet integration is the established pattern.

What I'd do

A 4 GB, 2-vCPU VM, the compose above with a pinned Mongo 7 tag and a pinned Rocket.Chat tag instead of latest, Caddy in front with websockets, ROOT_URL set correctly on day one. Register the workspace, switch upload storage off GridFS, connect Authentik for login. Snapshot the Mongo volume nightly and upgrade on a monthly calendar reminder, one Mongo major at a time. If the team is under 20 people and nobody needs the omnichannel or app marketplace, I would run Mattermost instead and keep the operational surface to one Postgres database; the team chat category has the wider field.