Install

View on GitHub

The keylight CLI manages your account from a terminal instead of the dashboard: apps, key types, licenses, customers, payment integrations, and usage. It is the same management API the dashboard uses, so anything you do here shows up there.

It is also built to be run by something other than a person. No command opens a prompt, every input is a flag, and every command speaks --json — so a coding agent or a CI job can drive the whole surface. See Commands for what that surface covers.

Note

Flag names and human-readable output can change while the CLI is on 0.x. The --json output and the exit codes are the parts to script against.

Install

Homebrew

brew tap keylight-dev/tap
brew trust keylight-dev/tap
brew install keylight

The brew trust step is not specific to Keylight. Since Homebrew 6, a formula from any third-party tap refuses to load until you trust it, and there is no prompt to click through. It is a supply-chain control worth having — a tap is Ruby that runs on your machine, so read the formula first if you like. It is about sixty lines and downloads a published release binary.

Cargo

cargo install keylight-cli

Requires Rust 1.85 or newer. The crate is keylight-cli; the binary it installs is keylight.

Prebuilt binary

Download for macOS (Apple Silicon), Linux (x86_64), or Windows (x86_64) from the releases page.

Caution

The macOS release binaries are not yet signed or notarized, so Gatekeeper blocks them on first run. Clear the quarantine flag with xattr -d com.apple.quarantine ./keylight, or install with Homebrew or Cargo, neither of which has the problem.

Sign in

keylight login

This prints a short code and opens your browser. Check the code on the page matches the one in your terminal, choose what the CLI may do, and approve. The token is then stored on your machine.

That match matters: it is what proves the request came from the session you started, and it is why the flow is safe on a machine you do not fully control. The browser never needs to reach the CLI, so this also works over SSH and on headless machines.

keylight products list   # confirm it worked

Narrowing what it can do

keylight login asks for every non-destructive permission by default. Narrow it by repeating --scope:

keylight login --scope licenses:read --scope usage:read

You can also untick permissions on the approval page. Destructive access (danger) is never requested by default and has to be switched on there deliberately — see confirm-gated operations.

Check what the current token resolves to at any time:

keylight auth status

CI and agents

Set an environment variable instead of logging in. It always wins over the stored config, and nothing is read from or written to disk:

export KEYLIGHT_API_TOKEN=klm_...
keylight licenses list --json

Create tokens in the dashboard under Settings → API tokens. Each carries a fixed set of scopes chosen at creation.

To store a token by hand instead, pipe it in:

echo "$KEYLIGHT_TOKEN" | keylight auth set-token

Read from stdin, never as an argument — arguments land in shell history and are visible to other users through ps. The same reasoning applies to the two commands that need provider secrets: they read named environment variables rather than accepting the secret on the command line.

Exit codes

Code	Meaning
0	Success
1	Everything else
2	Not authenticated, or the token lacks the required scope. Re-run keylight login.
3	A confirmation was denied or expired

2 is broken out from the rest because “you need to authenticate” is the one failure an unattended caller can resolve on its own.

Sign out

keylight logout

Revokes the token on the server and deletes the local copy. If the revoke call cannot be made — you are offline, or the token was already revoked — the local copy is still removed and the output says so, rather than leaving a credential on disk you believe is gone.