API keys
What the CLI, an agent and docker login authenticate with. Self-service, shown once, revocable at any time — including the last one.
An API key is a bearer token carried as Authorization: Bearer <key>,
and it is what every non-browser client uses: the CLI, an MCP client,
docker login at the instance's registry (username plus the key as the
password), a CI job calling the API.
Making one
On Account → API keys, or:
cubeship user api-key create laptop
cubeship user api-key list
cubeship user api-key revoke 3
cubeship user api-key rotate # replaces the key this CLI is usingA key is shown once. Only its hash is stored, so nothing can hand it
back; a key that was lost is revoked and replaced. Keys are named
(laptop, ci, mcp) so the list says what each is for, and an
account may hold any number.
The first account gets no key at setup: keys are self-service, and one nobody is shown would be a live credential lying around for nothing.
Revoking is never refused
Including the last one. A key that has leaked has to be able to go now, and being made to mint a replacement first would keep the leaked one live for as long as that took. What replaces the refusal is knowing: the account screen says what revoking this one costs — the CLI until you make another, or, for an account with no password, the way in — and asks.
Rotating
rotate revokes the key the CLI is signed in with and issues a new one
in its place, saving it locally. docker login sessions using the old
key stop working.
What a key may do
A key carries all of its owner's access unless it is given an access role. Then it reaches what the role grants and its owner reaches — a role never widens a key.
cubeship role list
cubeship user api-key create claude --role "Read only"
cubeship user api-key create ci --role DeployThe limit is in the key, not in the prompt. Over MCP a key is not offered a tool its role does not allow — an agent cannot be talked into calling what it was never shown — and every call is decided by the daemon anyway. A role naming projects reaches only those; one whose projects were all deleted reaches none of them, never all.
A key with a role cannot make one that reaches more than it does, cannot revoke keys and cannot change the password. Rotating keeps the role, and a key asked for by name alone gets the caller's own. What every key did is in the audit log.
The owner decides the ceiling
Blocking the owner refuses every key at the door; deleting the owner deletes them; changing the owner's role changes what every key of theirs reaches, from the next request.
Through an agent
create_api_key (with role), list_roles, list_api_keys, revoke_api_key and
rotate_my_api_key are in the tool reference.