# dotenvx alternative: Crunu vs encrypted .env files > Crunu and dotenvx compared: who holds the private key, giving and removing access, CI, audit and Armor, checked against the dotenvx README and pricing. URL: https://crunu.com/alternatives/dotenvx Language: en Updated: 2026-10-30 dotenvx encrypts the values in your .env files with a keypair per file, so they can be committed with your code; anyone holding a file's private key can read it. Crunu keeps environments out of the repository and seals each environment key to each person, machine and pipeline, so access is removed per recipient. The difference between dotenvx and Crunu is who holds the private key. dotenvx encrypts each value in a `.env` file with that file's public key, so the encrypted file can be committed and shipped with your code; the matching private key, such as `DOTENV_PRIVATE_KEY_PRODUCTION` for `.env.production`, decrypts it wherever it is set. Crunu has no key to pass around: each environment key is sealed separately to every person, machine and pipeline allowed to read it, and none of them ever sees anyone else's key. dotenvx is a clever, small design built from tools developers already use: Git, `.env` files and public-key cryptography. This page is about what changes when a team, not one developer, has to manage who holds those private keys. > **Note:** Crunu wrote this comparison. We checked every statement about dotenvx against its README, documentation and pricing page on October 30, 2026, and the sources are listed with this page. If something is out of date, tell us at . ## Who each one fits **dotenvx fits** developers and small teams who like `.env` files and want them encrypted in Git, with nothing to run. One private key per environment on the server, in CI or in your OS keychain is all your infrastructure needs. The core CLI is open source under the BSD 3-Clause license, and there are SDKs for several languages. Its paid service, Dotenvx Armor, adds key custody, team access, approvals and audit on top. **Crunu fits** teams where several people, servers and pipelines read different environments and the list changes. Nobody receives a copy of a production key to keep in a password manager. Each recipient gets its own sealed copy of only the environments it needs, and a departure rotates those keys in one step. ## Side by side | | dotenvx | Crunu | | --------------------- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Where secrets live | Encrypted values in `.env` files committed with your code | Environments in a vault outside your repository, stored as ciphertext | | Who can decrypt | Whoever holds the file's private key; paid Armor can move keys off devices and lists server-side decryption | Only the people, machines and pipelines an environment key is sealed to | | Keys per environment | Each `.env` file has its own keypair, such as `DOTENV_PRIVATE_KEY_PRODUCTION` | Each environment has its own key, sealed separately to each recipient's public key | | Giving someone access | Share the private key, or with Armor share access without the key | An invitation, a fingerprint check with an admin, and a role on each environment | | Removing someone | Armor plans list a key rotation command; re-keying when a member leaves is not documented | Removal rotates the keys of every environment they could read and lists the values to reissue | | CI pipelines | The GitHub Actions guide encrypts with an Armor Enclaved Key and reads `DOTENV_PRIVATE_KEY_CI` from Actions secrets | Service tokens limited to chosen environments, optionally bound by OIDC to a repository, branch and deployment environment | | Record of access | Paid Armor can audit every decrypt | Hash-chained organization log, 365 days by default, with a record of which versions each person received | | Where keys are kept | A local `.env.keys` file, the OS secret store, a password manager, or Armor | Account keys on your devices, from your password and Secret Key; machine keys with the agent | | Platforms | CLI and SDKs, with key stores for macOS, Windows and Linux | Web app, plus a CLI and agent for Linux and macOS | | Source code | Core CLI open source under BSD 3-Clause; Armor is a paid service | Not published | | Price | Core free; Armor plans billed monthly by seats and included usage, with a 5-day trial on Member | Free during early access in the Crunu cloud; self-hosting on the Enterprise plan | ## Who holds the private key In dotenvx, the private key is the access list. Whoever has `DOTENV_PRIVATE_KEY_PRODUCTION` can decrypt `.env.production`, from any copy of the repository, including every commit in its history. Giving a new teammate production access means giving them that key. dotenvx does not document a re-key for when someone leaves. With the core CLI, the way to keep an old key from reading future changes is a new keypair, a re-encrypted file, and the new key replaced everywhere the old one was set: laptops, servers and every CI secret that held it. Dotenvx Armor lets a team share access without sharing the private key, but that is a paid service with its own trust model. *Figure: Diagram of who can decrypt dotenvx values, split into your side and the provider side. On your side, anyone with the file key can decrypt. The Git host and backups keep only encrypted files.* Crunu starts from the other end. A developer with access to development holds the development key and nothing else, so they cannot read production even with a full copy of the database. Machines and pipelines get their own keys too. When someone leaves, the [member removal flow](https://crunu.com/features/offboarding) rotates every environment key they held, shows which versions they received and when, and lists the values to reissue at each provider. Nobody has to redistribute a new private key to everyone who stays. *Figure: Each environment of payments-api at Kiteline, a fictional company, has its own key, sealed only to those on its access list. Jonas Lindqvist is an editor on development and staging through the Developers access profile, so those two keys are sealed to his key. The production list has Amara Okafor as a reader and the machine api-prod-1, but not Jonas, so nothing he holds opens production.* The trade-off is that Crunu always involves a server. It stores only ciphertext and cannot decrypt, but it still sees metadata such as project names, email addresses and timestamps, as the [limitations page](https://crunu.com/security/limitations) explains. dotenvx core needs no server at all. ## Where dotenvx is stronger - **Secrets travel with the code.** Encrypted `.env` files ship in the same commit and the same artifact as the code that reads them. With core dotenvx your infrastructure only needs one private key per environment. Crunu needs its agent and a server it can reach at least once per lease. - **Windows and SDKs.** dotenvx lists key storage in macOS Keychain, Windows Credential Manager and Linux Secret Service, plus SDKs for languages including Node.js, Python, Ruby, Rust and PHP. Crunu has no Windows agent and no SDKs; applications use `crunu run`. - **Drop-in for dotenv.** If your code already loads `.env` files, dotenvx changes very little. Crunu adds projects, environments and accounts. - **Paid controls Crunu lacks.** Armor lists human approval before decrypt, decrypting from a software enclave, and Google and GitHub sign-in. Crunu has access requests for environments, but no approval step for each decrypt and no SSO. - **Open-source core.** The dotenvx CLI is BSD 3-Clause. Crunu's source code is not published. ## Moving from dotenvx to Crunu > **Note:** Crunu has no importer for dotenvx. You decrypt each file with dotenvx on a trusted computer and drag the plaintext `.env` files into Crunu. 1. [Create an account](https://crunu.com/signup) and save your Emergency Kit before anything else. 2. Create a project for each application and an environment for each `.env` file you encrypt, such as `development`, `ci` and `production`. 3. On a trusted computer that holds the private keys, write each file out in plaintext, for example `dotenvx decrypt -f .env.production --stdout > production.env`. 4. Drag the plaintext files into the matching environments and invite the team, giving each person a role per environment. 5. Replace `dotenvx run -- ` with `crunu run --env / -- `, enroll servers as machines and give pipelines service tokens with OIDC binding. 6. Remove the `DOTENV_PRIVATE_KEY_*` values from CI secrets, servers and `.env.keys` files, delete the plaintext files, and remove the encrypted files from the repository once nothing reads them. The encrypted files stay in Git history, readable by anyone who still holds an old private key. Reissue the values that matter at their providers after the move. > **Warning:** Decrypted files hold plaintext secrets. Keep them out of Git and synced folders, and delete them as soon as the import is done. ## Other dotenvx alternatives If you want to keep encrypted files in Git, [SOPS](https://crunu.com/alternatives/sops) encrypts values in `.env`, YAML, JSON and INI files with age, PGP or cloud KMS keys, and documents how to remove a key and rotate the data key. [git-crypt](https://crunu.com/alternatives/git-crypt) encrypts whole files transparently, without a way to revoke access. [SOPS vs Ansible Vault](https://crunu.com/compare/sops-vs-ansible-vault) covers the trade-offs between file tools in more depth. If you want a hosted vault where the vendor still cannot read values, [Phase](https://crunu.com/alternatives/phase) and [Bitwarden Secrets Manager](https://crunu.com/alternatives/bitwarden-secrets-manager) also encrypt on the client. [Doppler](https://crunu.com/alternatives/doppler) and [Infisical](https://crunu.com/alternatives/infisical) decrypt on their servers in exchange for syncs to many platforms. The [who can decrypt guide](https://crunu.com/guides/who-can-decrypt-your-secrets) compares them all. ## FAQ ### Is Crunu an alternative to dotenvx? Yes, for teams that share encrypted `.env` files between people, servers and CI. Crunu replaces the per-file private keys with keys sealed to each person and machine, so access can be granted and removed one recipient at a time. If you work alone and like secrets traveling with the code, dotenvx may suit you better. ### How do I move from dotenvx to Crunu? Decrypt each file with `dotenvx decrypt --stdout` on a trusted computer, drag the plaintext files into Crunu environments, and switch `dotenvx run` to `crunu run`. There is no importer. Then remove the old private keys from CI, servers and `.env.keys` files. ### Who can read a dotenvx file? Anyone who has the matching private key, such as `DOTENV_PRIVATE_KEY_PRODUCTION` for `.env.production`, and a copy of the file. With paid Armor, keys can be moved off devices, access can require human approval, and Armor lists server-side decryption among its features. ### Does Crunu work on Windows? The Crunu web app runs in current versions of Chrome, Safari and Firefox, but the `crunu` agent and CLI are built for Linux and macOS only. If your team develops or deploys on Windows, dotenvx's CLI covers that today and Crunu does not. ### Can CI decrypt without a stored key in Crunu? Yes. A Crunu service token can be bound by OIDC to a repository, branch and deployment environment on GitHub Actions, GitLab CI or Bitbucket Pipelines, so a leaked token does not work without that pipeline's identity token. The documented dotenvx setup stores a private key as a CI secret. ## Sources - [dotenvx README](https://github.com/dotenvx/dotenvx) (accessed 2026-10-30) - [dotenvx for AI tools (llms.txt)](https://dotenvx.com/llms.txt) (accessed 2026-10-30) - [dotenvx pricing](https://dotenvx.com/pricing) (accessed 2026-10-30) - [Dotenvx Armor](https://dotenvx.com/armor) (accessed 2026-10-30) - [dotenvx: GitHub Actions](https://dotenvx.com/docs/github-actions/) (accessed 2026-10-30) - [dotenvx license (BSD 3-Clause)](https://github.com/dotenvx/dotenvx/blob/main/LICENSE) (accessed 2026-10-30)