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.
The difference in brief
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 is the better pick when
- Secrets must live in Git next to the code they configure, reviewed in the same pull requests.
- You want no extra server or account at all, only a CLI and keys you already manage.
- Your cloud KMS and IAM roles should decide who can decrypt.
Crunu is the better pick when
- Removing a person should rotate keys and list the values they saw, without a manual rotate on every file.
- Servers and CI should get only their environments, with OIDC-bound tokens instead of private key files.
- You want a record of who received which version, not only who committed a change.
SOPS and Crunu, property by property
The same 14 questions we ask of every tool, answered from SOPS’s own pages and from what Crunu does today. Yes is not always better: read the note.
- Yes
- documented and available
- Partial
- with limits: on some plans, in preview or by hand
- No
- not offered
- n/a
- doesn’t apply, or isn’t documented publicly
| Property | SOPS | Crunuour product | What it changes for you |
|---|---|---|---|
| Keys change when someone leaves | SOPSPartialManual: after removing a key, rotate the data key with sops rotate, as the docs recommend. getsops.io · | CrunuYesRemoving a member rotates the keys of every environment they could read and lists values to reissue. crunu.com/features/offboarding · | When people hold decryption keys, removing access is complete only once those keys are replaced. |
| Decrypted only on your devices | SOPSYesThe sops CLI decrypts files locally; keys come from age, PGP or a cloud KMS. getsops.io · | CrunuYesValues are encrypted and decrypted only in the browser and the crunu agent. crunu.com/security · | If values are decrypted only on devices you control, a breach of the vendor’s servers doesn’t expose them. |
| Server handles plaintext values | SOPSNoNo server: encrypted files live in your repository or storage. getsops.io · | CrunuNoThe server holds no decryption key at any point. It still sees metadata such as names, emails and timestamps. crunu.com/security · | Whoever runs a server that handles plaintext, and anyone who breaks into it, could read what passes through. |
| Runs on your own infrastructure | SOPSYesA command-line tool with no hosted service. getsops.io · | CrunuPartialEnterprise plan only, under a signed agreement: your own server on Docker, Cloudflare Workers, Vercel or Google Cloud Run. crunu.com/self-hosting · | You decide where the data lives and who operates the service. Several tools, Crunu included, offer this only on an enterprise plan. |
| Source code published | SOPSYesMozilla Public License 2.0; a CNCF Sandbox project. getsops.io · | CrunuNoSource code is not published. crunu.com/security/threat-model · | Published code can be read and audited by anyone, and kept running if the vendor changes course. |
| CI signs in with OIDC | SOPSn/aNo service to sign in to; CI needs an age or PGP key, or access to a cloud KMS key. getsops.io · | CrunuYesService tokens bound by OIDC to repository, branch and environment on GitHub Actions, GitLab CI, Bitbucket or any issuer. crunu.com/features/ci-cd · | Pipelines get short-lived access tied to the repository, instead of a long-lived token stored in CI settings. |
| Separate key per environment | SOPSPartialCreation rules can assign different keys per file path, such as *.dev.yaml and *.prod.yaml. getsops.io · | CrunuYesEach environment has its own key, sealed separately to each recipient's public key. crunu.com/features/access-control · | With a key per environment, access to development can’t turn into access to production. |
| Audit log | SOPSPartialOptional: logs each decryption to a PostgreSQL database that you set up. getsops.io · | CrunuYesHash-chained organization log with one-click verification and JSONL export, kept 365 days by default. crunu.com/features/audit-log · | A record of who changed or fetched what tells you what a person or machine could have seen. |
| Links for people without an account | SOPSNoNo sharing feature; access comes from holding a key the file is encrypted to. getsops.io · | CrunuYesLinks for people without an account; the key stays in the URL fragment. Expiry, view limit and password. crunu.com/features/access-links · | Contractors and one-off handovers get a value without it staying in chat history. |
| Free plan or free to use | SOPSYesFree, open-source CLI. github.com · | CrunuYesFree during early access. crunu.com/pricing · | A small team can start with real projects before anyone signs a contract. |
| Syncs values into other platforms | SOPSNoEncrypts files only; it does not push values to other platforms. getsops.io · | CrunuNoNo built-in sync to other platforms. CI can push values with crunu run as a recipe. crunu.com/integrations · | Pushing values into clouds and CI saves copying by hand, but the syncing service has to read them. |
| Dynamic secrets | SOPSNoEncrypts stored files only; it does not generate credentials. getsops.io · | CrunuNoNot offered by design: generating credentials on demand needs a key on the server. crunu.com/security/limitations · | Credentials created on demand and revoked after a lease limit how long a leaked one works. |
| SSO and SCIM | SOPSn/aNot applicable: there are no user accounts; access is by key. getsops.io · | CrunuNoNo SSO or SCIM. People sign in with a password, a Secret Key and an optional second factor. crunu.com/features/access-control · | Sign-in and provisioning from your identity provider make joining and leaving one step. |
| Kubernetes integration | SOPSn/aNot documented publicly. getsops.io · | CrunuNoNo Kubernetes operator, Helm chart or CSI provider. crunu.com/integrations · | An operator or CSI driver delivers values into clusters without custom glue code. |
Comparison in detail
On this page
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.
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.
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.
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 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 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
- Create an account and save your Emergency Kit before anything else.
- Create a project for each application and an environment for each stage that has its own creation rule, for example
development,stagingandproduction. - On a trusted computer, decrypt each file to plaintext with SOPS, for example
sops decrypt prod.enc.env > prod.env. - Drag the plaintext files into the matching environments. Crunu reads
KEY=VALUEfiles, INI sections and flat YAML as fields, and keeps any other text, such as nested YAML, as a whole file. - Invite the team and give each person a role per environment: Editor, Reader, Specific files or Operator.
- Replace
sops exec-envin scripts and services withcrunu run --env <project>/<environment> -- <command>, enroll servers as machines and give pipelines service tokens with OIDC binding. - 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.
Other SOPS alternatives
If you like that SOPS keeps everything in Git, the closest neighbors are other file tools. Ansible Vault protects files and variables with a vault password and suits teams that already deploy with playbooks; SOPS vs Ansible Vault compares the two directly. git-crypt encrypts whole files transparently on commit, but cannot revoke access. 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 and Infisical decrypt on their servers and add dynamic secrets and syncs. The who can decrypt guide puts all of these tools on one page, sorted by who holds the keys.
More facts, row by row
Details beyond the 14 questions above, as this comparison states them.
| 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 |
Sources
Every page this comparison relies on, and the day we last verified it.
- SOPS documentation · checked October 30, 2026
- SOPS: key management · checked October 30, 2026
- SOPS: configuration file and creation rules · checked October 30, 2026
- SOPS: key groups · checked October 30, 2026
- SOPS: advanced usage (exec-env, auditing) · checked October 30, 2026
- SOPS: common operations (diffs in Git) · checked October 30, 2026
- SOPS: security model · checked October 30, 2026
- SOPS license (MPL 2.0) · checked October 30, 2026
Questions about Crunu and SOPS
Something else? Write to support@crunu.com
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.