The CLI
Everything the dashboard can do, from a terminal.
The saved CLI is not a subset of the dashboard. Anything you can do in the browser you can
do here, because both call the same API.
Signing in
saved login # device code: prints a code, you approve it in a browser
saved auth whoami # who am I, and in which workspaceThe session lives in a config file at $XDG_CONFIG_HOME/sctl/config.yaml, mode 0600.
Switching workspace re-mints your token into that workspace, so every command acts on
exactly one workspace, the one your session is scoped to.
saved workspace list
saved workspace switch analytics
saved workspace currentCommand surface
| Command | Covers |
|---|---|
login | Device-code sign-in |
auth | Session state (whoami) |
workspace | List, create, switch, current |
member | Membership and invitations |
role | Custom roles and their permission bundles |
apikey | Org-scoped API and SDK keys |
worker | Provision, list, rotate, delete |
backup | Create, configure, trigger, pause, resume, delete, submit |
run | History: run list --backup, run get |
artifact | List, get, download, delete |
restore | Client-side restore of an artifact |
apply | Reconcile a YAML manifest |
Two things that look like omissions and are not:
backup createtakes--kind;backup configuredoes not. Kind is immutable after creation, so there is no field to patch.- There is no
artifact lock. Protection is a property of the backup's retention policy (--lock-for), stamped onto each artifact as it is archived. A per-artifact lock would be a second source of truth for the same guarantee.
Automation
For CI, use an API key rather than your own session. It is scoped to exactly the permissions you grant it, and revoking it does not sign you out.
saved apikey create ci-backups --permissions backups:trigger,runs:read
export SAVED_API_KEY=...
saved backup trigger prod-dbA key with backups:trigger and nothing else is refused if it tries to delete an artifact,
and the refusal names the permission it lacked rather than returning a bare 403.
Declarative
saved apply -f saved.yamlapply reconciles what the file declares and never deletes what the file omits. Removing
something is always explicit:
saved backup delete prod-dbThat asymmetry is deliberate. A file is easy to typo, easy to check out at the wrong revision, and easy to run from the wrong directory; none of those should be able to destroy a retention policy.