Skip to main content
rbs manages language toolchains itself. Declare the version you want in WORKSPACE.rbs, and rbs downloads the official distribution, verifies it, and builds with it — no system installation of Go, Node.js, or Python required, and no drift between what’s on a developer’s machine and what the build uses. Two machines with the same workspace build with byte-identical toolchains.

​
Declaring a toolchain

Each language ships a one-liner for WORKSPACE.rbs:
That single call downloads the toolchain for your platform on first build and registers it for the workspace — every go_binary, nodejs_binary, py_binary, and related rule then uses it automatically. Any release version works, not just a curated list. A small pinned registry inside the rules covers common versions; anything else is fetched by constructing the official download URL for that ecosystem:
  • Go: any release ("1.23.4", "1.26.0", …) straight from go.dev.
  • Node: any release ("21.7.3", …) straight from nodejs.org.
  • Java: any major ("11", "17", "21", "25", …). Pinned entries install an exact Temurin build; an unpinned major resolves to the latest GA of that major via the Adoptium API at first download, then stays fixed in the shared store.
  • Python: select by major.minor ("3.11", "3.12", "3.13") for the pinned hermetic CPython builds, or any full x.y.z published in the python-build-standalone release the rules pin.
A version that doesn’t exist upstream fails at download with the constructed URL in the error. Pinned registry entries remain preferred — they carry exact, checksummed URLs — so pin a version in the rules when byte-exact reproducibility matters. When you build for a different platform than your host (for example a Linux container image built from macOS), rbs also downloads the host toolchain so build-time tools (like the TypeScript compiler) still run locally — you don’t have to declare anything extra.

​
Where toolchains live

Toolchains are stored once per user, not once per workspace:
(The location follows RBS_CACHE_DIR if you’ve relocated the shared cache.) Entries are keyed by platform and content digest, so:
  • Two workspaces on the same toolchain version share one copy — the second workspace links it instantly instead of re-downloading.
  • Two workspaces pinned to different versions coexist without conflict; bumping a version in one workspace never disturbs another.
Inside a workspace, .rbs/toolchains/<platform>/<name> is a link into that store. rbs cache stats reports the store’s total size under “Toolchains”, and rbs cache gc ages out toolchains that haven’t been used recently — a swept toolchain reinstalls itself automatically on the next build.
On Windows, toolchains are installed per-workspace under .rbs/toolchains instead of being linked into the shared store.

​
Hermeticity

Builds use the downloaded toolchain exclusively — rules invoke the toolchain’s own binaries, never whatever happens to be on PATH. Go builds, for example, run with module fetching disabled during compilation, so the compiler can’t quietly reach the network mid-build. The result: a workspace builds the same way on a fresh machine as it does on yours.

​
Custom tools

Beyond language toolchains, you can pull in any standalone tool hermetically with the same machinery — pin the URL and checksum in WORKSPACE.rbs:
native.http_archive does the same for archives (with strip_prefix to peel off a top-level directory), and native.tool_binary wraps a downloaded tool so build rules can invoke it.
Always pin a sha256 and a specific release URL. A checksum makes the download verifiable; a “latest” URL makes the build unreproducible.