# Update kli


`kli update` replaces your installed binary with a newer release built from [github.com/kleisli-io/kli](https://github.com/kleisli-io/kli). It downloads the release for your platform, verifies it against the release checksums, and swaps it into place. If the new binary fails to run, kli restores the previous one before it returns.

This applies to a binary you installed with the install script (`curl -fsSL https://kli.kleisli.io | sh`). If you installed through Nix, update through Nix instead; see [Refuses a Nix-managed binary](#refuses-a-nix-managed-binary).

## Update to the latest release

Run:

```sh
kli update
```

kli queries GitHub for the latest release tag, compares it to the running version, and shows what it found:

```
  current: v0.3.1
  new:     v0.4.0

Proceed? [Y/n]
```

Press Enter or `y` to continue. An empty line counts as yes. When the update finishes, kli prints:

```
kli updated to v0.4.0.
```

If you are already on the latest release, kli prints `Already up to date (v0.4.0).` for that version and exits without downloading anything. If you decline the prompt, it prints `Update cancelled.`

## Update without the prompt

Pass `--yes` (or `-y`) to skip the confirmation. This is the form to use in a script or a `cron` job:

```sh
kli update --yes
```

The version check still runs, so an up-to-date binary stays untouched.

## Install a specific version

Pass `--version` with a release tag to install that release instead of the latest:

```sh
kli update --version v0.3.0
```

The tag must match a published release on [github.com/kleisli-io/kli](https://github.com/kleisli-io/kli); kli validates it against the releases endpoint before downloading and fails if no such release exists. This works for both upgrades and downgrades. Combine it with `--yes` to install a pinned version unattended:

```sh
kli update --version v0.3.0 --yes
```

## What an update does

`kli update` keeps your current install in a `.bak` sibling directory while it activates the new release, so a failure rolls back to it:

1. It downloads the release archive for your platform and checks it against the release `checksums.txt`. A mismatch aborts the update with the bytes left untouched.
2. It moves your current install aside to a `.bak` directory and moves the new files into place.
3. It runs the freshly installed binary's `version` command. On success, it deletes the `.bak` backup.
4. If the new binary does not run, kli deletes the broken install, renames the `.bak` backup back into place, and reports `the updated binary failed to run; rolled back`.

You keep a working kli whether the update succeeds or fails. There is no half-installed state to clean up.

## Refuses a Nix-managed binary

A kli installed through Nix lives under a read-only store path, and the package, not the updater, owns that file. `kli update` refuses such a binary and prints:

```
kli is managed by Nix; update through your Nix configuration instead.
```

Bump the version in your Nix configuration and rebuild to update a Nix-managed kli. See [Installation](/kli/cli/installation) for the install methods and which one you have.