Security
What getmyenv stores and never sees, what each file or leak exposes, the named crypto primitives, and how tokens and contexts limit access.
Last updated: 2026-10-11
What we store
We store ciphertext, encrypted key blobs, public keys, and metadata: project, context, and variable names, and activity. We never store your Vault password, your recovery code or readable values. Webhooks and activity carry names only. Audit logs redact values.
Hosted only. The CLI, shared and crypto packages are MIT, so you can read the code that encrypts your values.
What each file or leak exposes
- A copy of our database: ciphertext, sealed context keys, and private keys encrypted with Vault passwords and recovery codes. No readable values.
- Your recovery code: with your account's encrypted key blob, it opens your vault like the Vault password. Make a new one in Settings, Security. The old one stops opening the vault, but still opens backups made while it was in effect.
.getmyenv/token.json: API access to the open contexts of one project. It returns ciphertext only. Values need the Vault password. Revoke it in Project settings, Tokens.- A server token: its one context, from allowlisted IPs, on trusted or approved machines. It holds that context's key, so it reads those values.
.getmyenv/claim.json: the passphrase for a guest project. With the guest token it reads that project's values. It is removed at claim.- A machine key (in
GETMYENV_CONFIG_DIR): identifies the machine for Read-only contexts. It does not decrypt values. - The process run starts: The process that run starts gets readable values as environment variables, and so do its child processes. export writes them to a plaintext file.
- Unlocked keys: The dashboard unlocks the vault per browser tab, in memory. Reload, close the tab, or Lock, and the keys are gone. The CLI keeps context keys in the OS keychain for 8 hours, or until
npx getmyenv lock.
Named primitives
One Vault password per account. It unlocks your encrypted private key on your device. Your private key opens the context keys shared with you. Each context has its own random key. Each reader (you, each member, each server token) gets their own sealed copy. The recovery code unlocks the same private key.
A member has their own key pair and their own Vault password. A server token carries its own private key. Each opens only its own sealed copy of a context key. No reader uses another reader's private key.
Vault encryption uses standard primitives:
- Argon2id derives a key from your Vault password. It encrypts your account's X25519 private key (RFC 9106). Your recovery code, 128 random bits, encrypts the same private key a second time, with its own Argon2id salt.
- AES-256-GCM encrypts each value under its context key, bound to the variable name (NIST SP 800-38D).
- X25519, HKDF-SHA256 and AES-256-GCM seal each random 32-byte context key to a public key: your account, a member you shared the context with, or a server token for that context.
- Libraries:
@noble/ciphers,@noble/curves,@noble/hashes,hash-wasm.
Tokens
- Folder: made by browser sign-in in a folder, or in Project settings, Tokens. Reads and writes open contexts of one project. On a shared project, only the contexts shared with you.
- Guest: made by
guest. Development only. A guest project stays active while the CLI uses it. After 30 days without use, or 180 days after it was created, values can't change. For 30 more days, run still works and it can still be claimed. Unclaimed projects may be deleted after that. - Server: made in Project settings, Tokens. Reads one context, from allowlisted IPs, on a trusted or approved machine. Holds that context's key, so it never needs the Vault password.
Tokens last up to 1 year. Revoke them in Project settings, Tokens, or with npx getmyenv unlink in the folder.
Revoking stops new reads. A running process keeps the values it started with until it restarts. If a server is compromised.
Sharing
Each member gets their own copy of a context key, sealed to their public key by the owner's browser. We store sealed keys only. Keys are sealed the next time the owner unlocks the vault. The owner can compare the member's key fingerprint to confirm the key is theirs. Removing a member rotates the keys by default, so their old copy stops working. How sharing works.
Vault reset
Lost the Vault password and the recovery code? Choose "Forgot your Vault password?" and reset the vault. Names, contexts and members stay. Values only you could open are deleted, and you set them again. Contexts a member or server token still reads keep their values until you reset them.
A reset needs a login code and never grants access. The new key gets no copy of an existing context key. Other browsers are signed out in the same step. Owners do not send keys to a member who reset their vault until they check the new key fingerprint and send them by hand. A key sealed to the old public key is refused. If you forget the password. Three kinds of recovery.
Sign-in and browsers
- Login codes: too many wrong codes for one email from one IP pause sign-in by code from that IP for a while. Each code takes a few tries, and an email gets a limited number of codes a day, so guessing from many IPs stays slow. Someone else cannot pause sign-in from your own IP.
- Passkeys: add one in Settings, Security, then sign in with your fingerprint, face or device PIN. A passkey sign-in counts as two factors, so it skips the authenticator code. Login codes, GitHub and Google still ask for it. Adding or removing a passkey asks you to confirm it is you first.
- CLI sign-in: the page does not show the code. You type the code from your own terminal, so a sign-in link sent by someone else cannot be approved with one click.
- Analytics loads on public pages only. It never loads on sign-in, signup, claim or the dashboard, where the vault unlocks.
- Settings, Security, Browsers lists the browsers remembered for your account. Forget one, or Sign out everywhere else.
- Signing out other browsers also forgets them as remembered browsers, so they need a login code again. It happens with Sign out everywhere else, a vault reset, turning two-factor on or off, and unlinking GitHub or Google.
Guest projects and claim.json
Until claim, the claim code and guest passphrase live in .getmyenv/claim.json. It opens the guest vault. It stays in the project folder and is gitignored. At a terminal, guest prints the claim code and guest passphrase once. Run by an agent or a script, it prints neither, and claim.json is the only copy. If the folder is lost before claim, the project cannot be claimed. After claim, the context keys are sealed to your account and claim.json is removed.
The claim link carries the claim code after #, so it never reaches the server or proxy logs. The page also asks for the code the terminal prints. A claim link sent by someone else cannot be approved with one click.
Keep claim.json private. Do not print it, paste it in chat, or add it to git. The human runs npx getmyenv claim in the same folder, and claim reads it.
Platform and admin
MFA is optional for your account. getmyenv staff accounts must use MFA. Every admin action is logged. Admins never see readable values.
No compliance claims
getmyenv does not claim any specific compliance standard.