---
title: The CLI
description: Do from a terminal or CI what the console does.
---

The console is the place to build and try an agent. Once it works, the `subako` CLI does the same from a terminal: configuration that lives in files can be reviewed in a pull request, and published by CI the same way in every environment.

## Install

```bash
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/subako-ai/subako-cli/releases/latest/download/subako-cli-installer.sh | sh
```

The installer puts `subako` in `$XDG_BIN_HOME` when you have one set, and `~/.local/bin` otherwise. It runs on macOS and Linux.

## Sign in

```bash
subako login --org acme
subako whoami
```

Signing in opens your browser on the organization's sign-in page — the same sign-in as the console's — and stores the credential in `~/.config/subako/credentials.json`. `--profile` stores it under another name, so several organizations, or a staging and a production login, sit side by side; `subako profile list` and `subako profile use` move between them.

Select a workspace once, and later commands act in it:

```bash
subako workspace list
subako workspace use production
```

`subako cloud signup --org <handle> --name <name>` creates an organization from the terminal, as the console's sign-up does.

## Agents

An agent version is a JSON document: the same fields the [version editor](/console/agents#the-version-editor) shows, described in the [agent config reference](/reference/agent-config). `config-example` prints the smallest one that publishes:

```bash
subako agent config-example --format openai_responses > agent.json
subako model-provider list           # the provider id, and its models
subako agent create --name support-triage
subako agent publish <agent-id> --config agent.json --model-provider <provider-id>
subako agent versions <agent-id>
```

The provider is named at publish time rather than in the file, so one file publishes to staging and production alike.

## Skills

```bash
subako skill create ./refund-policy      # a folder with SKILL.md at its root; version 1
subako skill push <skill-id> ./refund-policy
subako skill list
```

## Functions

```bash
subako function create dist/orders.tar.gz         # version 1
subako function push <function-id> dist/orders.tar.gz
subako function list
```

Either takes the bundle's directory in place of its archive. See [Packages and versions](/functions/packages).

## Vaults and keys

Secrets are read from stdin, never from a flag, so they stay out of your shell history and the process list:

```bash
subako vault create --display-name "Acme production"
subako vault add-credential <vault-id> --protocol mcp \
  --target https://mcp.acme.example/orders --display-name "Orders" < credential.json

subako api-key mint --label "support backend" \
  --permission session.create --permission session.read --permission session.manage
```

## In CI

The CLI authenticates as a person, with the stored login. For CI, point `--credentials-file` (or `SUBAKO_CREDENTIALS_FILE`) at a credentials file kept as a secret, or call the API directly with an [API key](/console/api-keys) that holds the permissions the job needs. `subako token` prints the signed-in credential as JSON, for a program of your own that calls the API as you.

Every command, flag, and argument is in the [CLI reference](/cli).