ExpressLRS Configurator turns firmware flashing into a desktop app

A desktop front end for an open source radio link

ExpressLRS Configurator is the build and configuration tool for ExpressLRS, the open source radio control link for RC applications. It is developed and maintained by ExpressLRS LLC together with the community around it.

The division of labour is what makes the project useful to understand. The firmware and the radio link live in the separate ExpressLRS repository. The Configurator is the desktop application you use to pick a target, set the options that differ per radio and module, build the firmware and flash it to the device.

The application is written in TypeScript and built as an Electron app. The repository layout says as much: src for the sources, an .erb directory holding the build configuration, a devices directory, a dependencies directory, codegen.yml, a graphql.schema.json and a release directory, plus yarn.lock and an .nvmrc for the Node version.

The audience is hobbyists and builders who own the hardware. The README is explicit that if you have hardware you want to flash, you should follow the guides on the ExpressLRS website and the FAQ linked from it, so the Configurator is one part of a documented workflow rather than the whole of it.

One installer for 64-bit Windows, Linux and Mac

Installation is a download, not a build. The project provides a standalone program for 64-bit Windows, Linux and Mac, and the installer comes from the Releases page of the GitHub repository.

There is no source build step in the README for end users, which is worth noting for a project whose repository is a TypeScript and Electron codebase. Contributors work inside the package.json scripts, where the build pipeline is visible: yarn build runs build:main and build:renderer concurrently, electron-builder produces the packaged application with yarn package, and electron-rebuild handles native modules for the release directory. The lint step is eslint with a cache, and the development entry points are yarn start, start:main, start:renderer and start:preload.

That script list is also the clearest description of the architecture. The README shows a diagram with a main process and a renderer process, and the scripts mirror it: a separate webpack configuration builds the main process and the renderer, and a preload script exists as its own target.

The release history is steady. Versions 1.8.1, 1.8.2 and 1.8.3 were published on 2026-07-13, 2026-07-14 and 2026-07-22, and the last push to the default branch was on 2026-10-20. The repository is not archived, and the licence is GPL-3.0.

macOS blocks the app until you remove the quarantine flag

The macOS section exists because of a security model change. The README explains that since macOS 10.14 Mojave and 10.15 Catalina the system shows an error saying the ExpressLRS Configurator.app cannot be opened because the developer cannot be verified.

There are two ways around it. The first is a control-click: hold the control key while clicking the application, choose Open, and then confirm in the popup. The README notes that you may have to try this twice.

The second is to strip the quarantine attribute from the terminal after installing:

sudo xattr -rd com.apple.quarantine /Applications/ExpressLRS\ Configurator.app

That command has to be run on the installed application, and it needs administrator rights because xattr is applied to a file in the Applications directory.

The deeper point is that this is not a bug in the application but a consequence of how macOS treats unsigned or unnotarised software. Any team that manages Macs with a policy against bypassing such warnings has a problem with this installer, and there is no notarised build mentioned in the README.

Linux needs udev rules and serial group membership

Linux is where the setup is longest, because the application talks to serial devices and the operating system has to permit that.

The first requirement is the udev rules for PlatformIO supported boards and devices. The latest version of the rules file comes from the platformio-core repository, and it must be placed at /etc/udev/rules.d/99-platformio-udev.rules, which is the preferred location, or at /lib/udev/rules.d/99-platformio-udev.rules, which is required on some systems the README calls broken.

The recommended way to install it pipes the download into place:

curl -fsSL https://raw.githubusercontent.com/platformio/platformio-core/master/platformio/assets/system/99-platformio-udev.rules | sudo tee /etc/udev/rules.d/99-platformio-udev.rules

Then the udev management tool has to be restarted so the rules take effect:

sudo service udev restart

or, with the systemd tools:

sudo udevadm control --reload-rules
sudo udevadm trigger

Group membership is the second step. On Ubuntu and Debian, a user who is not root has to be added to the dialout and plugdev groups:

sudo usermod -a -G dialout $USER
sudo usermod -a -G plugdev $USER

On Arch the equivalent groups are uucp and lock. These changes take effect after you log out and back in, which the README does not spell out but is how group membership works on those systems.

There is also an old distribution caveat. On Ubuntu 18.XX the default git is too old for the recent version and some system dependencies are missing, and the README points at issue 26 with a manual fix involving the gconf2 packages and a newer git from the git-core PPA.

The build pipeline: webpack targets and electron-builder

For contributors, the package.json scripts describe how the desktop application is assembled, and they are more informative than the architecture diagram.

There are three webpack targets. build:main produces the Electron main process with the production configuration, build:renderer does the same for the renderer, and build-dll creates a development DLL bundle for the renderer. All three run with Node options that disable TypeScript type stripping and use the ts-node ESM loader instead, with warnings suppressed.

Packaging is a separate step. yarn package runs the build and then electron-builder with --publish never, and electron-rebuild is available as a rebuild script that works in parallel over production, development and optional modules in the release/app directory.

The postinstall script is the part that surprises people. It runs a native dependency check script, lets electron-builder install app dependencies, builds the renderer DLL and deduplicates the yarn lockfile. So a first clone is not a single command, and a broken native module usually means the postinstall did not finish.

Development runs through yarn start, which first checks whether a port is already in use, then starts the renderer, with start:main and start:preload available for the other two targets. The presence of graphql.schema.json alongside a codegen.yml suggests the renderer talks to the main process over a typed GraphQL surface, which is a fairly involved way to structure an Electron app.

The alternative to all of this, for someone who only wants firmware, is to drive the underlying PlatformIO build directly, since the udev rules in the installation section come from platformio-core and the devices directory holds the device definitions. That path skips the graphical settings editor and the per-radio presets, and in exchange it gives you a repeatable command line and a firmware source tree you can diff.

Localisation goes through Crowdin, not pull requests

The translation policy is stated as a request rather than a rule, and it is unusual enough to be worth repeating exactly: do not submit pull requests for translation changes.

The reason is stated just after it. ExpressLRS Configurator has been translated into several languages, and the application detects your system language and uses the translation if one exists, with the option to pick another language in the Settings menu. The project wants to remain accessible to pilots who are not fluent in English, and it has a team of volunteer translators.

The mechanism is Crowdin. The README points at the Crowdin project for the Configurator, where you can suggest updates to translations in a language you know, or ask to take on a new language or become a proof reader. For the second of those, the route is the Discord server and the #configurator-translation channel.

For a reviewer, this has a practical consequence. Translation changes will not arrive as pull requests against the repository, so the diff you see in a release does not tell you what changed in every language, and a bad string can reach users through the translation platform rather than through code review.

Editorial conclusion

Adopt ExpressLRS Configurator when you fly or build ExpressLRS hardware and want per-device settings and firmware flashing without working through a build toolchain, and when your platform is 64-bit Windows, Linux or Mac. Do not adopt it for other radio link firmware, for 32-bit systems, or for an airframe where the quarantine override and udev rules are unacceptable in your environment. Before you commit, check the release page for a build that matches your radio and its target, read the FAQ at expresslrs.org for the flashing guides the README points to, and on Linux install the PlatformIO udev rules and restart udev first, because without those the device will not be visible to the application.

Frequently asked questions

Official sources

1. ExpressLRS/ExpressLRS-Configurator on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases