Capy vs AWS Secrets Manager

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 write 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. This comparison covers when Capy is the right AWS Secrets Manager alternative and when it isn't.

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.

Where an AWS Secrets Manager alternative is worth adding

If your runtime is entirely AWS, your team is small, and the secrets you actually deal with are mostly AWS-managed credentials, ASM by itself can carry the load. The dev-loop friction is real but tolerable, and you avoid introducing another tool. Once the runtime spans clouds (Vercel, Cloudflare, Fly, OpenAI, Anthropic) or once the dev loop has measurably eaten engineering time, the compose pattern above pays back quickly.

ASM stores plaintext, encrypted at rest with KMS keys you control. Within the AWS trust boundary, that's a strong posture; outside it, the keys are still managed by AWS. Capy stores ciphertext only via two-party encryption, which is relevant for the third-party API keys, customer-supplied secrets, and other values you'd rather not have on a vendor's infrastructure even encrypted. For those, Capy is the better home, and the deploy step bridges the two systems without either of them seeing what the other holds.

The deploy guide for AWS Lambda walks through the join in practice.