About getmyenv

Last updated: September 28, 2026

Managing secrets as files was the problem

Environment variables are fine. The trouble is keeping them in files. A .env on disk is plaintext. It ends up in git history, chat logs, screenshots, and shared folders. Sharing means copying the file. There is no expire, no revoke inside the file itself, and no environment scopes. It is one blob for every machine that can read it.

The same problem shows up when one developer keeps many client or personal projects. Each folder grows its own plaintext .env. Secret storage becomes a pile of files across machines and repos. getmyenv keeps ciphertext in one place per project. Each app still reads ordinary environment variables.

What getmyenv keeps

The native environment interface. Your application still reads environment variables. Same code. No SDK.

What getmyenv adds

Encrypt in the browser or on your machine via the CLI. We store ciphertext only. Never your Vault password.
Projects with one list of variable names and a context for each place the app runs.
One command, getmyenv run, that checks every value is set before your app starts.
Open and Read-only contexts. New projects start with Development (open) and Production (Read-only). The CLI reads Production with a server token, from an allowlisted IP, on a trusted or approved machine. Only the owner sets Read-only values, in the dashboard.
Expiry: after the date, we stop providing the value.

Does not

See or store your Vault password.
Store readable values.
Require an SDK in your application.
Revoke credentials at third-party providers when you unset or expire a value in getmyenv.
Integrate with other secret stores. Chain them with run instead.

Open pilot