bootload
⚓ portal

📖 DOCS

Account security — 2FA & API keys

Lock down your account with two-factor authentication, and give CI pipelines and scripts their own scoped API keys instead of sharing your password. Both take a minute to set up from the CLI.

Two-factor authentication

Turn on TOTP two-factor so a password alone isn't enough to sign in:

bootload 2fa enable

You'll enroll an authenticator app (scan the secret, then confirm a code) and get a set of backup codes — each works once, shown only at enrollment, so save them somewhere safe. Check your status or turn it off (a current code is required) any time:

bootload 2fa status
bootload 2fa disable

Scoped API keys

For automation — CI, deploy scripts, cron — mint a dedicated API key with only the permissions it needs, rather than handing out broad access:

bootload token create ci-deploy \
  --scope projects:read \
  --scope services:read --scope services:write

Include projects:read on almost every key: most commands resolve an org/project/service by name before acting, and that lookup needs it — even when you're only touching a service. Without it you'll get 403 token lacks scope projects:read. A * login token has everything; scoped keys don't inherit projects:read implicitly.

The secret is shown once at creation — copy it then, because it's never displayed again.

Use the key directly with the CLI — no bootload login required, which is ideal for CI and scripts. Any of these work, in order of precedence:

bootload --token <key> status my-svc      # one-off, highest precedence
export BOOTLOAD_TOKEN=<key>; bootload …    # whole session / CI job
bootload login --token <key>               # save it like a login (future commands use it)

Or use it as a plain bearer token against the API — Authorization: Bearer <key> — from a curl script. A key only carries the scopes you granted it, so a command that needs more access returns 403 token lacks scope ….

List and revoke keys whenever you like:

bootload token list
bootload token revoke <id>

Revoking a key takes effect immediately — rotate one the moment you suspect it leaked.

Scopes

Scopes follow a resource:action shape, so a key carries exactly the access you grant — nothing more. The full set:

Scope Grants
projects:read list projects and resolve names to ids — nearly every command needs it
projects:write create projects, change project settings, run bootyard builds
services:read view services and their status
services:write deploy, scale, restart services
services:exec open a shell into a replica
deployments:read list deployments and rollouts
deployments:write trigger deployments and rollbacks
domains:read view domains and DNS records
domains:write manage custom domains, register and renew names
volumes:read view volumes
volumes:write create, resize, attach, delete volumes
backups:read list backups and download exports
backups:write take, restore, delete backups
secrets:read list secret names (values are never readable)
secrets:write set and delete secrets
registry:push push images to the hosted registry
registry:pull pull images from the hosted registry
smtp:read view managed-SMTP accounts and records
smtp:write create and rotate managed-SMTP accounts
inference call the OpenAI-compatible LLM gateway at /inference/v1; tokens are billed to the project wallet
billing:read view the wallet and ledger
billing:write top up and change payment settings
logs:read read service logs
metrics:read read usage metrics
usage:read read usage and cost breakdowns
tickets:read list and read your support tickets
tickets:write open, reply to, escalate and close tickets
apps:read browse the app library and your installs
apps:write review an app
partner:read partner programme: managed organizations, usage, settings
partner:write partner programme: create or suspend managed organizations

A key can never exceed your own access, and you can grant several scopes by repeating --scope. Prefer the narrowest set that gets the job done — a CI key that only deploys needs services:read/services:write, not your wallet.