> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt
> Use this file to discover all available pages before exploring further.

# Install the CLI

> Install the `reactor` binary on macOS, Linux, or a CI runner.

The `reactor` CLI is how you build and run a model. It is a single Go binary, and it is the only
thing you install. There is no Python, no runtime package, and no media libraries on your host — all
of it ships inside the image the CLI builds for your workspace.

You need two things: the CLI, and a running Docker daemon.

## macOS

Install with [Homebrew](https://brew.sh):

```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
brew install reactor-team/tools/reactor-cli
```

Upgrade the same way:

```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
brew update && brew upgrade reactor-cli
```

## Linux

Homebrew works here too, if you already run it:

```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
brew install reactor-team/tools/reactor-cli
```

Otherwise, download the release tarball into a directory on your `PATH`. The `RELEASE` variable
controls which build you get, and `latest` always resolves to the newest release. Use the `sudo` tab
to install system-wide, or the `no-sudo` tab to install into your home directory.

<CodeGroup>
  ```sh sudo theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
  RELEASE=latest
  ARCH=amd64   # or arm64
  curl -fsSL "https://releases.reactor.inc/reactor-cli/${RELEASE}/reactor-cli_linux-${ARCH}.tar.gz" \
    | sudo tar -xz -C /usr/local/bin
  ```

  ```sh no-sudo theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
  RELEASE=latest
  ARCH=amd64   # or arm64
  mkdir -p ~/.local/bin
  curl -fsSL "https://releases.reactor.inc/reactor-cli/${RELEASE}/reactor-cli_linux-${ARCH}.tar.gz" \
    | tar -xz -C ~/.local/bin
  export PATH="$HOME/.local/bin:$PATH"
  ```
</CodeGroup>

To see which release `latest` currently points at, read the
[VERSION file](https://releases.reactor.inc/reactor-cli/latest/VERSION).

### Pin to a specific release

CI pipelines that need a reproducible install should pin a release instead of tracking `latest`. Set
`RELEASE` to a version from [releases.reactor.inc](https://releases.reactor.inc/), where versioned
tarballs are kept indefinitely.

<CodeGroup>
  ```sh sudo theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
  RELEASE=v1.20260818.22146
  ARCH=amd64   # or arm64
  curl -fsSL "https://releases.reactor.inc/reactor-cli/${RELEASE}/reactor-cli_${RELEASE}_linux-${ARCH}.tar.gz" \
    | sudo tar -xz -C /usr/local/bin
  ```

  ```sh no-sudo theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
  RELEASE=v1.20260818.22146
  ARCH=amd64   # or arm64
  mkdir -p ~/.local/bin
  curl -fsSL "https://releases.reactor.inc/reactor-cli/${RELEASE}/reactor-cli_${RELEASE}_linux-${ARCH}.tar.gz" \
    | tar -xz -C ~/.local/bin
  export PATH="$HOME/.local/bin:$PATH"
  ```
</CodeGroup>

## Windows

Not supported. Use WSL2, or the Linux download above.

## Verify

```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
reactor version
```

Sample output:

```
v1.20260818.22146 (git: a1b2c3d4, runtime: 3.2.0)
```

| Field               | Meaning                                                                |
| ------------------- | ---------------------------------------------------------------------- |
| `v1.20260818.22146` | CLI binary release tag                                                 |
| `git: a1b2c3d4`     | Short git SHA the binary was built from                                |
| `runtime: 3.2.0`    | The `reactor-runtime` version `reactor init` pins into a new workspace |

The runtime version is informational: `reactor` is a Go binary with no Python dependency of its own.
It tells you what a fresh `reactor init` will pin, which you can override per workspace with
`reactor init --runtime-version`. Once a workspace exists, the pin lives in its `requirements.txt`
and you bump it there.

The `reactor` command with no arguments prints a welcome screen. To print it again later, run
`reactor welcome`.

```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
reactor welcome
```

## Check your setup

`reactor version` only proves the binary runs. To check the rest, run `reactor doctor`. It checks
Docker, the workspace config files, your API key, and the connection to the Reactor API. Each check
prints one line, a failed check tells you how to fix it, and the command exits non-zero when any
check fails.

```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
reactor doctor
```

Docker and the config files are what building and running a model locally depend on. The API key
and connection checks only matter once you deploy, so a fresh install that fails those two can
still build and run.

## Next

<CardGroup cols={2}>
  <Card title="Build your own model" icon="rocket" href="/deploy/overview">
    Write a `ReactorModel`, run it, and connect a client.
  </Card>

  <Card title="Model Anatomy" icon="microscope" href="/deploy/development/reactor-model/model-anatomy">
    A working model read line by line.
  </Card>
</CardGroup>