Installation

Install the Dorgu CLI

Prerequisites

Prerequisites:

• kubectl on your PATH and pointed at the target cluster. Every cluster command shells out to it.
• Go 1.21+ with $GOPATH/bin (or $HOME/go/bin) in your PATH, only for the go install path. The release archives need no Go toolchain.
• Docker installed, only for Dockerfile analysis in dorgu generate.

kubectl is not optional. dorgu health, dorgu incidents, dorgu remediation, and dorgu persona import all shell out to kubectl and read your current context. Without it every cluster command fails with kubectl not found in PATH. Only dorgu generate, dorgu init, and dorgu config work without a cluster.

Versions

Current versions: CLI v0.12.0 with operator v0.11.1 (Helm chart 0.11.1; the chart version, the chart appVersion, and the operator version are always the same number). Newest of each is always the right answer, and this note is the only place in these docs that states which that is.

On arm64 nodes, 0.11.1 is a floor and not a preference. Every operator image published before it, up to and including 0.11.0, was pushed as a single-platform amd64 manifest rather than a manifest list. That covers AWS Graviton nodegroups and any kind or k3d cluster on an Apple Silicon Mac. On containerd there is no manifest list to select from, so the pull succeeds and the container dies immediately with exec /manager: exec format error and exit code 255. The pod reads CrashLoopBackOff, not ImagePullBackOff. 0.11.1 is that image and nothing else: no API, CRD, controller, or chart-template change, which is why everything below still names v0.11.0 as the release each behaviour landed in.

There is no version pinning between the CLI and the operator. Every field either side has added is optional and additive, so a half that does not know about a field simply sees it absent and renders exactly as it did before. Nothing has to be upgraded in lockstep.

Three mismatches change behaviour. Only the first is unsafe, and it is the old CLI, not the old operator:

Mismatch	What happens
CLI v0.9.0 or older against operator v0.9.0 or newer	Upgrade the CLI. An older CLI never reads spec.workloadRef, so approve will patch a Deployment that Helm, ArgoCD, or Flux owns and break the owner’s next apply. The operator supplies the ownership facts; declining the patch is the CLI’s job. This is the one combination that silently does the thing the guard exists to prevent.
CLI v0.10.0 or newer against operator v0.8.1 or older	Conservative rather than dangerous. The operator writes no workloadRef, an absent record is treated as owned, and every remediation carrying a workload change is declined with exit 4. dorgu remediation approve <name> -n <ns> --no-heal records the decision until the operator is upgraded.
CLI v0.12.0 against operator v0.10.0 or older	No guardrail verdicts. They are read from the optional spec.steps[].safety field that operator v0.11.0 adds. The field is absent, remediation list grows no GUARDRAIL column, and every command prints what it printed before.

One operator upgrade is worth doing on its own merits, with no CLI implication at all: with aiRemediation.enabled=true, operator v0.11.0 is the release that made AI-planned remediations appliable. On v0.10.0 and older, a plan that diagnosed a resource change could be persisted with nothing to apply. See AI setup.

Both mismatch directions in full, with the ownership reasoning behind them: version coupling. Newest published releases: CLI and operator.

Binary releases (no Go toolchain)

Every release ships pre-built archives on GitHub Releases, for Linux, macOS, and Windows on both amd64 and arm64.

Set OS to linux or darwin and ARCH to amd64 or arm64:

OS=linux
ARCH=amd64

curl -fLO "https://github.com/dorgu-ai/dorgu/releases/latest/download/dorgu_${OS}_${ARCH}.tar.gz"
tar -xzf "dorgu_${OS}_${ARCH}.tar.gz" dorgu
chmod +x dorgu
sudo mv dorgu /usr/local/bin/

That URL is an unversioned alias that always resolves to the newest release, so it never needs a version bump. It was first published with v0.9.0; for anything older, use the pinned form below.

To pin an exact release instead:

VERSION=0.12.0
OS=linux
ARCH=amd64
ARCHIVE="dorgu_${VERSION}_${OS}_${ARCH}.tar.gz"

curl -fLO "https://github.com/dorgu-ai/dorgu/releases/download/v${VERSION}/${ARCHIVE}"
tar -xzf "$ARCHIVE" dorgu
chmod +x dorgu
sudo mv dorgu /usr/local/bin/

Keep the -f in curl -fLO. Without it, a wrong URL writes the 404 response body to disk, curl still exits 0, and you end up installing a text file named after the asset you wanted.

The archive also contains README.md, LICENSE, and .dorgu.yaml.example; naming dorgu in the tar command extracts only the binary.

Windows

Download dorgu_windows_amd64.zip (or _arm64) from the latest release, extract it, and put dorgu.exe somewhere on your PATH. The pinned form is dorgu_0.12.0_windows_amd64.zip.

Verifying the download

Each release publishes checksums.txt, which covers the versioned archives:

VERSION=0.12.0
curl -fLO "https://github.com/dorgu-ai/dorgu/releases/download/v${VERSION}/checksums.txt"

# Linux
sha256sum --ignore-missing -c checksums.txt
# macOS
shasum -a 256 --ignore-missing -c checksums.txt

Go install

With a Go toolchain, install the latest release:

go install github.com/dorgu-ai/dorgu/cmd/dorgu@latest

Or pin a specific version:

go install github.com/dorgu-ai/dorgu/cmd/dorgu@v0.12.0

If the literal above has fallen behind, Versions is the statement to trust on this page, and CLI releases is the statement to trust over both. @latest always resolves to the newest.

Ensure $GOPATH/bin (or $HOME/go/bin) is in your PATH.

From source

git clone https://github.com/dorgu-ai/dorgu.git
cd dorgu
make build    # builds to ./build/dorgu
make install  # installs to $GOPATH/bin

Verify installation

dorgu version

From a release archive, the commit and build date are stamped in:

dorgu version v0.12.0
Build: 0d863c6 @ 2026-08-26T22:40:37Z

go install github.com/dorgu-ai/dorgu/cmd/dorgu@... cannot set those build flags, so it prints Build: from source instead. That is a working install, not a broken one. Building from a clone with make build or make install does stamp the commit and date.

Next steps

Quickstart

Break an app and watch Dorgu diagnose and heal it.

Already have apps running?

Import personas from your live Deployments so Dorgu can see them.

Ownership model

Which workloads Dorgu will patch, which it only recommends for, and why.

Security and permissions

The operator’s ClusterRole, published in full.