Why ReasonOS

Most teams assemble their development platform from parts: a build tool, one package manager per language, a CI system with its own YAML dialect, an infrastructure tool with its own state store, linters and coverage tools wired in per project, and — lately — AI assistants bolted on the side. Each seam costs reproducibility, onboarding time, and debugging hours. ReasonOS takes the opposite approach: rbs is one binary that covers the whole lifecycle, and everything in it speaks the same language.

One self-contained binary

rbs is a single self-contained binary. Its built-in rules are embedded in the binary itself; there is no runtime to install first, no plugin marketplace to assemble, and no bootstrap step that downloads hundreds of megabytes before your first build.

rbs build //...

Compare the prerequisites: Bazel needs a JVM and per-language rule repositories declared in your workspace before anything compiles; Nx needs Node.js and npm even if your project has no JavaScript in it. rbs needs rbs.

Managed, hermetic toolchains

Rules declare the toolchain they need, and rbs downloads it — pinned by version, verified, and cached in a store shared by every workspace on your machine. No system Go, Node, Python, JDK, or .NET SDK is required, and two developers building the same target use bit-identical tools.

# WORKSPACE.rbs
load("@rbs//go/toolchain.rbs", "go_toolchain")

go_toolchain(
    name = "go",
    version = "1.24.3",
)

The same pattern covers ad-hoc tools: declare a download with a checksum and wrap it as a target.

native.http_file(
    name = "jq_tool",
    url = "https://github.com/jqlang/jq/releases/download/jq-1.7.1/jq-macos-arm64",
    sha256 = "0bbe619e663e0de2c550be2fe0d240d076799d6f8a652b70fa04aea8a8362e8a",
    executable = True,
    output_name = "jq",
)

native.tool_binary(
    name = "jq",
    tool = ":jq_tool",
)

External packages work the same way: rbs resolves npm, PyPI, and Maven dependencies itself — no npm install, no pip install — and records resolutions in a committed rbs.lock so repeat builds skip resolution entirely.

One shared cache

Every build action’s result lands in a user-global, content-addressed store shared across all your workspaces. Check out the same repository twice, or work across ten services that share a library, and cached results carry over. rbs cache stats shows what the store holds; rbs cache gc keeps it bounded. Teams can point builds at a shared remote cache as well:

rbs build //... --remote cache.internal:8980

One language for builds, tests, CI, and infrastructure

Everything is the RBS language — a small, deterministic, Python-like language. The same file style that defines a binary also defines a test with an enforced coverage floor, a CI workflow, and cloud infrastructure:

py_test(
    name = "tests",
    srcs = glob(["tests/**/*.py"]),
    deps = [":calculator"],
    min_line_coverage = 80,   # rbs coverage fails the target below this
)

ci_workflow(
    name = "main",
    on = {"push": {"branches": ["main"]}},
    jobs = {
        "build-test": {
            "steps": [
                {"name": "Build", "run": "rbs build //..."},
                {"name": "Test", "run": "rbs test //..."},
            ],
        },
    },
)

CI workflows run locally with rbs ci run — the pipeline you debug on your laptop is the pipeline that runs on the server. Infrastructure declared with the infra SDK is planned and applied with rbs infra plan and rbs infra apply, with state kept alongside the code rather than in a separate tool’s silo.

Batteries built in

Capabilities that are external tools elsewhere are subcommands here, and they all share the same dependency graph:

Watch mode — rbs build, rbs run, and rbs test all take --watch for rebuild-on-change and TDD loops. No external file-watcher wrapper.
Coverage gates — test rules accept minimum-coverage attributes, and rbs coverage fails targets that drop below them.
Environments — layered .env files validated against a schema written in the build language, selected per-invocation with -e (see Core concepts).
Scaffolding — rbs scaffold generates code from templates with variable substitution, like Nx generators but defined in the same build language.
Stacked branches — rbs stack manages chains of small, dependent branches: create, restack, sync, and submit them as a stack.
Graph queries — rbs query lists targets without building; rbs graph exports the unified build/infra/CI/dependency graph as JSON, DOT, or Mermaid; rbs atlas builds a symbol-level knowledge graph you can query instead of grepping.
A coding agent — rbs agent runs interactively or headless, with permission modes, git-worktree isolation, and workspace checkpoints (rbs checkpoint) to revert its changes.
An editor backend — rbs server exposes file APIs, search, terminals, build-graph-aware language servers, and streaming AI assistance; it is what the ReasonOS editor connects to.

Extensible without plugins

Custom rules are ordinary .rbs code, defined in the same files that use them — no separate rules repository, no npm package, no plugin API:

def _hello_impl(ctx):
    ctx.actions.run(
        executable = "echo",
        arguments = ["Hello, " + ctx.name],
    )

hello = native.define_rule(
    name = "hello",
    implementation = _hello_impl,
    attrs = {},
)

Rules have a first-class test story (rbs rules test and rbs rules integration), and rule packages can be shared across repositories with rbs ext, pinned to commits through the lockfile so a moved tag can never silently change your build.

Where Bazel or Nx may still fit

ReasonOS is opinionated, and honesty helps you choose. If you have years of investment in Bazel rules and remote-execution infrastructure at very large scale, or your world is exclusively JavaScript and you want Nx’s framework-specific generators, those ecosystems are mature. ReasonOS is the better fit when you want hermetic builds, managed toolchains, CI, infrastructure, and AI agents as one system — without assembling and maintaining the glue yourself.

Getting Started

Build

Languages

Containers & Deploy

Infrastructure

CI & Remote Builds

Team Workflow

One self-contained binary

Managed, hermetic toolchains

One shared cache

One language for builds, tests, CI, and infrastructure

Batteries built in

Extensible without plugins

Where Bazel or Nx may still fit

​One self-contained binary

​Managed, hermetic toolchains

​One shared cache

​One language for builds, tests, CI, and infrastructure

​Batteries built in

​Extensible without plugins

​Where Bazel or Nx may still fit

One self-contained binary

Managed, hermetic toolchains

One shared cache

One language for builds, tests, CI, and infrastructure

Batteries built in

Extensible without plugins

Where Bazel or Nx may still fit