Installation

Prerequisites

For the install script, you need:

• curl or wget
• tar

If you plan to build from source, you also need:

• Rust 1.94+: install via rustup if you don't have it
• A C linker (included with Xcode Command Line Tools on macOS, or build-essential on Debian/Ubuntu)

Install with curl

This detects your OS and CPU, downloads the matching release archive, verifies its SHA-256 checksum, and installs chio into /usr/local/bin. It stops on a checksum mismatch rather than installing the bytes it got:

$ curl -fsSL https://www.chio.world/install.sh | sh

To install into a user-writable directory:

$ curl -fsSL https://www.chio.world/install.sh | CHIO_INSTALL_DIR="$HOME/.local/bin" sh

Pin a version or point the installer at a private mirror:

$ curl -fsSL https://www.chio.world/install.sh | CHIO_VERSION=0.1.0 sh
$ curl -fsSL https://www.chio.world/install.sh | \
    CHIO_RELEASE_BASE_URL=https://mirror.example.com/chio/releases/v0.1.0 sh

Build from source

Cargo builds the CLI out of the repository. The workspace pins its toolchain in rust-toolchain.toml, so rustup fetches the Rust 1.94.1 the build asks for:

$ git clone https://github.com/bb-connor/arc.git
$ cd arc
$ cargo build --release -p chio-cli
   Compiling proc-macro2 v1.0.106
   ... 666 more crates ...
    Finished `release` profile [optimized] target(s) in 19m 38s
$ export PATH="$PWD/target/release:$PATH"
$ chio --version
chio-cli 0.1.0

The build writes one self-contained binary at target/release/chio, and the export puts it on your PATH for this shell. Copy that file into a directory your PATH already covers, such as /usr/local/bin or $HOME/.local/bin, to keep it there.

Homebrew

On macOS and Linuxbrew, install from the release formula. The URL below redirects to the matching GitHub Release asset:

$ curl -fsSL https://www.chio.world/releases/chio/latest/chio.rb -o /tmp/chio.rb \
    && brew install --formula /tmp/chio.rb

Prebuilt binaries

The installer downloads these same archives. The release pipeline builds for the five targets below and names the archives exactly as shown, so the table is the naming contract to script against:

$ VERSION=0.1.0
$ TARGET=aarch64-apple-darwin
$ ARCHIVE="chio-$VERSION-$TARGET.tar.gz"
$ BASE="https://www.chio.world/releases/chio/v$VERSION"
$ curl -fL "$BASE/$ARCHIVE" -o "$ARCHIVE"
$ curl -fL "$BASE/$ARCHIVE.sha256" -o "$ARCHIVE.sha256"
$ shasum -a 256 -c "$ARCHIVE.sha256"
$ tar -xzf "$ARCHIVE"
$ sudo install -m 0755 "chio-$VERSION-$TARGET/chio" /usr/local/bin/chio

Docker

Run the Chio kernel in a container for CI runners, temporary build agents, or environments where installing a native binary is impractical. Two tag families ship: latest tracks main, and the version tags come from release tags, so pin a version for anything you deploy.

$ docker pull ghcr.io/backbay-labs/chio-sidecar:0.1.0
$ docker pull ghcr.io/backbay-labs/chio-sidecar:latest
$ docker run --rm ghcr.io/backbay-labs/chio-sidecar:0.1.0 --help

The image is Alpine-based and runs as the non-root user chio (UID 10001), with tini as PID 1 for correct signal handling. Sidecar state is persisted under /var/lib/chio; mount a volume there to keep receipts across restarts.

The entrypoint is the chio binary and nothing else, so the command defaults to --help and every deployment overrides it with a real subcommand (run, mcp serve-http, and the like). A subcommand that wraps a tool server needs that server in the image too, which is what the derived build on Container Images is for.

SDK installation

To embed Chio governance directly in your application instead of running the CLI as a sidecar, use one of the language SDKs.

TypeScript

$ npm install @chio-protocol/sdk

Or with your preferred package manager:

$ yarn add @chio-protocol/sdk
$ pnpm add @chio-protocol/sdk
$ bun add @chio-protocol/sdk

The @chio-protocol/sdk manifest declares an engines range of Node >=22, and the framework packages below carry the same range.

Python

Two distributions, by design. Most applications want the sidecar client, which delegates enforcement to a colocated kernel:

