Providers & Services¶

Providers¶

Each backend lives under a provider group; the group names take aliases:

Group	Aliases
`aws`	—
`gcloud`	`gcp`, `google`
`azure`	`az`

Group aliases are interchangeable with the group name (e.g. suve az kv show). Under azure stage, the secret / param subgroups take the same aliases as their read/write forms (kv / keyvault, appconfig / ac / appcfg).

Services¶

Each backend is a service under its provider group, with its own aliases:

Backend	Command	Aliases
AWS SSM Parameter Store	`aws param`	`ssm`, `ps`
AWS Secrets Manager	`aws secret`	`sm`, `secretsmanager`
Google Cloud Secret Manager	`gcloud secret`	`secrets`, `sm`
Azure Key Vault	`azure secret`	`kv`, `keyvault`
Azure App Configuration	`azure param`	`appconfig`, `ac`, `appcfg`

Staging is the same for every backend — <group> stage (alias stg), i.e. aws stage, gcloud stage, azure stage.

Bare form: when exactly one backend is active for a service (see Bare Aliases), drop the group prefix — every alias still works. So suve param / suve ssm, suve secret / suve kv, suve stage / suve stg, … resolve to the uniquely-active backend.

Bare Aliases¶

Every backend has an explicit command group that is always available, regardless of environment:

suve aws param    ...  # AWS Parameter Store
suve aws secret   ...  # AWS Secrets Manager
suve aws stage    ...  # AWS staging
suve gcloud secret ... # Google Cloud Secret Manager
suve gcloud stage  ... # Google Cloud staging
suve azure secret  ... # Azure Key Vault
suve azure param   ... # Azure App Configuration
suve azure stage   ... # Azure staging (secret = Key Vault, param = App Configuration)

For convenience, suve also exposes bare top-level aliases — suve param, suve secret, suve stage — but only when the environment makes the target unambiguous. param, secret, and stage are each resolved independently. All backends support staging, so stage follows the same "exactly one active backend" rule (Azure is staging-active when either AZURE_KEYVAULT_NAME or AZURE_APPCONFIG_NAME is set):

A backend is active when its identifying environment variable is set:

Backend	Active when set
AWS	`AWS_ACCESS_KEY_ID`, `AWS_VAULT`, `AWS_PROFILE`, `AWS_DEFAULT_PROFILE`, or an ambient-credential variable from AWS-managed compute (CloudShell / ECS / IRSA — see Cloud Shell Support)
Google Cloud	`GOOGLE_CLOUD_PROJECT`
Azure Key Vault (secret)	`AZURE_KEYVAULT_NAME`
Azure App Configuration (param)	`AZURE_APPCONFIG_NAME`

The bare alias for a service appears only when exactly one backend is active for it. Zero or two-plus active → no alias, use the explicit group. There is no priority order — ambiguity is never resolved silently.
AWS fallback: if no backend is active via env at all, AWS is accepted when ~/.aws/credentials (or $AWS_SHARED_CREDENTIALS_FILE) or ~/.aws/config (or $AWS_CONFIG_FILE) exists. If both are absent, there are no bare aliases.

Examples (— = alias not exposed):

Environment	`param` →	`secret` →	`stage` →
nothing set, `~/.aws/credentials` or `~/.aws/config` present	`aws`	`aws`	`aws`
`AWS_PROFILE`	`aws`	`aws`	`aws`
AWS CloudShell (`AWS_CONTAINER_CREDENTIALS_FULL_URI`)	`aws`	`aws`	`aws`
`GOOGLE_CLOUD_PROJECT`	—	`gcloud`	`gcloud`
`AZURE_KEYVAULT_NAME`	—	`azure`	`azure`
`AZURE_APPCONFIG_NAME`	`azure`	—	`azure`
`AWS_PROFILE` + `GOOGLE_CLOUD_PROJECT`	`aws`	— (ambiguous)	— (ambiguous)
nothing set, no credentials file	—	—	—

suve --help lists which aliases are active in the current environment.