Installation

The kobe CLI is a self-contained binary. It connects to a kobe operator endpoint — the operator itself runs in your Kubernetes cluster.

Install the CLI

All release binaries are signed (macOS codesigned + notarized, Windows code-signed, Linux/apt PGP-signed via GCP-KMS).

# install globally
mise use -g github:kunobi-ninja/kobe@latest

[tools]
"github:kunobi-ninja/kobe" = "latest"

brew install kunobi-ninja/kunobi/kobe

brew install kunobi-ninja/kunobi/kobe-unstable

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://r2.kunobi.com/kobe/apt/gpg.key \
  | sudo gpg --dearmor -o /etc/apt/keyrings/kobe.gpg
echo "deb [signed-by=/etc/apt/keyrings/kobe.gpg] https://r2.kunobi.com/kobe/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/kobe.list
sudo apt-get update && sudo apt-get install kobe

winget install kunobi-ninja.kobe

scoop bucket add kunobi https://github.com/kunobi-ninja/scoop-kunobi

# Stable
scoop install kunobi/kobe

# Pre-release channel
scoop install kunobi/kobe-unstable

choco install kobe

# Prebuilt binary — recommended (statically linked, x86_64 + aarch64, no compile)
paru -S kobe-bin

# Builds the latest main from source
paru -S kobe-git

# Builds the latest release from source
paru -S kobe

# download a pre-built binary (no compile) via cargo-binstall
cargo binstall kobectl

# or compile from crates.io
cargo install kobectl

nix run github:kunobi-ninja/kobe -- --help
nix profile install github:kunobi-ninja/kobe

cargo install --git https://github.com/kunobi-ninja/kobe --bin kobe

Verify the installation

kobe --help

You should see the list of available subcommands. If the command isn't found, make sure the binary is on your PATH.

Deploy the operator

The kobe-operator binary runs in your host Kubernetes cluster. Refer to the Helm chart or Flux deployment in the kobe repository for production setup. The operator requires:

• A host Kubernetes cluster (k3s, k0s, EKS, GKE, or any conformant cluster)
• Permission to manage Kobe CRDs, including ClusterPool, ClusterLease, ClusterInstance, SandboxPool, SandboxLease, AccessPolicy, and KobeStore
• Network access between the operator and a kobe endpoint your clients can reach

Install the CRDs:

cargo run --bin crdgen -- all | kubectl apply -f -

Or apply them from the Helm chart, which bundles the generated CRD manifests.

Helm does not upgrade objects from a chart's crds/ directory. Before upgrading an existing Kobe release to a version that adds CRDs, apply the new chart's CRD manifests explicitly, then upgrade the operator.

SandboxPool, SandboxLease and SandboxExecution are deliberately not operator startup prerequisites, so existing cluster-lease endpoints can remain available during a staged upgrade. Until the Sandbox CRDs are installed and established, the Sandbox API is unavailable; a 503 Service Unavailable means Kobe could not verify Sandbox admission against Kubernetes. Install the CRDs before enabling Sandbox API clients.

The three are checked per endpoint rather than all at once, so a partial install degrades legibly instead of failing everything: leasing needs SandboxPool and SandboxLease, and the execution endpoints additionally need SandboxExecution. A cluster with the first two but not the third can still lease and connect — only POST /v1/sandbox-leases/{id}/executions and its siblings report the missing CRD, and they say which one.

Separate teardown authority

On Kubernetes 1.30 or newer, set teardownAuthority.separate=true to run teardown proof production under a dedicated ServiceAccount. Helm installs two fail-closed ValidatingAdmissionPolicy boundaries: ordinary lifecycle code cannot forge or erase protected evidence, and it cannot replace the authority namespace or cluster-scoped RBAC. The authority validates the live policies, bindings, and its authenticated identity before it starts.

The default remains the compatibility single-process mode for older API servers. In that mode, the ordinary control plane also publishes teardown evidence, so it does not provide the same identity separation.