SOPS vs Ansible Vault: diffs, keys and removing people
SOPS and Ansible Vault compared for team secrets: keys vs passwords, readable diffs, rekeying and removing people, CI and audit, from both tools' docs.
Product websitesSOPSAnsible Vault
The difference in brief
Both keep secrets encrypted in your repository with no server. SOPS encrypts only the values in YAML, JSON, ENV and INI files, with age, PGP or cloud KMS keys per person or per path. Ansible Vault encrypts whole files or single variables with a vault password and fits teams that already deploy with Ansible.
SOPS is the better pick when
- You want per-person keys or cloud KMS keys instead of one shared password.
- Reviewers should see which value changed in a diff, and merge conflicts should be easier to resolve.
- Your secrets live in YAML, JSON, ENV or INI files used outside Ansible.
Ansible Vault is the better pick when
- Your deployments are Ansible playbooks, and secrets belong next to the roles.
- You need to encrypt whole task files or templates, not only values.
- A small team shares a few secrets, and one password is enough.
Crunu, a third option, fits when
- People, servers and pipelines should each get only their environments, with keys rotated when someone leaves.
Crunu wrote this page and makes this third option.
SOPS, Ansible Vault and Crunu, property by property
The same 14 questions we ask of every tool. SOPS and Ansible Vault are answered from their own pages; Crunu is shown as a third option in its own column.
- 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 | Ansible Vault | CrunuThird option | What it changes for you |
|---|---|---|---|---|
| Decrypted only on your devices | SOPSYesThe sops CLI decrypts files locally; keys come from age, PGP or a cloud KMS. getsops.io · | Ansible VaultYesAnsible or ansible-vault decrypts content wherever the vault password is supplied. docs.ansible.com · | 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 · | Ansible VaultNoNo server: encrypted files go into your source control. docs.ansible.com · | 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 · | Ansible VaultYesPart of Ansible, with no hosted service. docs.ansible.com · | 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 · | Ansible VaultYesAnsible is licensed under the GNU GPL v3. github.com · | 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 · | Ansible Vaultn/aNo service to sign in to; CI needs the vault password. docs.ansible.com · | 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. |
| Keys change when someone leaves | SOPSPartialManual: after removing a key, rotate the data key with sops rotate, as the docs recommend. getsops.io · | Ansible VaultPartialManual: rekey each file with a new password; encrypted variables cannot be rekeyed. docs.ansible.com · | 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. |
| Separate key per environment | SOPSPartialCreation rules can assign different keys per file path, such as *.dev.yaml and *.prod.yaml. getsops.io · | Ansible VaultPartialVault IDs let you use a different password per environment, such as dev and production. docs.ansible.com · | 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 · | Ansible VaultNoProtects data at rest only; it keeps no record of who decrypted what. docs.ansible.com · | 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 · | Ansible VaultNoNo sharing feature; people need the vault password. docs.ansible.com · | 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 · | Ansible VaultYesFree as part of open-source Ansible. 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 · | Ansible VaultNoEncrypts files and variables only; it does not push values to other platforms. docs.ansible.com · | 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 · | Ansible VaultNoEncrypts stored content only; it does not generate credentials. docs.ansible.com · | 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 · | Ansible Vaultn/aNot applicable: there are no user accounts; access is by vault password. docs.ansible.com · | 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 · | Ansible Vaultn/aNot documented publicly. docs.ansible.com · | 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
The deciding difference between SOPS and Ansible Vault is what opens a file. SOPS encrypts each file's data key to a list of keys, such as one age or PGP key per person or a cloud KMS key, and leaves the structure of the file readable. Ansible Vault derives its key from a vault password, so everyone who can decrypt holds the same secret. Both keep encrypted secrets in your repository, both run without a server, and both are free and open source.
That one choice shapes everything else on this page: what a diff shows, how merges behave, and what you do when a teammate leaves.
Who each one fits
SOPS fits teams that keep configuration in YAML, JSON, ENV or INI files and want them in Git, encrypted per value. It works with any deployment tool, and access can follow your cloud IAM through AWS KMS, Google Cloud KMS or Azure Key Vault, or follow people through age and PGP keys. It is a CNCF Sandbox project under the Mozilla Public License 2.0.
Ansible Vault fits teams that already deploy with Ansible. It ships with Ansible, so there is nothing new to install, and it can encrypt anything Ansible reads: variables files, single variables, tasks and templates. The Ansible documentation suggests a single password for a small team and several passwords, told apart by vault IDs, for larger ones.
Adding and removing a person
This is where the two tools differ most in daily work. The steps below come from each tool's documentation.
| Task | SOPS | Ansible Vault |
|---|---|---|
| Give a new person access | Add their key to .sops.yaml and run sops updatekeys on each file | Share the vault password with them |
| Give access to staging only | A creation rule for staging files that lists their key | A separate vault ID and password for staging |
| Remove a person | Remove their key, run sops updatekeys, then sops rotate on each file | Choose a new password, ansible-vault rekey every file, and re-create encrypted variables |
| Tell everyone else | Nothing changes for people who stay | Everyone who stays needs the new password |
| After removal | Reissue the secrets themselves, since old commits still open with the old data key | Reissue the secrets themselves, since old commits still open with the old password |
SOPS documents the order carefully: remove the key first, then rotate the data key, and "only after this is done" rotate the real passwords and API keys. Ansible's documentation notes that "you cannot rekey encrypted variables", so single variables made with encrypt_string have to be encrypted again one by one.
Diffs, merges and who can decrypt
SOPS's security notes explain why it encrypts values instead of whole files: diffs are meaningful, because "if a single value of a file is modified, only that value will show up in the diff", and conflicts are easier to resolve as long as two people do not change the same value. With a textconv setting in Git, git diff can even show the decrypted values for review.
Ansible Vault gives you the choice. File-level encryption hides even the variable names and rekeys easily, but the file is no longer readable at a glance. Variable-level encryption keeps the file legible and lets you mix plain and encrypted values, at the cost of harder password rotation.
In both tools, everyone who can open a file can open all of it, and any commit in history opens with the keys or password that were valid at the time.
Where SOPS is stronger
- Keys per person, not a shared password. Removing one person does not mean handing a new password to everyone else.
- Readable diffs and easier merges. Only changed values show up in a diff, and merges conflict only when two people change the same value.
- Cloud KMS and key groups. Access can follow cloud IAM roles, and a threshold of key groups can be required before a file opens.
- Works with any tool. SOPS is not tied to Ansible.
Where Ansible Vault is stronger
- Already installed. If you run Ansible, Ansible Vault is part of it, with no extra binary or key infrastructure.
- Encrypts anything Ansible reads. Task files, templates and inventories can be encrypted whole, which hides even the variable names.
- Simple for a small team. One password in a password manager is easy to understand, and the docs recommend it for few people and few values.
- Built into the run. Playbooks decrypt what they need during the run, with
--vault-idchoosing passwords per environment.
A third option: Crunu
Crunu, which wrote this page, takes secrets out of the repository instead. Each environment has its own key, sealed separately to every person, machine and pipeline that may read it, and the server stores only ciphertext. Removing someone rotates the keys of every environment they could read, records which versions they received, and lists the values to reissue. Pipelines use service tokens bound by OIDC to a repository and branch instead of a key file or a vault password, and crunu run can start ansible-playbook with the values a run needs. The server still sees metadata such as names, email addresses and timestamps, as the limitations page explains.
Crunu is not a fit if you want secrets reviewed in the same pull requests as code, need no server at all, or want open-source software: its source code is not published. See Crunu vs SOPS and Crunu vs Ansible Vault for the full comparisons, and git-crypt for a third file tool, one that cannot revoke access.
More facts, row by row
Details beyond the 14 questions above, as this comparison states them.
| SOPS | Ansible Vault | |
|---|---|---|
| What opens a file | Any key the file's data key is encrypted to: age, PGP, AWS KMS, Google Cloud KMS, Azure Key Vault or HuaweiCloud KMS | A vault password, typed in, read from a file or returned by a client script |
| What is encrypted | Values only in YAML, JSON, ENV and INI; whole files in binary mode | Whole files, or single variables with encrypt_string |
| What stays readable | Key names and file structure | In variable-level mode, the surrounding file; in file mode, nothing but the header |
| Separate environments | Creation rules in .sops.yaml pick keys by file path, such as *.dev.yaml and *.prod.yaml | Vault IDs let you use a different password per environment; the label is only a hint |
| Requiring several parties | Key groups with a threshold: keys from several groups must take part before a file opens | Not documented |
| Running a program | sops exec-env passes decrypted values to a child process without writing them to disk | ansible-playbook decrypts what it needs during a run |
| Record of access | Optional: a log entry per decryption in a PostgreSQL database you set up | None; Ansible Vault protects data at rest only |
| CI pipelines | The job needs an age or PGP key, or IAM access to a cloud KMS key | The job needs the vault password |
| Tooling | A standalone CLI that works with any tool | Part of Ansible, GNU GPL v3 |
| Price | Free | Free |
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: common operations (diffs in Git) · checked October 30, 2026
- SOPS: advanced usage (exec-env, auditing) · checked October 30, 2026
- SOPS: security model · checked October 30, 2026
- Ansible Vault guide · checked October 30, 2026
- Ansible: managing vault passwords · checked October 30, 2026
- Ansible: encrypting content with Ansible Vault · checked October 30, 2026
- Ansible: using encrypted variables and files · checked October 30, 2026
Questions about SOPS and Ansible Vault
Something else? Write to support@crunu.com
Is SOPS better than Ansible Vault?
For teams that change who has access often, SOPS makes that easier, because each person or service has its own key and removing one does not mean a new password for everyone. For teams that already run Ansible and share a few secrets among a few people, Ansible Vault is simpler.
Can I use SOPS and Ansible Vault together?
Yes. You can keep Ansible Vault for encrypted task files and templates and use SOPS for application configuration files. Each secret should live in one tool, so it is clear which one to update and rekey.
Which one shows readable diffs?
SOPS. It keeps key names in cleartext and encrypts only values, so a diff shows which value changed. With a textconv setting, git diff can show the decrypted values. Ansible Vault in file mode shows the whole file as changed ciphertext.
What should I do when someone leaves?
With SOPS, remove their key from .sops.yaml, run sops updatekeys and sops rotate on every file, then reissue the secrets. With Ansible Vault, choose a new password, rekey every file, re-create encrypted variables and share the new password. In both cases, old commits still hold values the person could read.
Do SOPS or Ansible Vault keep an audit log?
Ansible Vault does not; its documentation says it only protects data at rest. SOPS can write a log entry for each decryption to a PostgreSQL database you set up, recording the time, the user running SOPS and the file.