Dotvault vs AWS Secrets Manager

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	One-time purchase, twelve months of updates included	Per secret per month + API call charges
Cloud dependency	None	AWS account required
Where secrets live	On your Mac as plain text; snapshot history encrypted	AWS Secrets Manager, inside your AWS account
Use case	Managing local .env files	Application runtime secret retrieval on AWS
Offline use	Every feature that touches your files; licensing checks in periodically	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 rotation can be automated, either with a Lambda function you write or, for the databases AWS supports directly, with managed rotation you just switch on. If you’re already all-in on AWS, it’s the path of least resistance.

The catch is the same thing, from the other side. The API is reachable from anywhere you can present AWS credentials, so “AWS-only” overstates it, but everything that makes Secrets Manager pleasant is AWS-shaped: IAM for auth, KMS for encryption, and the rotation and integration story built around AWS services. Run a meaningful part of your system somewhere else and you’re doing that work by hand, which is a fair reason to look at something cloud-neutral instead.

Dotvault doesn’t have a cloud dependency at all. Your .env files stay on your Mac, as the plain text your tooling needs them to be, and are never sent anywhere. Dotvault’s own snapshot history is encrypted at rest. 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 a single payment. 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, and an encrypted history of every version of the file.

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 an encrypted snapshot trail — 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.