Install runtz CLI

The runtz CLI is a single static Go binary. The install script detects your architecture, downloads the binary and puts it on your PATH.

curl -fsSL https://runtz.dev/install.sh | bash

Verify the installation:

runtz version

runtz 1.0.0-rc1 (linux/amd64)

Linux and macOS are supported on amd64 and arm64; Windows on amd64.

Script options

Both scripts accept the same overrides, passed as environment variables.

# Install a specific release
RUNTZ_VERSION=v1.0.0-rc1 curl -fsSL https://runtz.dev/install.sh | bash

# Install to a custom directory (no sudo needed if writable)
RUNTZ_INSTALL_DIR=$HOME/.local/bin curl -fsSL https://runtz.dev/install.sh | bash

Manual install

Download the binary for your platform from the GitHub releases page, then:

chmod +x runtz_linux_amd64
sudo mv runtz_linux_amd64 /usr/local/bin/runtz
runtz version

Docker image

The CLI is also published as a container image — the entrypoint is the runtz binary:

docker run --rm runtzdev/runtz-cli:latest version

This is the recommended way to run runtz in pipelines — see the CI/CD guides for ready-to-use pipeline examples (GitHub Actions, GitLab, Jenkins, Azure DevOps, Bitbucket and CircleCI).

Commands

Updating

The CLI updates itself in place, verifying the download's SHA-256 against the release checksums before replacing the binary:

runtz update          # prompts before replacing the binary
runtz update --yes    # no prompt (automation)
runtz update --check  # only report if a newer version exists (exit 3 if so)

Authentication

Every scan authenticates with a workspace token generated in the platform (rtz_live_...); the token resolves your workspace automatically. For interactive use, log in once — runtz login verifies the token and stores it in ~/.config/runtz/config.json (permissions 0600), and scan commands stop needing --token:

runtz login          # paste the token at a hidden prompt
runtz whoami         # workspace + where the current token comes from
runtz logout         # remove the stored token

In CI/CD, skip login and pass the token from a secret on each run. The token is resolved in this order — an explicit flag or environment variable always beats the stored login:

1. --token flag
2. RUNTZ_TOKEN environment variable
3. runtz login stored token

--endpoint defaults to the runtz SaaS engine (https://engine.runtz.dev). Self-hosted deployments pass their own endpoint — runtz login --endpoint stores it alongside the token — or set RUNTZ_ENDPOINT.

First scan

Log in, then scan from the root of any repository:

runtz login
runtz sca ./

Expected output:

Parsed package.json (npm): 42 dependencies
Checking 42 dependencies against the GitHub Advisory Database...
Sending SCA scan to Runtz...
SCA scan completed and sent to Runtz Platform.
Project: frontend
Manifests: 1
Dependencies: 42
Vulnerabilities: 3

CI/CD severity gates

Every scan command can fail the pipeline when it finds too many issues at a given severity. The thresholds are optional; 0 (the default) leaves the gate off.

# Fail the build on a single critical, or on 5+ highs:
runtz sca ./ \
  --token "$RUNTZ_TOKEN" \
  --critical-threshold 1 \
  --high-threshold 5

Available on every scan: --critical-threshold N, --high-threshold N, --medium-threshold N, --low-threshold N (or the env vars RUNTZ_CRITICAL_THRESHOLD, RUNTZ_HIGH_THRESHOLD, RUNTZ_MEDIUM_THRESHOLD, RUNTZ_LOW_THRESHOLD).

The scan results are always sent to the platform before the gate is evaluated, so a failed gate still records the scan.

Exit codes: 0 success · 1 execution error · 2 usage error · 3 a severity gate tripped (or runtz update --check found an update).

See the Scans section for what each scan type covers and every available flag.