Dotvault vs AWS Secrets Manager
Cloud-locked per-secret pricing versus local one-time-purchase tool
AWS Secrets Manager is the AWS-native answer for storing and retrieving secrets at runtime. If your application already runs on AWS and needs a database password at startup, Secrets Manager is designed exactly for that. Dotvault is something completely different — a macOS desktop app for managing the .env files on your own machine, before any of those values ever get near AWS. They don’t really compete. The question is which one (if either) you actually need.
Quick comparison
| Feature | Dotvault | AWS Secrets Manager |
|---|---|---|
| What it is | macOS desktop app for editing .env files | AWS-hosted secrets service for runtime retrieval |
| Pricing model | £29 one-time | Per secret per month + API call charges |
| Cloud dependency | None | AWS account required |
| Where secrets live | Encrypted on your Mac | AWS Secrets Manager, inside your AWS account |
| Use case | Managing local .env files | Application runtime secret retrieval on AWS |
| Offline use | Fully offline | Needs AWS reachability |
| Best for | Individual developer editing | AWS-hosted apps needing runtime secrets |
Cloud-locked versus local
AWS Secrets Manager lives inside AWS. That’s its strength and its catch. The strength is that if your app is already running in ECS, Lambda, EKS, or on an EC2 instance, pulling secrets from Secrets Manager at startup is close to effortless — IAM handles authentication, the AWS SDK handles retrieval, and rotations can be automated through AWS-native Lambda functions. If you’re already all-in on AWS, it’s the path of least resistance.
The catch is the same thing: it’s AWS-only. You’re paying to store your secrets in a service that only speaks usefully to AWS-hosted workloads. If part of your system runs outside AWS, or if you change cloud provider, Secrets Manager is not the secrets backbone you want.
Dotvault doesn’t have a cloud dependency at all. Your .env files live on your Mac, encrypted at rest via the macOS keychain, and never sent anywhere. There’s no account, no region, no IAM role, no per-API-call cost. It’s a desktop app that opens files that are already on your disk.
Pricing — per secret versus one purchase
AWS Secrets Manager’s pricing is straightforward but scales with usage: a small per-secret monthly charge plus a tiny charge per retrieval. On any serious production system those numbers are rounding errors in the AWS bill. On a personal project with a few .env files you’re poking at during development, they’re an annoying extra line item for no real benefit — you don’t need a cloud service to hold a Stripe test key that only ever runs on your laptop.
Dotvault’s pricing is £29 once. It doesn’t scale with how many secrets you have, how many files, how many times you open the app, or how many projects you use it on. That fixed cost is better for individual developers and small projects. For a team running thousands of secrets in production, AWS Secrets Manager’s ongoing cost is trivial — and Dotvault isn’t even trying to solve that problem.
The right pricing model depends entirely on what you’re doing. Runtime secrets infrastructure at production scale and local editing of a handful of .env files are not the same problem.
Where each fits
Think of the lifecycle of a secret. Somewhere, someone writes down the value — maybe copied from a provider’s dashboard, maybe generated by a rotation job. That value gets stored somewhere canonical. Later, an app retrieves it at startup and uses it to talk to a database or an API.
AWS Secrets Manager fits the “stored somewhere canonical” and “retrieved at runtime” parts of that lifecycle for AWS workloads. Policies, audit logs, automated rotation, KMS-backed encryption — the whole shape of a piece of infrastructure.
Dotvault fits the “I’m editing my local .env.local” part of the lifecycle. It has no opinion about how those secrets reached you, and no involvement in how they reach your production environment later. Its only job is to make the local editing experience less fiddly — snapshots, diffs, framework awareness, encryption at rest on your Mac.
The two coexist fine. A developer working on an AWS-hosted app might pull production secrets from Secrets Manager for staging tests while using Dotvault to manage the local .env that drives their own dev environment.
Who should use which
Use AWS Secrets Manager if your application runs on AWS, needs to fetch secrets at runtime, and would benefit from IAM-gated access, automated rotation, and AWS-native integration. Its pricing makes sense once you’re operating at any real scale.
Use Dotvault if you’re editing .env files locally on a Mac and want a proper editor for them — with history, diffs, and encryption at rest — that doesn’t require a cloud account to run and doesn’t charge per secret. One-time purchase, no account, no AWS involvement.
If you’re already using AWS Secrets Manager in production, Dotvault doesn’t replace it — it just makes the local side of your workflow better. And if you’re not running on AWS at all, Secrets Manager isn’t really on the table, and Dotvault is a reasonable starting point for the local editing problem whether or not you adopt a cloud secrets service later.