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.12.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.12.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.12.0 \
  download resource \
  ghcr.io/open-component-model//ocm.software/cli:0.12.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. 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.

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
gh attestation verify $(which ocm) --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.

# Compute the binary's SHA-256 digest
DIGEST="sha256:$(sha256sum $(which ocm) | cut -d' ' -f1)"
# On macOS, use: DIGEST="sha256:$(shasum -a 256 $(which ocm) | 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]+)' \
  $(which ocm)

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).

# Compute the binary's SHA-256 digest
DIGEST="sha256:$(sha256sum $(which ocm) | cut -d' ' -f1)"
# On macOS, use: DIGEST="sha256:$(shasum -a 256 $(which ocm) | 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#

Verify Installation#

Verify Binary Authenticity#

CLI Reference#

Next Steps#

You’ll end up with

Estimated time

Install the OCM CLI

Prerequisites

Clone and build

Verify Installation

Verify Binary Authenticity

CLI Reference

Next Steps