AWS Secrets Manager vs Bitwarden Secrets Manager

AWS Secrets Manager

IAM roles support access without long-lived credentials on AWS compute services. Each API call is billed, making caching relevant to frequent reads.

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.

AWS Secrets Manager

1. Give the agent's task or instance role secretsmanager:GetSecretValue on the specific secret ARN, not a wildcard
2. Cache the value for the run, or read through the Workload Credentials Provider on localhost; each GetSecretValue is billed and logged
3. Use BatchGetSecretValue with a filter when you need several secrets at start-up; it's limited to 100 calls a second
4. Pass a ClientRequestToken on PutSecretValue so a retry can't create a second version, and don't write more than once every 10 minutes
5. Read VersionStage AWSPREVIOUS if a rotation lands mid-run and the new credential isn't live yet

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