Limitations & FAQ

Yes, currently. We may introduce paid plans in the future as the product grows, but there is no cost today. See Terms & Conditions for the full free-tool disclaimer (no SLA, no warranty, liability limited to zero).

No. The Service is offered best-effort, with no formal SLA for uptime or support response time.

Yes — every change to an environment is a versioned, immutable snapshot. Open History on the environment (web) or run envhq history / envhq rollback <version> (CLI) to restore an earlier version, bringing back anything deleted or changed since.

No — that's still permanent, with no undo, trash, or recovery path. Version history only covers changes to variables within an environment, not deleting the environment/project itself. If a secret matters, keep an independent backup of it (a password manager, a private vault, etc.) in addition to EnvHQ.

push does a three-way sync against the last-known state, not a blind overwrite: it adds new keys, updates changed ones, and only deletes a remote key if you removed it locally andit hasn't changed remotely since — and it'll ask for confirmation before deleting anything (skippable with --yes). Run envhq diff first to preview exactly what a push would do. And since every push is a version, you can always rollback if something still goes wrong.

No. Values are encrypted and decrypted client-side (in your browser or the CLI) under a key derived from your passphrase — the server only ever stores and transmits ciphertext, and never holds a key capable of decrypting it. Key names(project, environment, variable names) aren't encrypted, only values. See the Security model page for the full key hierarchy.

Use your recovery phrase (shown once, at setup) to unlock your account and set a new passphrase. If you've lost both your passphrase and your recovery phrase, your data is permanently unrecoverable — not even the operator can decrypt it for you. There is no other reset path, by design.

Yes. Create or switch to a team organization from the sidebar switcher, invite people (handled by Clerk's hosted invite UI under Teams), then use Manage access on a project to grant an org member — or a group of them, from Settings → Groups — Viewer, Editor, or Admin access. Org admins/owners get admin access to every project in the org automatically.

You can cap a grant per environment — e.g. Editor project-wide but Viewer-only on prod— from the expandable row under a grant on the project's "Manage access" page. There's no way to hide an environment from someone entirely while still granting the rest of the project; a cap restricts what they can do there, not whether they can see it exists.

Go to Settings → CLI Tokens in the web app and revoke it immediately. Then create a new one and update wherever the old one was used (e.g. CI secrets).

In a managed Postgres database (Neon); authentication is handled by Clerk. Values are stored encrypted, as described in the Security model.

That's your call, but weigh it against the limitations on this page — especially that deleting an entire environment or project is still unrecoverable, and that losing both your passphrase and recovery phrase means permanently losing that data — before relying on it as your sole store for anything business-critical.

The three-way sync engine, version history with rollback, team/organization access control with per-environment role caps, and zero-knowledge end-to-end encryption described elsewhere on this page and the Security model page have all shipped. Key-name/metadata encryption and DEK rotation on revoke (see the Security model page's "what's not covered today") are the main security gaps left open. This page will be updated as further pieces ship.