Rocket.Chat: a Meteor monorepo where dependencies are patched, not just pinned

Four workspaces, one Turborepo, and a branch ahead of the tags

The server is a monorepo, and package.json says so directly: the name is rocket.chat, the description is Rocket.Chat Monorepo, and it is marked private. Four workspace globs make up the tree:

	"license": "MIT",
	"author": "",
	"main": "index.js",
	"workspaces": [
		"apps/*",
		"packages/*",
		"ee/apps/*",
		"ee/packages/*"
	],

apps/, packages/, ee/apps/ and ee/packages/ means the community code and the enterprise code build in the same dependency graph and the same pipeline, which is why ee/ shows up twice in the workspace list. The version in the manifest is 8.10.0-develop on a default branch called develop, while the three most recent tags are all release candidates for 8.9.0, 8.9.0-rc.0 and 8.9.0-rc.1 on 2026-09-23 and 8.9.0-rc.2 on 2026-09-28.

Read that as a rule for cloning. A default clone gives you the development line, not a release, and the repository's own dev script is filtered to the one app that matters:

	"scripts": {
		"build": "turbo run build",
		"dev": "turbo run dev --env-mode=loose --parallel [email protected]/meteor...",
		"dev:next": "yarn workspace @rocket.chat/meteor dev:next",
		"dsv": "turbo run dsv --env-mode=loose [email protected]/meteor...",
		"ms": "turbo run ms --env-mode=loose",
		"fossify": "TS_NODE_COMPILER_OPTIONS='{\"module\": \"commonjs\"}' ts-node scripts/fossify.ts",
		"lint": "turbo run lint",

If you want the released server, pick a tag deliberately.

Yarn patches replace two packages outright and force postcss everywhere

The dependency section is the part that tells you what kind of codebase this is. The tree carries .yarn/, .yarnrc.yml and yarn.lock, so this is Yarn with patches, and two dependencies are not versions but replacements:

	"resolutions": {
		"file-type@npm:^16.5.4": "patch:file-type@npm%3A16.5.4#~/.yarn/patches/file-type-npm-16.5.4-d653e66a40.patch",
		"image-size@npm:^1.2.1": "patch:image-size@npm%3A1.2.1#~/.yarn/patches/image-size-npm-1.2.1-e285f3c080.patch",
		"browserslist": "^4.28.7",
		"postcss-svgo/svgo": "4.1.0",

A patch is a file inside the repository, referenced by a path under ~/.yarn/patches, so file-type and image-size are edited source rather than upstream versions. Behind that sits a wall of forced versions: postcss is pinned to 8.5.26 for @vue/compiler-sfc, css-loader, resolve-url-loader, sanitize-html, vite, stylelint, stylelint-order, stylelint-selector-bem-pattern and postcss-svgo alike, and external-editor/tmp is held at 0.2.7.

The consequence is a real maintenance cost. A security release for postcss is not a one-line bump here; it becomes a patch or a coordinated set of resolutions, and any fork inherits the same constraint set. That is a reasonable price for a reproducible build and a poor one if you need to track upstream quickly.

Four deployment paths, and each one hands you a different job

The README splits deployment by who operates what. On your own servers the recommended methods are Docker, Podman or Kubernetes, and it tells you to check the system requirements before you deploy rather than after. Launchpad is offered for a quick Kubernetes setup where you do not manage each dependency. An air-gapped workspace is a separate path for isolated networks that must run without internet access. Premium dedicated cloud hosting exists for teams that want a hosted solution without handling infrastructure, and native federation covers the decentralised case, letting workspaces communicate across a federated network.

Each option moves a different cost. Docker or Podman leaves you with the container runtime and the upgrade. Kubernetes leaves you with a cluster, and Launchpad with the platform's own opinions about it. Air-gapped leaves you with change control, because a workspace with no internet access cannot fetch anything new, so the apps you rely on have to be staged before the network is cut. Federation adds a trust model on top of a chat deployment.

The system requirements check is the step people skip. A workspace that under-provisions its database or its memory will not tell you which component was wrong.

A FIPS compose file and a devcontainer show up as files, not promises

Compliance claims are easy to make and easy to fake, so it is worth looking at what the tree actually contains. At the root there are three compose files: docker-compose-local.yml for local work, docker-compose-ci.yml for continuous integration, and docker-compose-ci.fips.yml for a FIPS variant of the same CI environment. There is also app.json, the manifest shape used by platform-as-a-service deployers, and two ways of getting a prepared development environment, a .devcontainer/ directory and a .gitpod/ directory.

The FIPS compose file is the informative one. It means the test matrix includes a FIPS configuration, which is a different claim from saying the product is compliant, and it is the kind of thing you can check for yourself before you sign anything.

For a contributor, the three environment routes are a real choice with a real cost. A devcontainer gives one setup, Gitpod gives a hosted one, and docker-compose-local.yml gives the most control and the most maintenance. The developer documentation splits the rest by target, with separate guides for the server on Linux distributions, Windows and Mac, for the desktop app, and for the mobile app including push notification configuration.

Desktop and mobile ship from other repositories on their own cadence

The client applications are not built from this repository. The desktop app is Rocket.Chat.Electron, the mobile app is Rocket.Chat.ReactNative, and the README treats both as separate projects you can follow and contribute to, each with its own setup guide.

Distribution is a second split. The mobile app comes from the Apple App Store and Google Play, the desktop app from the Mac App Store, the Microsoft Store, and Snapcraft for Linux, where the README gives a single command:

sudo snap install rocketchat-desktop

Two consequences. A change to the web client reaches users on their own schedule, since each store applies its own review and rollout. And on Linux, installing from Snapcraft means the desktop client's updates arrive through the Snap store rather than from this repository's releases, so a support question about a Linux desktop version has two variables in it: the server version and the snap revision.

None of this is a criticism of the arrangement, which is the normal shape for a platform with native clients. It is a scheduling fact to put in your rollout plan before a server upgrade, not after.

Apps-Engine is the extension unit, and the Marketplace needs a network

Extension happens through an app framework rather than by dropping files into the server. The README points to an open-source Apps-Engine framework for building your own integrated apps, public apps in the Rocket.Chat Marketplace, and integration with external systems. Developer documentation and API documentation live on separate developer subdomains from the user and administrator guides.

The Marketplace is the part with a deployment consequence. An air-gapped workspace has no internet access, so public apps have to be obtained and staged before isolation, and an organisation that standardises on a few apps has to include them in whatever internal distribution process it already runs. If your integration is written with Apps-Engine, the same code should work in either deployment, which is worth knowing when you decide how tightly to couple it.

Feature work has its own front door. Feature requests are tracked in the separate RocketChat/feature-requests repository, and the historical archive of older requests, up to 2018, lives in the feature request forums rather than in the tracker.

MIT in the manifest, a liability note in the tree, and hosting that is sold

The licence picture needs two questions kept apart. package.json records the licence as MIT and a LICENSE file sits at the root. Alongside them the tree carries LIMITATION_OF_RESPONSIBILITY.md, SECURITY.md, CODE_OF_CONDUCT.md and a file called VIP Sponsors.md, and the enterprise code is a separate workspace under ee/.

The commercial side is separate from the code. The README sells premium dedicated cloud hosting with a service level agreement, and points at a Trust Center and a Compliance Center as the places to read about security practices, privacy commitments, compliance certifications and governance. None of that changes what the code licence says, and none of it is a substitute for reading the file at the root.

For an evaluator, the practical questions are narrow. If you self-host, you are working with the community build and the documentation, and the system requirements page is where your sizing decisions should start. If you buy hosting, you are buying a service with an SLA, and the self-hosting documentation tells you less about that arrangement than the hosting page does. If you fork, the ee/ tree and LIMITATION_OF_RESPONSIBILITY.md are the two files to read before you assume a modification is free of obligations.

The repository is not archived and its last push was on 2026-09-29, with release candidates for 8.9.0 in the same week, so the 8.x line was still settling.

Editorial conclusion

Adopt Rocket.Chat if you need a chat platform you host yourself, possibly on an isolated network, and can operate MongoDB plus the deployment you choose. Do not adopt it expecting a single repository to be the whole product, since the desktop and mobile clients live in Rocket.Chat.Electron and Rocket.Chat.ReactNative, and do not read the MIT line in package.json as covering a commercial relationship. Verify first against the system requirements page, then decide between Docker, Kubernetes and Launchpad, and check whether the enterprise code under ee/ matters to your deployment before you pin a version.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes