Choosing services
Secrets
Environment and mounted files, encrypted in Postgres, Supabase Vault, HashiCorp Vault / OpenBao, AWS Secrets Manager, Azure Key Vault or Google Secret Manager, with secret:// references.
Credentials for the other providers (storage keys, SMTP passwords, client secrets, API keys, even ENCRYPTION_KEY) can live in a secret store instead of the environment or the database. Any provider option can be a reference, secret://name or secret://name#field. Resolved values are cached for SECRETS_CACHE_TTL_SECONDS (default 300), so rotations are picked up without a restart.
| Option | SECRETS_PROVIDER | On-prem | AWS | Azure | Google Cloud | Switch |
|---|---|---|---|---|---|---|
Environment, <VAR>_FILE, a mounted secrets directory | env (default) | yes | yes: ECS secrets, mounted files | yes: Container Apps secrets | yes: Cloud Run secret volumes | config |
Encrypted in Postgres (secrets.<name> instance settings) | db | yes | yes | yes | yes | config |
| Supabase Vault | supabase_vault | with a Supabase database | — | — | — | config |
| HashiCorp Vault / OpenBao (KV v2) | hashicorp_vault | yes | compatible: HCP Vault | compatible | compatible | config |
| AWS Secrets Manager | aws_secrets_manager | — | native | — | — | config |
| Azure Key Vault | azure_key_vault | — | — | native | — | config |
| Google Secret Manager | gcp_secret_manager | — | — | — | native, with regional endpoints | config |
When to pick which
- Environment / mounted files when your platform already injects secrets (Kubernetes Secrets, ECS task definitions, Docker secrets).
- Your cloud's secret store when the app runs in that cloud: it reaches the store with its own identity, and rotation and audit happen there.
- Vault / OpenBao on premises, or when one store serves several clouds.
dbfor small installs that want secrets out of the environment without another service.
Rules
- SDKs:
aws_secrets_manager,azure_key_vaultandgcp_secret_managerneed their optional SDK, included in the Docker image by default (Optional drivers). - Keep the store in the app's cloud (see multi-cloud). Credentials for other clouds then become references in it.
supabase_vaultneeds the Supabase database. Move secrets elsewhere before moving the database.- The switch checks that every
secret://reference in every area resolves in the new store before it writes anything. - Secret values are never printed by
status,doctoror the switch log.
bash
usertasks-admin switch secrets --to hashicorp_vault --set vault_addr=https://vault.internal:8200 --dry-runReference: Secrets.