# 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.

URL: https://crunu.com/compare/sops-vs-ansible-vault
Language: en
Updated: 2026-10-30

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.

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.

> **Note:** Crunu wrote this comparison. We make a third option, described near the end, and we compared SOPS and Ansible Vault using only their own documentation, checked on October 30, 2026. Sources are listed with this page. If something is out of date, tell us at <support@crunu.com>.

## 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.

## Side by side

|                           | 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                                                                                 |

## 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.

*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.*

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.

*Figure: Diagram of who can decrypt Ansible Vault 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.*

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-id` choosing 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](https://crunu.com/security/limitations) 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](https://crunu.com/alternatives/sops) and [Crunu vs Ansible Vault](https://crunu.com/alternatives/ansible-vault) for the full comparisons, and [git-crypt](https://crunu.com/alternatives/git-crypt) for a third file tool, one that cannot revoke access.

## FAQ

### 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.

## 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: common operations (diffs in Git)](https://getsops.io/docs/usage/common-operations/) (accessed 2026-10-30)
- [SOPS: advanced usage (exec-env, auditing)](https://getsops.io/docs/usage/advanced/) (accessed 2026-10-30)
- [SOPS: security model](https://getsops.io/docs/security/) (accessed 2026-10-30)
- [Ansible Vault guide](https://docs.ansible.com/ansible/latest/vault_guide/vault.html) (accessed 2026-10-30)
- [Ansible: managing vault passwords](https://docs.ansible.com/ansible/latest/vault_guide/vault_managing_passwords.html) (accessed 2026-10-30)
- [Ansible: encrypting content with Ansible Vault](https://docs.ansible.com/ansible/latest/vault_guide/vault_encrypting_content.html) (accessed 2026-10-30)
- [Ansible: using encrypted variables and files](https://docs.ansible.com/ansible/latest/vault_guide/vault_using_encrypted_content.html) (accessed 2026-10-30)