$ pip install chio-sdk-python   # import chio_sdk

The in-process core verifies inside the application process and is the conformance anchor:

$ pip install chio-sdk          # import chio

Both distributions, and every Python adapter beside them, set requires-python to >=3.11.

Go

The Go modules are consumed from a clone: require the module path, then point it at the directory in the tree. This is what examples/hello-chi does for the wire adapter.

require (
	github.com/backbay-labs/chio/sdks/go/chio-go-http v0.0.0
	github.com/go-chi/chi/v5 v5.2.3
)

replace github.com/backbay-labs/chio/sdks/go/chio-go-http => ../../sdks/go/chio-go-http

Each Go SDK module names its own minimum toolchain in its go directive:

• github.com/backbay-labs/chio/sdks/go/chio-go-http: go 1.21
• github.com/backbay-labs/chio/sdks/go/chio-go: go 1.23.0

Framework adapters

Framework integrations connect Chio to an existing application stack. In Python, install an adapter alongside chio-sdk:

$ pip install chio-fastapi     # FastAPI / ASGI
$ pip install chio-django      # Django
$ pip install chio-langgraph   # LangGraph
$ pip install chio-prefect     # Prefect flows

The Temporal adapter is installed from its own directory in a clone, together with the sidecar client beside it.

uv venv --python 3.11
uv pip install -e '.[dev]'
uv pip install -e ../chio-sdk-python

Further Python adapters cover chio-langchain, chio-crewai, chio-autogen, chio-llamaindex, chio-dagster, chio-airflow, and chio-ray. On TypeScript, the core @chio-protocol/sdk is paired with per-framework packages:

$ npm install @chio-protocol/express
$ npm install @chio-protocol/fastify
$ npm install @chio-protocol/elysia
$ npm install @chio-protocol/node-http
$ npm install @chio-protocol/ai-sdk

Other languages

Chio also ships host SDKs beyond TypeScript, Python, and Go. The JVM modules publish under the Gradle group world.chio, each built for the Java release its Gradle file names:

• chio-sdk-jvm: Java 17
• chio-spring-boot: Java 17
• chio-streaming-flink: Java 21

On .NET, ChioMiddleware ships as Backbay.Chio.Middleware and targets net8.0. On C++, the CMake projects are ChioCpp and the Drogon middleware ChioDrogon, in the directories sdks/cpp/chio-cpp and sdks/cpp/chio-drogon. For infrastructure, there is a Kubernetes controller with CRDs and admission webhooks, an AWS Lambda extension (chio-lambda-extension), and a Swift SDK with App Attest support.

Verify release signatures

Each release archive ships with a detached Sigstore keyless signature: a .sig (cosign signature) and a .pem (Fulcio short-lived certificate) produced by the GitHub Actions release workflow under its OIDC identity. Verify a downloaded archive with cosign, pinning both the certificate identity and the OIDC issuer:

$ ARCHIVE=chio-0.1.0-aarch64-apple-darwin.tar.gz
$ cosign verify-blob \
    --signature   "$ARCHIVE.sig" \
    --certificate "$ARCHIVE.pem" \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    --certificate-identity-regexp \
        '^https://github.com/backbay-labs/chio/.github/workflows/.+@refs/tags/.+$' \
    "$ARCHIVE"

Both pins matter. The identity regexp above accepts only a signature minted by a workflow in this repository running on a tag ref, and the issuer pins that workflow to GitHub's OIDC provider. Each of the five archives carries its own .sig and .pem pair, so verifying one platform says nothing about another. The CLI applies the same identity and issuer pins to a Sigstore bundle: chio attest supply-chain verify --artifact <path> --bundle <path> --issuer-san-regex <regex> --issuer-oidc <url>, which is the form a supply-chain attestation takes when it travels with a governed artifact rather than a release archive. Releases also publish SLSA provenance and an SBOM alongside the signed archives.

Verify the installation

Confirm the CLI is installed and reachable:

$ chio --version

chio-cli 0.1.0

The CLI prints its name and version. If you get a command not found error, ensure the install directory is in your PATH.

Next steps

With the CLI installed, explore the system architecture or jump straight into writing policies:

• Architecture: understand the kernel, guard pipeline, and trust boundaries
• Capabilities: how authority is scoped, delegated, and revoked
• Policy Schema: full guard configuration options