Stop handing your secrets to vendors who can read them.

What you get

Boring crypto. Sharp pricing. Honest scope.

Just shipped

Built for monorepos.

One envstore.json at the root of your repo, every .env file in it — apps, services, workers, whatever shape your repo has. envstore init walks the tree, registers one project per file, and tags them with a shared group so the dashboard renders the monorepo as a single thing.

{
  "workspace": "shinra",
  "files": [
    { "path": "apps/web/.env.local",   "project": "shinra-web",    "environment": "development" },
    { "path": "apps/api/.env",         "project": "shinra-api",    "environment": "development" },
    { "path": "apps/worker/.env",      "project": "shinra-worker", "environment": "development" }
  ]
}

$ envstore init
Found 3 .env files. Group them as a monorepo? Y
Group name: shinra
  shinra-web    -> apps/web/.env.local
  shinra-api    -> apps/api/.env
  shinra-worker -> apps/worker/.env
Wrote envstore.json (3 files).

$ envstore push           # encrypts & uploads every file
$ envstore push apps/web  # path-prefix filter
$ envstore sync           # reconcile when files change

• ✓envstore init walks the tree and proposes one project per .env file it finds
• ✓Apps stay as separate projects — apps/web is not an environment of apps/api
• ✓Project groups cluster monorepo siblings together in the dashboard and CLI listings
• ✓push and pull filter by path prefix, --project, or --env
• ✓envstore sync reconciles envstore.json with the filesystem, with --dry-run and --prune modes
• ✓envstore link <code> offers to register every .env file when joining an existing workspace

Comparison

envstore vs. the other vaults

We are not the right tool for every job. We are the right tool when "the vendor can't see it" is a non-negotiable.

FAQ

The honest answers

Wait — really, you can't read my secrets?

Correct. The CLI encrypts your file with age (X25519 + ChaCha20-Poly1305) on your machine to every workspace member's public key. We store the resulting ciphertext on Cloudflare R2. We do not hold any private key. There is no decrypt endpoint, no admin override, no support backdoor. If we wanted to read your file we would need to compromise your laptop, not our server.

What stops a compromised envstore from quietly adding its own key to your next push?

Nothing server-side — which is exactly why the CLI does. The very first push from a workstation prints every recipient it’s about to encrypt to and caches that set under ~/.config/envstore/trust.json. That first contact is trust-on-first-use, so we rely on you actually reading the list (or comparing it to a teammate’s) — but after that, if our API ever returns a public key your CLI hasn’t seen before, your push flags the new entry and waits for you to confirm before encrypting. In CI the push fails outright unless you’ve passed --trust-new. The “compromised server silently adds a key to read future pushes” attack is real in every end-to-end-encrypted vault that takes the server’s recipient list on faith. envstore surfaces it.

What happens if I lose my key?

Your data is gone. We tell you that loud and often. This is the tradeoff for a vendor that cannot read your secrets. We help you avoid it: the CLI prompts you to back up your identity on first run, supports multiple recipients per workspace, and re-encrypts on every push. A teammate or a second key on a yubikey gets you out of single-point-of-failure territory.

How is this different from Doppler, Infisical, Vault, 1Password Secrets?

Those products are good, but they all hold your keys. Their server has, at some layer, the capability to return plaintext — which means an internal compromise or a credential theft is a leak. envstore deliberately gives up that capability. The flip side: we cannot offer "click to reveal in the web UI" because there is nothing on the server to reveal. If you want a vault that can show you the value in a browser, those vendors are the right fit. If you want a vendor that cannot leak your secrets even when breached, you are in the right place.

My repo has six services in it. Do I have to register them by hand?

No. envstore init walks your tree, lists every .env file it finds, and registers all of them in one go. Each app becomes its own project (so secrets stay scoped) but they share a group, so the dashboard shows them as a single monorepo at a glance. After that, envstore push with no arguments encrypts and uploads every file; envstore push apps/web narrows by path. When you add a new .env tomorrow, envstore sync pulls it into the config.

How do I get secrets into CI without burning a real user identity?

Mint a workspace service token. The CLI generates the X25519 keypair on your laptop, registers the public part, and hands you the bearer token once. Pass ENVSTORE_TOKEN and ENVSTORE_IDENTITY as secrets to your runner — or use the bundled GitHub Action, which installs the binary (sha256-verified) and runs the pull for you. Tokens can't mint other tokens or change ACL, so the blast radius of a leak is the workspace's current ciphertext, nothing more.

My team needs to share .env files for staging and production. Does this work?

Yes — that is exactly the use case. Each workspace member registers their public key. Every push encrypts to all of them. Add a new member: the next push picks them up automatically. Remove a member: rotate by re-pushing. The CLI handles the bookkeeping; you handle the humans.

What does the web dashboard do, then?

Metadata only — projects, environments, member list, file names, sizes, timestamps, key fingerprints, audit log. You can manage your workspace and billing from the browser. You cannot decrypt anything from the browser. There is no "view file" button. We did not build one, and we are not going to.

Why AGPL v3 and not MIT?

Two reasons. First, AGPL lets us be open without giving away the ability to run the business — if a competitor hosts envstore as a service they have to share their changes back. Second, you can self-host today, with the same code we run. There is no proprietary "enterprise edition." If we ever get acquired and the new owner gets cute, you fork.

Is this production-ready?

envstore is early. The crypto primitives are not — they are age, an off-the-shelf, peer-reviewed format. The web app, billing, and CLI are new, and you should treat the service like any other early-stage product: keep a backup of your secrets in your password manager, watch the changelog, and tell us when something is wrong. We will earn the word "stable" by behaving like it.