Rocket.Chat Desktop App for Electron development

What Rocket.Chat Desktop App adds around the web client

Rocket.Chat Desktop App solves the native desktop packaging problem for Rocket.Chat. The web application supplies the collaboration interface, while this repository supplies the Electron shell that runs it as an application on Windows, macOS, and Linux. The intended users include Rocket.Chat contributors working on the client shell and organizations that distribute Rocket.Chat to desktop users through their own installers.

The repository is not presented as a separate messaging server. Its `package.json` identifies it as the official macOS, Windows, and Linux desktop client, and the README states that it is built using Electron. This boundary matters during evaluation. If the requirement is to host chat infrastructure, administer workspaces, or develop the Rocket.Chat server, this is the wrong repository. If the requirement is to wrap the web client in a distributable desktop application, it is directly relevant.

Platform coverage is broad but not universal across every CPU and package format. Windows 10 and later are listed for x64, ia32, and arm64. macOS starts at version 12, with a universal package covering Intel and Apple Silicon. The Linux target is x64 on Ubuntu 22.04 or an equivalent distribution, with AppImage, deb, rpm, snap, and tar.gz outputs. These constraints should be checked before modifying build settings.

Electron entry points and webview connection

The build is based on Rollup and has three documented entry files. `src/main.ts` runs in the main Electron process and orchestrates the application. `src/rootWindow.ts` renders the root window, which is the application's main window. `src/preload.ts` runs with elevated privileges and connects the application to the webviews that render the Rocket.Chat web client.

That split is the core architectural detail. The main process manages the desktop application, the root-window code owns the visible shell, and the preload layer provides the privileged bridge between Electron and embedded Rocket.Chat views. The README does not document the full IPC protocol or every security setting, so an engineer should inspect these source files before extending the boundary.

The `src` directory is rebuilt automatically during development. A completed build places the runnable application in `app`, while Rollup compiles the source and the subsequent build check examines bundle externals. The package entry is `app/main.js`, which means distribution packaging depends on that generated application directory rather than directly starting TypeScript from `src`.

Installing Rocket.Chat Desktop App for first use

For end users, the README directs them to the Releases page or the listed app stores. The documented installation process is to launch the installer and follow its instructions. Windows also supports silent installation, which is useful for scripted deployment. The README identifies `/S` as silent mode and `/currentuser` as the default installation scope.

Windows installers accept `/S` for silent installation. The README also lists `/allusers` for installation for all users, which requires administrator access, `/currentuser` for installation only for the current user, and `/disableAutoUpdates` for disabling automatic updates. The documentation does not provide a complete executable invocation for a downloaded installer, so no command should be invented for that step.

After installation, the documented first-use path is to add a Rocket.Chat server. Without bundled defaults, the client presents its server list and connection flow.

Running Rocket.Chat Desktop App from source

Source development requires Git, Node.js 22.0.0 or later, and Yarn 4.0.2 or later. The following is the README's quick-start sequence. It clones the `dev`-branch repository, installs dependencies, and starts Rollup in watch mode.

git clone https://github.com/RocketChat/Rocket.Chat.Electron.git
cd Rocket.Chat.Electron
yarn
yarn start

The reader should see the application build begin from `src`. The `postinstall` script also installs application dependencies, clears generated directories, and applies `patch-package`. This means the install is more than fetching JavaScript packages, and missing native Electron dependencies can stop it before startup.

Linux contributors may also need system libraries. Ubuntu and Debian systems can use the documented `build-essential` and `libxss-dev` packages.

sudo apt install build-essential libxss-dev

Fedora and RHEL systems have a separate documented package set. The README does not say these packages are required on every distribution, so they are troubleshooting prerequisites rather than a universal Linux installation recipe.

sudo dnf install libX11-devel libXScrnSaver-devel gcc-c++

Bundling managed server defaults with servers.json

Rocket.Chat Desktop App supports deployment-time server defaults through `servers.json`. Located beside `package.json` in the packaged application, this file supplies entries that populate the sidebar when the client first runs or after every server has been removed.

The README gives this exact object shape:

{
  "Demo Rocket Chat": "https://demo.rocket.chat",
  "Open Rocket Chat": "https://open.rocket.chat"
}

The keys are display names and the values are server URLs. If the file is bundled, the initial connect-to-server screen is skipped. The client attempts the first defined server and should open at the login screen. Object key order determines the first entry in this example.

There is an important persistence boundary. The bundled `servers.json` is consulted only when no servers have already been added. Removing the application while preserving older preferences can prevent the defaults from appearing again. Distribution tests should therefore exercise both a clean profile and a profile that already contains a server. The README excerpt does not document management of existing preferences or a forced reset of server history.

Testing, packaging, and branch-based upgrades

The project uses Jest with the Jest electron runner. Unit test discovery is documented as covering JavaScript and TypeScript files in `src` that match `*.(spec|test).{js,ts,tsx}`. The package script runs through `xvfb-maybe`, sets one worker, forces exit, and starts Jest.

yarn test

Packaging uses `electron-builder`. The README instructs contributors to run the release command for the operating system on which the command is running, with output written to `dist`.

yarn release

That distinction limits direct local verification: one host does not automatically produce every platform's final artifact. The repository also contains dedicated build scripts for macOS, MAS, Windows, and Linux, while CI builds every platform after a release tag is pushed. Upgrade work is tied to branches. Pull requests target `dev`; `master` contains released code; and `release/X.Y.x` branches handle patch releases before merging into `master`.

The last push was on 2026-10-14, and releases 4.18.3, 4.18.2, and 4.18.1 were published on 2026-10-14, 2026-10-11, and 2026-10-09. This confirms recent code and release activity, but consumers still face an upgrade cost because the package was rewritten in TypeScript 5 and contains build configuration, patches, tests, and platform packaging. The MIT license permits use and modification under its terms, but redistribution and packaging obligations must be reviewed against the actual license text.

Where the desktop client is the wrong choice

The clearest limitation is scope. This project does not replace a Rocket.Chat server or provide workspace administration. It is the desktop shell around the web client, so organizations without an accessible Rocket.Chat deployment cannot use it as a standalone chat platform.

The client also carries Electron's native packaging and privileged-webview model. Engineers extending it must account for `main`, `rootWindow`, and `preload` responsibilities rather than treating it as a normal browser tab. The README does not describe a generic plugin API, the complete IPC surface, or a rollback mechanism for failed desktop updates, so none should be assumed.

An actual alternative is to use Rocket.Chat through a browser or managed web application. That approach avoids maintaining a native Electron shell and its per-platform installers, but it does not produce a distributable desktop package with `servers.json`, native update controls, or the documented Windows, macOS, and Linux formats. The practical choice therefore turns on whether native distribution is required, not on which option is universally better.

Editorial conclusion

Contributors and organizations standardizing on Rocket.Chat can adopt this repository when they need the official desktop client or want to package it for managed deployment. Teams should not choose it for an independently maintained Rocket.Chat client, and self-hosters should first verify their Rocket.Chat server compatibility, supported operating system, distribution format, and update policy. The first code-level check is whether the intended `servers.json` entries and target platform build settings produce the expected installer.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. RocketChat/Rocket.Chat.Electron on GitHub