# SOPS alternative for teams: Crunu vs SOPS > Crunu and SOPS compared: who can decrypt, removing a teammate, CI access, audit records and diffs in Git, checked against the SOPS documentation. URL: https://crunu.com/alternatives/sops Language: en Updated: 2026-10-30 SOPS encrypts values inside files in your repository, with keys from age, PGP or a cloud KMS, and runs no server. Crunu keeps each environment encrypted on your devices behind a server that stores only ciphertext. It gives every person, machine and pipeline its own access, and rotates keys when someone leaves. SOPS and Crunu both keep secrets encrypted so that the place they are stored cannot read them, but they draw the boundary in different places. SOPS encrypts the values inside YAML, JSON, ENV and INI files and leaves those files in your repository; whoever holds one of the keys a file is encrypted to can decrypt it. Crunu keeps each environment encrypted on your devices and seals its key separately to every person, machine and pipeline that may read it, so access can be granted and taken away one recipient at a time. That difference rarely matters on day one. It matters on the day someone leaves, the day a new CI pipeline needs only staging, or the day a security review asks who received the production values last quarter. > **Note:** Crunu wrote this comparison. We checked every statement about SOPS against its documentation 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 **SOPS fits** teams that want secrets to live in Git with the code they configure. Files are encrypted with keys from age, PGP, AWS KMS, Google Cloud KMS, Azure Key Vault or HuaweiCloud KMS, there is no service to run, and a change to a secret goes through the same pull request as the change that needs it. It is open source under the Mozilla Public License 2.0 and a Cloud Native Computing Foundation Sandbox project. **Crunu fits** teams where the list of people and machines changes more often than the files do. It is built around projects and environments, around giving a laptop, a server or a pipeline exactly the environments it needs, and around a clean exit when someone leaves. You can use the Crunu cloud or, on the Enterprise plan, [host the server yourself](https://crunu.com/self-hosting). ## Side by side | | SOPS | Crunu | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | | Where values are decrypted | Locally by the `sops` CLI, on any machine that holds a key the file is encrypted to | Only in the browser and the `crunu` agent, on devices that hold the environment key | | What a server sees | No server. Encrypted files live in your repository; key names stay readable in YAML, JSON, ENV and INI files. | Ciphertext, public keys and signed documents, plus metadata such as names, emails and timestamps | | What you run | A command-line tool, plus your key infrastructure: age or PGP keys, or cloud KMS keys | The Crunu cloud; on the Enterprise plan, also your own server on Docker, Cloudflare Workers, Vercel or Google Cloud Run | | Source code | Open source, Mozilla Public License 2.0 | Not published | | Keys per environment | Creation rules in `.sops.yaml` can assign different keys by file path, such as `*.dev.yaml` and `*.prod.yaml` | Each environment has its own key, sealed separately to each recipient's public key | | Removing someone | Remove their key from `.sops.yaml`, run `sops updatekeys` and `sops rotate` on every file, then reissue the values | Removal rotates the keys of every environment they could read and lists the values to reissue | | CI pipelines | The job needs an age or PGP private key, or IAM access to a cloud KMS key | Service tokens limited to chosen environments, optionally bound by OIDC to a repository, branch and deployment environment | | Record of access | Optional: a log entry per decryption in a PostgreSQL database you set up | Hash-chained organization log, 365 days by default, with JSONL export and a record of which versions each person received | | Sharing with someone outside | No sharing feature; the recipient needs a key the file is encrypted to | Links for people without an account, with expiry, view limit and password; the key stays in the URL fragment | | Reviewing changes | Diffs show which value changed; a `textconv` setting shows cleartext diffs in `git diff` | Version history of the last 100 versions, with field names that changed and rollback by a new version | | Price | Free, open-source CLI | Free during early access in the Crunu cloud; self-hosting on the Enterprise plan | ## What happens when someone leaves SOPS documents this step carefully, and its own instructions show where the work goes. To take a key away, you remove it from the key group in `.sops.yaml`, then run `sops updatekeys` and `sops rotate --in-place` on each encrypted file, then commit and push. The documentation is clear that the order matters, and that only after the data keys are rotated should you start reissuing "the actual passwords, API keys and other secrets". Older commits stay in Git history, encrypted to the old data key, so anything the person could read before is still readable to them in those commits. *Figure: Diagram of who can decrypt SOPS 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. Cloud IAM principals with decrypt permission can decrypt as well.* Crunu turns the same job into one action. When you remove someone, the server stops serving them at once, and every environment they could read gets a new key that they never held. The [member removal flow](https://crunu.com/features/offboarding) shows which versions of which environments the person received, when, and from where, and produces a checklist of values to reissue at each provider, without showing the values themselves. When an administrator leaves, the organization's signing and recovery keys are replaced as well. Neither tool can make a person forget a value they already saw. In both cases the last step is the same: reissue those values at the provider. Crunu's [limitations page](https://crunu.com/security/limitations) says this plainly. ## Where SOPS is stronger - **Secrets live with the code.** A secret change and the code that depends on it can land in one pull request, reviewed by the same people. SOPS keeps key names readable and encrypts only values, so a diff shows which value changed, and two people can merge their edits as long as they do not change the same value. Crunu keeps environments outside your repository. - **Nothing to run or trust.** SOPS is a CLI. There is no server, no account and no vendor between you and your keys. Crunu always has a server, even when you host it. - **Open source with foundation governance.** SOPS is MPL 2.0 and a CNCF Sandbox project. Crunu's source code is not published. - **Your cloud keys and IAM.** With AWS KMS, Google Cloud KMS or Azure Key Vault, your cloud IAM policies decide who can decrypt, and key groups can require keys from several groups before a file opens. Crunu keys live on your devices, not in a cloud KMS. - **No vendor at all.** SOPS works with any CI system, any file layout and offline, and it costs nothing. ## Moving from SOPS to Crunu > **Note:** Crunu has no importer for SOPS files. You decrypt each file with SOPS on a trusted computer and drag the plaintext 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 stage that has its own creation rule, for example `development`, `staging` and `production`. 3. On a trusted computer, decrypt each file to plaintext with SOPS, for example `sops decrypt prod.enc.env > prod.env`. 4. Drag the plaintext files into the matching environments. Crunu reads `KEY=VALUE` files, INI sections and flat YAML as fields, and keeps any other text, such as nested YAML, as a whole file. 5. Invite the team and give each person a role per environment: Editor, Reader, Specific files or Operator. 6. Replace `sops exec-env` in scripts and services with `crunu run --env / -- `, enroll servers as machines and give pipelines service tokens with OIDC binding. 7. Delete the plaintext files, then remove the encrypted files from the repository once nothing reads them. Some things do not move. Git history keeps the old encrypted files, so treat values those files held as known to everyone who had a key, and reissue them if that matters. Key groups, cloud KMS access and per-path creation rules have no direct equivalent; in Crunu the environment is the unit of encryption and access. > **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 SOPS alternatives If you like that SOPS keeps everything in Git, the closest neighbors are other file tools. [Ansible Vault](https://crunu.com/alternatives/ansible-vault) protects files and variables with a vault password and suits teams that already deploy with playbooks; [SOPS vs Ansible Vault](https://crunu.com/compare/sops-vs-ansible-vault) compares the two directly. [git-crypt](https://crunu.com/alternatives/git-crypt) encrypts whole files transparently on commit, but cannot revoke access. [dotenvx](https://crunu.com/alternatives/dotenvx) encrypts `.env` files with a keypair per file. If the pain is people and machines rather than files, look at hosted vaults. [HashiCorp Vault](https://crunu.com/alternatives/hashicorp-vault) and [Infisical](https://crunu.com/alternatives/infisical) decrypt on their servers and add dynamic secrets and syncs. The [who can decrypt guide](https://crunu.com/guides/who-can-decrypt-your-secrets) puts all of these tools on one page, sorted by who holds the keys. ## FAQ ### Is Crunu an alternative to SOPS? Yes, for teams that use SOPS to share environment files between people, servers and CI. Crunu replaces the encrypted files in Git with environments that each have their own key and their own list of readers. If you use SOPS mainly for GitOps manifests that must live in the repository, SOPS is still the better fit. ### How do I move from SOPS to Crunu? Decrypt each file with `sops decrypt` on a trusted computer, drag the plaintext files into matching Crunu environments, then switch scripts from `sops exec-env` to `crunu run`. There is no importer. Delete the plaintext files after the import. ### Does removing a key from .sops.yaml revoke access? Not on its own. The SOPS documentation says to run `sops updatekeys` and then rotate the data key with `sops rotate` on each file, and only then reissue the secrets themselves. Older commits in Git history stay encrypted to the old data key. ### Can I use SOPS and Crunu together? Yes. You can keep SOPS for infrastructure files that must live in the repository and use Crunu for application environments that people, machines and pipelines read at runtime. Each value should live in one place, so decide which tool owns which file. ### Is Crunu open source like SOPS? No. Crunu's source code is not published. On the Enterprise plan, you can host the server yourself on Docker, Cloudflare Workers, Vercel or Google Cloud Run, and it moves between them with one archive that holds no plaintext values. ## Sources - [SOPS documentation](https://getsops.io/docs/) (accessed 2026-10-30) - [SOPS: key management](https://getsops.io/docs/usage/key-management/) (accessed 2026-10-30) - [SOPS: configuration file and creation rules](https://getsops.io/docs/usage/identities/config-file/) (accessed 2026-10-30) - [SOPS: key groups](https://getsops.io/docs/usage/identities/key-groups/) (accessed 2026-10-30) - [SOPS: advanced usage (exec-env, auditing)](https://getsops.io/docs/usage/advanced/) (accessed 2026-10-30) - [SOPS: common operations (diffs in Git)](https://getsops.io/docs/usage/common-operations/) (accessed 2026-10-30) - [SOPS: security model](https://getsops.io/docs/security/) (accessed 2026-10-30) - [SOPS license (MPL 2.0)](https://github.com/getsops/sops/blob/main/LICENSE) (accessed 2026-10-30)