Bitwarden Secrets Manager vs Google Cloud Secret Manager

Bitwarden Secrets Manager

End-to-end encrypted, decrypted only on the client that holds the token. No release since 22 May 2026, and the npm SDK is still 1.0.0 from September 2024.

Google Cloud Secret Manager

Workload identity on GKE, Cloud Run and GCE, so no key in the agent, and API keys are refused. Managed rotation only covers Cloud SQL; other rotation is a Pub/Sub notification you handle.

Bitwarden Secrets Manager

1. Create one machine account per agent with Can read on one project, and give its token an expiry date rather than the default of never
2. Run the agent under bws run -- <cmd> so secrets arrive as environment variables and aren't written to disk or into the context
3. Fetch with bws secret list <project-id> --output json once per run; bws secret get needs the secret's UUID, not its name
4. Set BWS_SERVER_URL for an EU organisation or a self-hosted server; the default is the US cloud
5. Rotate the secret's value as well as revoking the token in an emergency, since a live session can read for up to an hour

Google Cloud Secret Manager

1. Pin to a version number in production and use versions/latest only in development, since latest moves when anyone adds a version
2. Grant roles/secretmanager.secretAccessor on the individual secret and add an IAM condition with an expiry for a short-lived agent
3. Turn on Data Access audit logs for secretmanager.googleapis.com if you need a record of each read
4. Read once per run and cache; accesses past 10,000 a month are metered
5. Use a regional secret (projects/*/locations/*/secrets/*) when the data must stay in one place, and note the higher write quota there