Install the OCM CLI

The OCM CLI is the primary tool for creating, managing, and transferring component versions. This guide covers installation options for different platforms.

You’ll end up with

The OCM CLI installed and ready to use on your system
The ability to run ocm commands from your terminal

Estimated time

~5 minutes

Install the OCM CLI

wget -qO- https://ocm.software/install-cli.sh | bash

curl -sfL https://ocm.software/install-cli.sh | bash

OCM distributes its own CLI as an OCM component version, the same mechanism it enables for your software.

Requires an existing OCM installation

This method needs ocm already on your PATH. For a first install, use the wget or curl tab instead. If you have Docker but no ocm, see the Docker bootstrap section below.

Download the CLI binary for your platform. Replace os and architecture as needed (linux/amd64, linux/arm64, darwin/amd64, darwin/arm64, windows/amd64, windows/arm64). The binary will be downloaded to the current working directory (specify --output to set the full output path, including filename):

ocm download resource \
  ghcr.io/open-component-model//ocm.software/cli:0.13.0 \
  --identity os=linux,architecture=amd64

Then make the downloaded binary executable and move it to your PATH:

chmod +x ./ocm
mkdir -p $HOME/.local/bin
mv ./ocm $HOME/.local/bin/ocm

Windows

The resource is downloaded as ocm.exe for Windows platform if not specified otherwise using the --output option. Make sure to add the directory containing ocm.exe to your PATH.

To inspect the full component version before downloading:

ocm get cv ghcr.io/open-component-model//ocm.software/cli:0.13.0 -o yaml

Docker bootstrap (no existing OCM installation)

Use the official OCM container image as a one-time downloader. The image contains the ocm binary and writes the downloaded resource to its working directory, which you can map to a local path via a volume mount:

mkdir -p "$HOME/.local/bin"
docker run --rm \
  -v "$HOME/.local/bin:/workspace" \
  -w /workspace \
  ghcr.io/open-component-model/cli:0.13.0 \
  download resource \
  ghcr.io/open-component-model//ocm.software/cli:0.13.0 \
  --identity os=linux,architecture=amd64
chmod +x "$HOME/.local/bin/ocm"

Replace os and architecture with your platform. This approach works on Linux and macOS.

Note

Building from source is not officially supported. Use the pre-built binaries via wget or curl instead.

Prerequisites

Clone and build

Build the OCM CLI from the open-component-model/open-component-model monorepo.

git clone https://github.com/open-component-model/open-component-model.git
cd open-component-model
task cli:build   # builds to cli/tmp/bin/ocm
task cli:install # installs to /usr/local/bin (requires sudo)

The binary is installed to ~/.local/bin by default (per the XDG Base Directory Specification). The installer verifies binary integrity via GitHub attestations when the GitHub CLI (gh) is available. Set OCM_VERSION to install a specific version, OCM_BIN_DIR to control where the binary lands (default: ~/.local/bin), and OCM_BIN_NAME to install the binary under a custom name. Run bash -s -- --help after the pipe to see all options.

Windows Support

The install script only supports macOS and Linux. Windows binaries can be downloaded directly from the GitHub releases page.

Windows support is best-effort and not guaranteed. While the CLI handles Windows-specific conventions such as drive-letter paths (e.g., C:\path\to\archive) and backslash path separators, there is no dedicated Windows CI infrastructure to continuously validate these code paths.

Windows builds are cross-compiled and checked for compilation correctness.
Windows-specific logic (such as path detection and normalization) is tested via simulated OS behavior on non-Windows runners.
There is no runtime testing on actual Windows environments in CI.
Bugs specific to Windows runtime behavior may go undetected until reported.

If you encounter a Windows-specific issue, please report it at github.com/open-component-model/open-component-model/issues.

Install a specific version

By default the script installs the latest stable release. Set OCM_VERSION to pin to a specific version. Use MAJOR.MINOR for the latest patch on that series, or MAJOR.MINOR.PATCH for an exact release:

wget -qO- https://ocm.software/install-cli.sh | OCM_VERSION=0.12 bash
# or with curl:
curl -sfL https://ocm.software/install-cli.sh | OCM_VERSION=0.12 bash

Side-by-side versions

Set OCM_BIN_NAME to install the binary under a custom name (default: ocm), and OCM_BIN_DIR to set the install directory. Combine both with a version suffix to keep multiple versions side by side in the same directory:

wget -qO- https://ocm.software/install-cli.sh | OCM_VERSION=0.12 OCM_BIN_NAME=ocm-v0.12 OCM_BIN_DIR=~/.local/bin bash
wget -qO- https://ocm.software/install-cli.sh | OCM_VERSION=0.11 OCM_BIN_NAME=ocm-v0.11 OCM_BIN_DIR=~/.local/bin bash

