Selenium's repository is a Bazel-built source tree for contributors, not a package you install

The README is written for contributors, so an install question ends at a redirect

The repository describes Selenium as an umbrella project bundling tools and libraries for web browser automation, and its central claim is that it provides infrastructure for the W3C WebDriver specification, which it calls a platform and language-neutral coding interface compatible with all major web browsers. What it does not do is tell a library user how to install it. The opening line states that the README is for developers interested in contributing, and points anyone starting out to the User Manual at selenium.dev/documentation, with a separate support page for when they get stuck.

That redirection matters for readers who arrive looking for an install command and expect a package name next to it. There is none here. The py/, java/ and javascript/ directories are source trees for a Bazel build, not published packages sitting beside an install line. For contributors who would rather not assemble that locally, the README offers three hosted shapes instead: GitPod as a ready to use environment, a dev container built from .devcontainer/devcontainer.json for editors such as VS Code or IntelliJ IDEA, and a Docker image built from the Dockerfile under scripts/dev-image.

Bazelisk picks the Bazel named in .bazelversion, so the build tool is not yours to choose

The build runs through Bazel, but the repository does not ask you to install Bazel itself. Bazelisk is the wrapper, and it reads the version pinned in the .bazelversion file, downloads that version, and passes command-line arguments through to the real Bazel binary. The root of the tree holds the configuration that arrangement expects: .bazelrc, .bazelrc.remote and .bazelignore, next to MODULE.bazel, WORKSPACE, REPO.bazel and a root BUILD.bazel.

The consequence is that two contributors on the same commit run the same Bazel, and a globally installed Bazel of a different version is overridden rather than obeyed. Two other root entries are worth knowing about before a first build: a .skipped-tests file and a Rakefile with a rake_tasks/ directory sitting alongside the Bazel files.

JAVA_HOME has to point at a JDK, and javac is the check

The single hard version constraint given for every platform is Java JDK 17 or greater, with Java 17 Temurin named as an example. The variable matters more than the version, and the README is unusually specific about it: JAVA_HOME must be set to the location of the Java executable, the JDK and not the JRE.

The check offered is short. Run javac, and if the command does not exist then only a JRE is installed; if you get a list of command-line options, the JDK is wired up correctly.

Running that command before a first compile is a cheap check. The project also states that it is made possible by volunteer contributors who have donated thousands of hours to code development and upkeep, so nothing here carries a support commitment from a vendor. Licensing is Apache-2.0, with LICENSE, NOTICE and AUTHORS files at the root of the tree.

Apple Silicon builds still need a hand written rosetta line

On macOS the extra requirement is Xcode with its command line tools, and the install is one command:

xcode-select --install

On Apple Silicon Macs a second requirement applies, and the README marks it as temporary: Rosetta, configured by adding a build flag to a local .bazelrc.local file.

build --host_platform=//:rosetta

The sentence after it says the team is working to make sure this is not required in the long run, which is a statement of intent and not a schedule. Until it is gone, every contributor on an M-series machine has to create that file and keep it. Two such files exist, this one and selenium/.bazelrc.windows.local on Windows.

Every worktree re-downloads the dependencies, and the fix goes in your own bazelrc

Bazel keeps its build outputs and downloaded dependencies under each checkout by default. That means a contributor working from several git worktrees of this repository downloads those dependencies again in each one and rebuilds artifacts, so every new worktree pays a full dependency fetch before it runs a test.

The workaround is a user level disk cache, configured in your home .bazelrc rather than in the repository's, so the setting stays on one machine and out of every commit:

common --disk_cache=/path/to/your/home/.cache/bazel-d

The path being yours is the point of putting it there rather than in .bazelrc, since a shared repository file would hard-code one machine's directory into everyone's build. A team that has not made this change pays the download again in every worktree.

Windows needs MSYS2, a C++ workload and registry edits before Bazel runs

The Windows setup is the one with the most moving parts, and it arrives in two forms. The scripted path runs scripts/dev-environment-setup.ps1 from an elevated PowerShell session, after allowing script execution for the process with Set-ExecutionPolicy Bypass -Scope Process -Force. The manual path asks for four things: RemoteSigned as the execution policy, Developer Mode enabled through a registry key, MSYS2 installed with its bin directory added to PATH and its bash.exe assigned to BAZEL_SH, and the latest Visual Studio Community with the Desktop development with C++ workload, whose build tools directory goes into BAZEL_VC and whose MSVC version goes into BAZEL_VC_FULL_VERSION.

Two Windows limits also have to be lifted, because Bazel's nested output trees exceed the defaults:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor" /t REG_DWORD /f /v "DisableUNCCheck" /d "1"
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" /t REG_DWORD /f /v "LongPathsEnabled" /d "1"

Bazel is then told to produce short name versions of long paths with fsutil 8dot3name set 0, and to write output outside the project directory by putting startup --output_user_root=C:/tmp into selenium/.bazelrc.windows.local. The README also links a detailed article about setting up a Windows development environment for the .NET bindings and says it is out of date but includes more detailed descriptions and screenshots.

Eight language trees share one Java-first Bazel workspace

The top level of the tree is the clearest statement of scope. Language directories sit side by side: java/, javascript/, dotnet/, py/, rb/, rust/, cpp/ and go/, with Java as the primary language of the project. Shared code lives in common/, third-party code in third_party/, documentation in docs/, and tooling scripts in scripts/.

Anyone working on a single binding is building inside a Java first workspace, which is why the JDK 17 requirement sits under the all platforms heading rather than inside a language section. The JavaScript side is configured differently from the rest of the tree: package.json declares two workspaces, javascript/grid-ui and javascript/selenium-webdriver, alongside pnpm-workspace.yaml, pnpm-lock.yaml, an .npmrc and an .nvmrc at the root. Two consequences follow for a reader choosing an approach. A Python or Rust contributor has to navigate a workspace sized for eight languages to isolate their own binding, and the Node toolchain is pinned by files unrelated to .bazelversion, so there are two independent version systems to hold in view at once. Dependency updates are also automated through a renovate.json at the root, which is worth knowing before anyone opens a pull request that only bumps a version.

A nightly tag moves daily while numbered releases land every few weeks

The default branch is trunk, and the release list shows two cadences running side by side. A nightly build was published on 2026-11-03, Selenium 4.52.0 on 2026-10-29 and Selenium 4.51.0 on 2026-10-09, so numbered releases arrive roughly every three weeks while the nightly build is refreshed far more often. The last push to trunk was on 2026-11-02, and the repository is not archived.

For a team pinning a Selenium version, that shape means choosing which line to track, and a tag named nightly carries no stability guarantee of its own. For a team reading trunk to track changes, the push date is the honest measure rather than the tag list. On upgrade cost, the Apache-2.0 license sits with LICENSE and NOTICE at the root, CONTRIBUTING.md is where pull requests are meant to start, and the version constraint that will surface first on any machine is the JDK 17 floor, not the Selenium version itself.

Editorial conclusion

This checkout suits contributors to the bindings themselves, and teams that need to build Java, JavaScript, .NET, Python, Ruby, Rust, C++ or Go bindings from trunk on their own infrastructure. A team that only wants to drive a browser should follow the User Manual, because nothing in this repository installs a usable library. Verify three things before a first build: that JAVA_HOME resolves to a JDK where javac runs, that Bazelisk is on your PATH so the version pinned in .bazelversion is the one used, and on Windows that DisableUNCCheck and LongPathsEnabled are set and that BAZEL_SH and BAZEL_VC point at real paths, because Bazel's nested directories can exceed default limits in Windows.

Frequently asked questions

Official sources

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