StoreEnv Beta
Product

Eight things, most of them borrowed from Git: a folder that finds its project, working anywhere, encryption, sharing, history, imports, signed writes and an open client. The CLI does all of them. The dashboard covers sharing, history, imports and signing. The VS Code extension pushes, pulls, keeps local commits and rolls back through the CLI, so everything it reads is checked the same way.

01 Find

A small .storeenv.json committed with your code names the project. Without one, StoreEnv looks for a project linked to one of the folder's remotes, and the repository's first commit can suggest one. Folders become services and file suffixes become environments.

  • .storeenv.json first, then linked remotes, then a first commit suggestion
  • Monorepos (apps/*, packages/*)
  • .env, .env.local, .env.production and any other suffix
  • Status works offline from a local cache of keyed hashes
$ storeenv status
  On project acme/cakeshop   (signed in as @tushar)
  Remote has a newer version on production (v 3b7e0d4 by @neha, 2h ago)
 
  Changes not pushed:
    backend/.env   ~ JWT_SECRET   + SENTRY_DSN
02 Anywhere

A project needs a name, not a repository. Start in any folder; if it's a Git repository, commit .storeenv.json and everyone who clones the code lands in the same project. Linking a remote is optional, on any host.

  • Any folder, with or without Git
  • Remotes on any host are optional links
  • Branch rules can pick the environment
  • Sign in with email, or an optional provider
$ storeenv init
  Created acme/cakeshop  prj_9f2c41d07a6b8e3d1c0f5a72
$ storeenv push
  Project    acme/cakeshop
  Scanning   2 env files
03 Protect

Each secret gets its own key and is sealed with AES-256-GCM. The scanner warns about live provider keys, malformed lines and env files that Git is tracking.

  • One key per secret, wrapped per reader
  • Identity from a 24-word recovery phrase
  • Private key kept behind your OS keychain
  • Ciphertexts are bound to their location
$ storeenv scan
  Scanned 3 env files, 22 keys.
  [warn] RAZORPAY_KEY_SECRET looks like a Razorpay live key (rzp_live_...)
  [warn] backend/.env line 14: duplicate key PORT (last value wins)
04 Share

Access goes down to a single secret. A contractor's pull writes only the keys they were given. When access ends, the secrets they could read get new keys.

  • Roles: owner, admin, editor, viewer
  • Production needs a separate flag
  • Temporary access that ends by itself
  • Repository collaborators are only suggested
$ storeenv invite @bob --role viewer \
    --keys backend/.env.production:DB_HOST,DB_USER --expires 7d
  Invitation sent to @bob (access expires in 7d).
 
$ storeenv revoke @bob
  @bob can no longer read acme/cakeshop.
  ! They may have copied these values. Rotate them at the provider:
05 Remember

Every push records who changed which keys and why. Compare any two versions and roll back in one step. History only moves forward.

  • Key-level diffs, values only on reveal
  • Rollback creates a new version
  • Templates generated from real files
  • Activity log for pushes, reveals and grants
$ storeenv log --env production -n 3
  3b7e0d4  Added Razorpay keys   production  @tushar  2h ago   +2
  a19c55e  Rotate JWT secret     production  @neha    3d ago   ~1
  7d02f9b  Initial push          production  @tushar  12d ago  +12
06 Import

Keep shared keys in a library project and import its environment where you need it. Nothing is copied: every pull checks the person's access at the library, so a rotation there reaches every importer.

  • Filter to the keys you need (--only)
  • Follow the latest version or pin one
  • Access checked at the source on every pull
  • Your own keys always win
$ storeenv import add acme/shared-stripe --env production --only STRIPE_KEY
  acme/cakeshop production now imports acme/shared-stripe production (STRIPE_KEY).
  Each teammate gets these values only if they can read the source themselves.
07 Signed

Each value is signed by the device that wrote it, and devices are certified by your account. Clients check those signatures against a key log before using a value, and storeenv run refuses values it can't verify.

  • Device keys certified by your account key
  • Append only key log, checked against signed heads
  • run and copy refuse unsigned or untrusted values
  • Known limits are listed in the docs, plainly
$ storeenv run -- node server.js
  API_KEY isn't signed by its writer, so StoreEnv can't tell it
  from a forgery. Nothing was run.
08 Open

The CLI and its encryption library are open source under Apache-2.0, with protocol test vectors, at github.com/tusharrr0302/storeenv-cli. Each release carries build provenance. The hosted server stays private.

  • Client source and test vectors are public
  • Release archives and the npm package carry provenance
  • Values are encrypted before they reach the server
  • The server only stores ciphertext, wrapped keys and public keys
$ npm view storeenv-cli dist.attestations.url
  https://registry.npmjs.org/-/npm/v1/attestations/storeenv-cli@0.2.2

Honest comparisons with Doppler, Infisical and Vault, including when the other tool is the better choice.

Compare StoreEnv