SeleniumHQ/selenium-ide: a recorder that stopped shipping releases in 2024

Three ways to install and only one builds from source

The README lists installation paths in order of convenience. First, prepackaged binaries published directly as GitHub releases. Second, an npm global install run through a command of the same name. Third, building manually, which is the path the contributing guide points at:

npm install -g selenium-ide

Manual building has three prerequisites: Git, NodeJS v16, and pnpm. The build itself is four steps, and the third one is the one that tells you this is a monorepo rather than a single application:

git clone https://github.com/SeleniumHQ/selenium-ide
cd selenium-ide
pnpm -r i
pnpm run build
pnpm run start

The recursive install and the top-level run commands both delegate into a workspace, so the flags are doing work a single-package project would not need. That detail matters if you are reading the build from the README and wondering why there is no webpack config at the root.

The monorepo package map and why it is shaped that way

The Architecture section explains the layout and it is unusually explicit. The codebase is JavaScript that leans on the NodeJS, Electron and React ecosystem, arranged as a monorepo, and except for the code export packages every package is fully typed with TypeScript.

The packages divide along clear lines. selenium-ide is the main Electron app, built with webpack and a React frontend, and it talks to the rest through IPC protocols. side-runtime is the playback system: it takes .side files and executes them, and both the IDE and side-runner use it. side-runner is the NodeJS task runner. side-cli is described as an experimental CLI built with React and ink. side-api is the shape of the IDE's API, kept separate so plugins can share the types with a smaller footprint. side-model holds metadata about standard commands and argument types. side-commons is the shared utilities directory. side-code-export is the NodeJS transpiler that turns .side files into other languages, with code-export- packages for the individual targets.

The split between side-api and side-model is the part to understand if you plan to write a plugin. The API is deliberately thin, and the metadata about commands and arguments lives elsewhere, so a plugin can depend on the types without pulling in the full model.

Export targets and what the recorder cannot do yet

The export story is the practical reason to use this project. The README names side-code-export as the NodeJS transpiler for .side files, and says it is used to export to other languages, naming csharp, java, javascript, python and ruby. Those become the code-export- packages, one per target format.

The What now section then lists three things still ahead, and the second and third of them overlap with what the Architecture section already describes as existing. Export to Selenium code in different languages appears as future work in one section and as a shipped transpiler with five named targets in the section above it. Reading both together, the honest conclusion is that the export path exists and its ergonomics are still being worked on, rather than that the feature is missing.

The first item on that list is the interesting one for anyone evaluating the tool. Selector accuracy is described as needing an option for ranking selectors, where the recorder collects as many attributes as possible per user event, uses the most likely properties for the selector, and falls back to the others. In other words the project itself names selector brittleness as the known weak point, and that is the failure mode that decides whether recorded scripts are maintainable.

Test infrastructure that dates from a different Selenium

The root manifest is named selenium-ide-monorepo and marked private, so nothing is published from it directly. The scripts show the shape of the test setup: a jest run for the core, separate runs for side-runner, the IDE and code-export, and a test:ci variant that starts a static server on port 8080 in the background before running anything.

The one file that dates the infrastructure is docker-compose.yml. It pins selenium/standalone-chrome-debug:3.11.0-antimony, along with an nginx service serving test fixtures and a VNC port:

services:
  selenium:
    image: "selenium/standalone-chrome-debug:3.11.0-antimony"
    ports:
      - "4444:4444"
      - "5900:5900"

The antimony build of that image belongs to the Chrome 71 era. So the test harness describes a Selenium server from before the W3C WebDriver transition was mandatory, sitting in a repository whose source was pushed in October 2026. Nothing in the README explains whether this compose file is current, historical, or what to substitute for it, which is exactly the kind of gap worth confirming before you rely on the container path.

One other artifact in the tree deserves a note: dump.rdb, a Redis dump file, is committed at the repository root. It is harmless in itself and it tells you something about how the development environment grew.

Contributor workflow details the README treats as small print

The contributing section is more useful than it looks, because it is written for someone who has already decided to work on the codebase.

For fast iteration, the README recommends a watch mode that gives near real-time rebuilding, with a change followed by a start and then testing the change. There are keyboard shortcuts for opening devtools on a page, and the React Developer Tools are pre-installed in the Electron environment. It points out that VSCode has a defined workspace structure and a run command, plus file mappings so breakpoints work across source maps for the main process. And it names the chrome dev tools at localhost:8315 as a fallback while arguing for the in-window tools since those have React Developer Tools installed.

Two details there are worth pulling out. The localhost:8315 devtools port is a debugging backdoor into the packaged app, which is a reasonable thing for a test tool to have. And the source map support for main-process breakpoints is the kind of thing that only exists because someone hit the problem, which is a good sign about the project's maturity even where other parts lag.

Support channels are the older ones: a FAQ on the wiki, the #selenium channel on IRC at freenode, and Slack via the Selenium project support page.

A 2024 beta tag against a 2026 source tree

The release history is the fact to plan around. The newest release is v4.0.1-beta.14, published on 2024-07-20, and the one before it is v4.0.1-beta.12 from May 2024. Both are betas on a 4.0.1 line, which means the version number itself has not settled.

Against that, the repository is not idle. The last push was on 2026-10-06, the default branch is trunk, and the topics describe it as an Electron record and playback tool for the web that supports both an extension and WebDriver. There are 455 open issues. The open question is therefore not whether work is happening but whether the work reaches the artifacts you can install.

The May 2024 release is a fair illustration of what the project considers worth a beta bump: a window timeout field in the command editor for commands marked as opening a window. That is a narrow, careful change, which fits a tool where a wrong timeout or a wrong target selector produces a test that fails for reasons that are hard to see.

There is also a naming thread running through the repository. The project is Selenium IDE, the Electron app package is selenium-ide, the monorepo root is selenium-ide-monorepo, and the sidebar command is side-runner. Anyone writing scripts against these will need all four names.

Editorial conclusion

Selenium IDE fits a team that wants recorded scripts as a starting point and is willing to own the exported code. It does not fit a pipeline that needs a stable release cadence, because the newest tag is a 2024 beta even though the source is current. Verify two things first: which build you actually install, since the npm global install and the GitHub release binaries are separate artifacts, and whether your selectors survive the recorder, which is the open problem the README itself lists as future work.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. SeleniumHQ/selenium-ide on GitHub