Skip to main content
The CLI signs in with a SabaothCloud API key. It never uses your email and password. There are two ways to give it a key:

Create an API key

  1. In the dashboard, open API Keys in the sidebar.
  2. Click Create API Key, name it (for example laptop CLI) and choose its scopes.
  3. Copy the key. It starts with mpg_ and is shown only once.
The key can do only what your role in the organization allows. See API keys for scopes, expiry and revoking keys.

Log in interactively

The CLI asks for the key with a hidden prompt, so it isn’t shown on screen or saved in your shell history. Then it:
  1. Checks the key with the API before saving anything. A mistyped or revoked key never leaves a credential behind.
  2. Finds the organization the key gives access to.
  3. Saves the key in the OS keychain and selects that organization for later commands.

If the key covers more than one organization

If the key gives access to several organizations, the CLI won’t guess which one you mean. Pass --org:
Without --org, login fails with AMBIGUOUS_ORGANIZATION and lists the organization IDs you can choose from.

Signing in to several organizations

Run sabaoth login once for each organization. Each one gets its own keychain entry, and the most recent login becomes the selected organization. Switch between them with sabaoth org use.

Passing the key as a flag

This works, but the key ends up in your shell history, and the CLI warns you about that. Use the hidden prompt on your own machine and SABAOTH_API_KEY in automation.
When there is no terminal (for example, input is piped) and you haven’t passed --api-key, sabaoth login exits with code 2 and the error NO_TTY_FOR_PROMPT. It never reads a key from a pipe.

Use an environment variable

For CI pipelines, scripts and containers, set SABAOTH_API_KEY and skip login entirely:
When SABAOTH_API_KEY is set:
  • It takes priority over everything saved locally. Your saved login and organization selection are ignored completely, so a CI job can’t be affected by whatever happens to be selected on a developer’s machine.
  • The organization comes from the server. The CLI asks the API which organization the key belongs to. If the key covers more than one, pass --org on each command.
  • --org can’t widen access. If you pass an --org the key doesn’t cover, the command fails with ORGANIZATION_MISMATCH. It never quietly switches to a different organization.
  • No keychain is needed. This makes it the right choice for headless Linux machines and containers.
See Scripting and CI for full pipeline examples.
Store the key in your CI provider’s secret store, such as GitHub Actions secrets or GitLab CI/CD variables. Don’t commit it to a repository or write it into a Dockerfile.

Check who you are signed in as

This shows where the credential comes from (local context for your saved login, or SABAOTH_API_KEY), the selected organization, and every organization you have signed in to. It makes no network call and never prints a key. See sabaoth config.

Log out

Logging out removes the key from the keychain. It doesn’t revoke the key itself. To make a key permanently unusable, revoke it on the API Keys page. See sabaoth logout.

How the CLI treats your key

  • Keys are stored only in the OS keychain (service com.sabaothcloud.sabaoth). There is no plain-text fallback.
  • If the keychain is locked or unavailable, login fails with CREDENTIAL_STORE_UNAVAILABLE and saves nothing.
  • No command prints a key, in human or JSON output.
  • Every request sends the key to https://api.sabaothcloud.com as a bearer token, and to nowhere else.