Each installs the binary under the name you give it. Run by name if ~/.local/bin is on your PATH, or by full path otherwise:

# Run a specific version by name (if ~/.local/bin is on PATH)
ocm-v0.12 version

# Or by full path
~/.local/bin/ocm-v0.12 version

# Switch which version is active in your shell session
ln -sf ~/.local/bin/ocm-v0.12 ~/.local/bin/ocm
ocm version

This is useful for running v1 and v2 side by side during a migration, testing a release candidate, or reproducing version-specific behavior when debugging.

Verify Installation

After installing, verify the CLI is working:

ocm version

Expected output:

{"major":"0","minor":"1","patch":"0","gitVersion":"0.1.0","goVersion":"go1.26.0","compiler":"gc","platform":"darwin/arm64"}

If the output looks different

If the field names are capitalised (Major, Minor, Patch), you are running the legacy v1 CLI, not v2. A previous v1 installation is shadowing the new binary. Run which ocm (Linux/macOS) or where.exe ocm (Windows) to see which binary is active — then either move ~/.local/bin earlier in your PATH or remove the v1 binary. Common v1 install locations are /opt/homebrew/bin (Homebrew), /usr/local/bin (old install script), ~/go/bin (built from source), and the Nix profile store.

Verify Binary Authenticity

The install script automatically verifies binaries using GitHub attestations when the GitHub CLI is authenticated. If automatic verification is unavailable, you can verify manually using one of the methods below.

The simplest method. Requires the GitHub CLI with authentication.

gh auth login --hostname github.com
# Set this to the binary you installed (adjust the path if you used a custom name or directory).
binary="${HOME}/.local/bin/ocm"
gh attestation verify "$binary" --repo open-component-model/open-component-model

Uses Sigstore cosign to cryptographically verify the binary’s provenance. No GitHub authentication required. The attestation API is public.

# Set this to the binary you installed (adjust the path if you used a custom name or directory).
binary="${HOME}/.local/bin/ocm"

# Compute the binary's SHA-256 digest
DIGEST="sha256:$(sha256sum "$binary" | cut -d' ' -f1)"
# On macOS, use: DIGEST="sha256:$(shasum -a 256 "$binary" | cut -d' ' -f1)"

# Download the Sigstore attestation bundle from the public GitHub API
curl -sfL \
  "https://api.github.com/repos/open-component-model/open-component-model/attestations/${DIGEST}" \
  | jq -r '.attestations[0].bundle' > attestation.jsonl

# Verify with cosign
cosign verify-blob-attestation \
  --bundle attestation.jsonl \
  --new-bundle-format \
  --type slsaprovenance1 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp \
    '^https://github\.com/open-component-model/open-component-model/\.github/workflows/cli\.yml@refs/(heads/(main|releases/v[0-9]+\.[0-9]+)|tags/cli/v[0-9]+\.[0-9]+\.[0-9]+)' \
  "$binary"

A successful verification proves the binary was built by the project’s GitHub Actions workflow and signed via Sigstore OIDC.

Verify integrity by comparing your binary’s hash against the digests recorded in the attestation (no extra tools needed beyond curl and jq).

# Set this to the binary you installed (adjust the path if you used a custom name or directory).
binary="${HOME}/.local/bin/ocm"

# Compute the binary's SHA-256 digest
DIGEST="sha256:$(sha256sum "$binary" | cut -d' ' -f1)"
# On macOS, use: DIGEST="sha256:$(shasum -a 256 "$binary" | cut -d' ' -f1)"

# Fetch expected digests from the attestation
curl -sfL \
  "https://api.github.com/repos/open-component-model/open-component-model/attestations/${DIGEST}" \
  | jq -r '.attestations[0].bundle.dsseEnvelope.payload' \
  | base64 --decode | jq '.subject[] | "\(.digest.sha256)  \(.name)"'

If your binary’s digest appears in the output, it matches the attested build artifact.

Note

This verifies integrity (the file hasn’t been corrupted) but not authenticity (it could theoretically be replaced along with the attestation by an attacker who compromises GitHub infrastructure). For full cryptographic proof, use the cosign method above.

CLI Reference

For detailed command documentation, see the OCM CLI Reference.

Next Steps

Tutorial: Create component versions - Learn how to create and store component versions using the OCM CLI

Certificate Chains (PEM)

Create Component Versions

Install the OCM CLI

You’ll end up with#

Estimated time#

Install the OCM CLI#

Prerequisites#

Clone and build#

Install a specific version#

Side-by-side versions#

Verify Installation#

Verify Binary Authenticity#

CLI Reference#

Next Steps#

You’ll end up with

Estimated time

Install the OCM CLI

Prerequisites

Clone and build

Install a specific version

Side-by-side versions

Verify Installation

Verify Binary Authenticity

CLI Reference

Next Steps