Configuration

Understand how the CLI chooses a workspace, project, environment, API endpoint, and credential.

Target resolution

Every secret command needs a workspace, project, and environment. Save the usual target with unbe use, then override individual parts with flags for one-off work.

Examples

unbe use -w acme -p api -e development
unbe secrets list --env production
unbe secrets list -w acme -p worker -e staging

Local and global config

Repository-local

The default for `unbe use`. It keeps each repository pointed at its own project and environment.

User-global

Pass `--global` when a target should be the fallback across repositories for the current user.

Local configuration is discovered by walking upward to the nearest.unbe directory. This is convenient in a monorepo, but it also means a parent configuration can affect nested directories.

Token precedence

1. UNBE_TOKEN
2. token in local .unbe/config.yaml or .unbe/config.json
3. token saved by the global login flow

Use UNBE_TOKEN for ephemeral CI and automation. A local token is useful when a repository must be constrained to a scoped, read-only credential. Interactive login manages only the global token.

API selection

Use --dev for the local development API or--api-url for an explicit host. These are intended for development and debugging; confirm the resolved host before changing production secrets.

Repository hygiene

Ignore local Unbe state

Add .unbe/ and any pulled secret files to.gitignore. Local configuration may contain target context or a token and should not be committed.