Skip to content
Subako Docs
English
Esc
↑↓navigate↵open⌘Jpreview
On this page

The CLI

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

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

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:

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 shows, described in the agent config reference. config-example prints the smallest one that publishes:

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

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

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.

Vaults and keys

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

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 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.

Was this page helpful?