AWS Secrets Manager was designed for one job and does it well: deliver a secret, scoped by IAM, into an AWS-hosted runtime (a Lambda execution context, an ECS task, an EC2 instance) at the moment that runtime needs it. The rotation hooks are wired into AWS’s own managed services; an RDS password rotation runs a Lambda function that talks to the database and updates the stored value, and the next fetch returns the new credential. For RDS, Redshift, DocumentDB, and the other ASM-rotation-aware services, this is the right place to keep those secrets, full stop. What ASM was not designed for is the part of the secrets lifecycle that happens before any of that. Engineers don’t writeDocumentation Index
Fetch the complete documentation index at: https://capy.sc/docs/llms.txt
Use this file to discover all available pages before exploring further.
STRIPE_SECRET_KEY directly into the AWS console. They edit a value, share it with a teammate, push a change for review, and run their application locally. That whole loop, the human-and-CI side of every secret’s life, sits awkwardly on top of ASM, which assumes the secret already exists and the only question is how to fetch it.
At a glance
| Capy | AWS Secrets Manager | |
|---|---|---|
| What it’s built for | Developer and team .env workflow | AWS-runtime credential delivery |
| Where encryption happens | On the client, before any wire transit | On AWS infrastructure, encrypted at rest with KMS |
| What the service stores | Ciphertext only | Plaintext encrypted at rest with KMS keys you control |
| Vendor can decrypt | No — two-party wrap, no service-side path to plaintext | Yes — AWS holds the KMS keys |
| Removing a teammate | capy kick — cryptographic, no rotation needed | IAM permission change |
| Secret diffs in PR review | keep.lock manifest with hash references | Changes happen in the AWS console or API, outside the repo |
| Git-branch alignment | Branches pin to your git branches | Versions, not git branches |
| Reach across runtimes | Vercel, Cloudflare, Fly, Render, GitHub Actions, Docker, Lambda | AWS-hosted runtimes |
| Rotation hooks for AWS-managed services (RDS, etc.) | No — not the right tool | Yes — first-class support |
| AI-agent blast radius | Only what capy run -- is currently injecting | Whatever IAM-scoped fetches the agent process inherits |
Why most teams end up running both
The pattern most teams settle on is to use Capy for the human / dev / CI side of every secret and ASM for the runtime values that AWS itself rotates.capy edit and capy run cover the engineer’s local loop. capy deploy writes secrets into Lambda environment variables (or Vercel, Cloudflare, Fly, Render, or any deploy target your runtime spans) at deploy time, so the runtime read is process.env.STRIPE_SECRET_KEY rather than an SDK round-trip on every cold start. ASM, meanwhile, holds the AWS-rotated values that need AWS in their rotation loop (RDS credentials, IAM session tokens), and the application fetches them at request time for those.
Each system holds the kind of secret it is the right place to hold. Capy never sees your AWS-rotated database password. AWS never sees your third-party API keys. The trust boundaries stay tight in both directions.