--- title: Keeping the CLI current sidebar_label: self-update, version description: "clika-cli self-update and version: pull a newer CLI from the deployment's own release channel, with checksum and signature verification." --- Each deployment serves the CLI binaries built from its own commit, so the right version of `clika-cli` is whichever one that deployment publishes. `self-update` fetches it, and `version` tells you what you are running now. ## `version` ``` clika-cli version ``` Prints the release version stamped into the binary when it was built. It talks to nothing, so it works with no credentials and no network. ``` $ clika-cli version 1.4.2 ``` A binary you built yourself with a plain `go build` reports `dev`. That is not a cosmetic difference. A non-semantic version cannot be compared against the channel's published version, so `self-update` refuses to act on it. ## `self-update` ``` clika-cli self-update [flags] ``` Reads the latest published version from the deployment's release channel at `/files/installation/cli`, and if it is newer than the running binary, downloads the matching asset for your operating system and architecture, verifies it, and atomically replaces the binary in place. Re-run `clika-cli` afterwards; the process that performed the update is still the old one. | Flag | Type | Default | Meaning | | --- | --- | --- | --- | | `--check` | bool | `false` | Report the latest published version and stop. Nothing is downloaded or replaced. | ``` $ clika-cli self-update --check running 1.4.2, latest 1.5.0 ``` ``` $ clika-cli self-update downloading clika-cli-linux-amd64 1.5.0 ... checksum ok signature ok updated to 1.5.0, re-run clika-cli ``` ### Coming from `clika-rt` Until September 2026 this program was named `clika-rt`. The rename is a clean cut: an installed `clika-rt` does not update itself into `clika-cli`, the old asset names are no longer served, and a profile saved under `~/.config/clika-rt/` is not read. Install `clika-cli` from the deployment's **Settings → CLI** tab (or the asset table on the [install page](./index.md)), run `clika-cli login` once, and remove the old binary. ### It needs a credential The release channel is authenticated, exactly like the rest of the deployment. `self-update` sends the same credential every other command uses (flag, then environment, then profile) on **every** fetch it makes: the version file, the checksum list, the signature list and the binary itself. A CLI that has never logged in cannot update itself, and says so with a `401`. ``` clika-cli login --base-url https://platform.clika.io --api-key clika-cli self-update ``` On an on-premise deployment with a self-signed certificate, pass `--insecure-tls`. This is one place the CLI cannot decide for you whether a certificate authority is trustworthy: ``` clika-cli --profile onprem --insecure-tls self-update ``` ### What is verified Two independent checks, both of which must pass: - **The checksum**, taken from the channel's `checksums.txt`. - **A detached signature** over the binary, verified against a public key embedded in the CLI at build time. The signature is the one that matters, because whoever serves the binary also serves the checksum. A checksum alone proves the download was not corrupted, not that it came from CLIKA. A release build refuses an update that is unsigned, tampered with, or signed by a different key. A binary you built locally embeds no trust key. It logs that signature enforcement is off and falls back to the checksum alone, which is fine for development and is not what you should be shipping to anyone. Transport is HTTPS only, and a redirect that would downgrade the connection is refused. ## Installing in the first place `self-update` replaces an installed CLI; it cannot bootstrap one. For the first install, and for the per-platform asset names, see [the install section of the CLI overview](index.md#install). ## The device agent is a separate channel Do not confuse updating the CLI with updating the **device agent**, the program that runs on each of your devices. They use the same download and verification machinery but are different artifacts on different schedules. | Command | What it does | | --- | --- | | `install list --os ` | Prints the agent install script for a platform, which is what you run on a new device to enroll it. | | `install availability --os ` | Reports whether an agent build is available for that platform. | | `install enrollment-payload` | The Android enrolment QR payload, which is what a phone scans. | | `devices update-create ` | Triggers an agent update on one device. | | `devices batch-update` | Triggers an agent update on many devices. | | `agent-versions list` | The agent versions this deployment publishes. | | `agent-versions latest` | The newest one. | See [devices](devices.md#agent-updates-and-certificates) for the update policy and history commands. ## Full command reference Every command below is generated from the deployment's own API description, so one subcommand is exactly one platform operation. Each entry names the method, the endpoint and the [MCP](mcp.md) tool name, so the same operation is identifiable whichever surface you drive it from. Path parameters are positional arguments, query parameters are flags, and a request body is `--body` or `--body-file`. The hand-written commands, the ones that stream, propagate an exit code, or hand your terminal to `ssh`, carry no operation line. The prose above covers the commands most people reach for. This section is the complete surface, for when you need the flag you have not used before. ### `clika-cli self-update` #### `clika-cli self-update` Fetches the latest clika-cli version from the orchestrator's release channel (``/files/installation/cli), verifies its checksum and signature, and atomically replaces this binary. Re-run clika-cli after a successful update. ``` clika-cli self-update [flags] ``` | Flag | Type | Default | Meaning | | --- | --- | --- | --- | | `--check` | bool | `false` | only report the latest version, do not update | ### `clika-cli version` #### `clika-cli version` Prints the release version stamped into this binary at build time. A plain `go build` leaves it `dev`, which disables self-update. ``` clika-cli version [flags] ``` ### `clika-cli install` `install` has 3 subcommands. #### `clika-cli install availability` Agent install availability ``` clika-cli install availability [flags] ``` | Flag | Type | Default | Meaning | | --- | --- | --- | --- | | `--os` | string | none | Platform to probe (android, linux, windows). Defaults via User-Agent. | | `--raw` | bool | `false` | print raw response without pretty-printing | #### `clika-cli install enrollment-payload` Android enrollment QR payload ``` clika-cli install enrollment-payload [flags] ``` | Flag | Type | Default | Meaning | | --- | --- | --- | --- | | `--code` | string | none | Activation code the device will enroll with (case and the dash do not matter); the payload then carries the addresses and TLS posture without a token | | `--raw` | bool | `false` | print raw response without pretty-printing | | `--token` | string | none | Enrollment token (JWT) to embed in the payload; one of token or code is required | #### `clika-cli install list` Get agent install script ``` clika-cli install list [flags] ``` | Flag | Type | Default | Meaning | | --- | --- | --- | --- | | `--code` | string | none | Activation code the installed agent enrolls with, in place of a token (as shown in the Add Device dialog; case and the dash do not matter) | | `--os` | string | none | Override platform detection: linux, windows, android | | `--raw` | bool | `false` | print raw response without pretty-printing | | `--token` | string | none | Pre-fill enrollment token in the generated script | ## Related - [CLI overview](index.md): the install channel, its assets, and the credentials it accepts. - [Authentication and profiles](authentication.md): getting a credential that the channel accepts. - [Devices](devices.md): updating the agents on your fleet.