# Ansible Vault alternative with per-person keys: Crunu > Crunu and Ansible Vault compared: shared vault passwords, rekeying when someone leaves, CI access and audit, checked against the Ansible documentation. URL: https://crunu.com/alternatives/ansible-vault Language: en Updated: 2026-10-30 Ansible Vault encrypts files and variables in your playbook repository with a vault password that everyone who runs the playbooks must hold. Crunu gives every person, machine and pipeline its own key to only the environments it needs, and rotates those keys when someone leaves. The core difference is the password. Ansible Vault encrypts files and variables with a key derived from a vault password, so everyone who runs a playbook, and every CI job that runs one, must hold that password. Crunu has no shared password: each environment has its own key, sealed separately to each person, machine and pipeline that may read it, and taking one recipient away rotates the key for everyone else without a new password to hand out. Ansible Vault is a good tool for what it was built to do, protecting secrets at rest inside a repository of playbooks and roles. This page is for teams who have outgrown the shared password: more people, more pipelines, and a need to know who could read what. > **Note:** Crunu wrote this comparison. We checked every statement about Ansible Vault against the Ansible 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 **Ansible Vault fits** teams that already deploy with Ansible and want their secrets to sit next to the playbooks and roles that use them. It ships with Ansible, needs no service, and works the same on a laptop and in a pipeline. The Ansible documentation itself suggests a single password for a small team with few sensitive values. **Crunu fits** teams where the number of people and pipelines makes one password a liability. It fits teams that want a developer to read development without ever holding the production key, want servers and CI jobs to fetch only their own environments, and want a clear trail when someone leaves. Crunu works alongside Ansible: `crunu run` can start `ansible-playbook` with the values a run needs. ## Side by side | | Ansible Vault | Crunu | | ---------------------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | What you need to decrypt | A vault password, typed in, read from a file or returned by a client script | Each person's account keys, each machine's key or each pipeline's service token | | Where values are decrypted | Wherever Ansible or `ansible-vault` runs with the password | Only in the browser and the `crunu` agent, on devices that hold the environment key | | What a server sees | No server. Encrypted files and variables go into your source control. | Ciphertext, public keys and signed documents, plus metadata such as names, emails and timestamps | | Separating environments | Vault IDs let you use one password for development and another for production; the label is only a hint | Each environment has its own key, sealed separately to each recipient's public key | | Removing someone | Choose a new password, rekey every encrypted file, and re-create encrypted variables, which cannot be rekeyed | Removal rotates the keys of every environment they could read and lists the values to reissue | | CI pipelines | The job needs the vault password, from a file, a prompt or a client script | Service tokens limited to chosen environments, optionally bound by OIDC to a repository, branch and deployment environment | | Record of access | None: it protects data at rest and keeps no record of who decrypted what | 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 the vault password | Links for people without an account, with expiry, view limit and password | | What can be encrypted | Whole files, including tasks and templates, or single variables with `encrypt_string` | `.env`, INI, flat YAML and any text file, grouped into environments | | Source code | Part of Ansible, GNU GPL v3 | Not published | | Price | Free as part of open-source Ansible | Free during early access in the Crunu cloud; self-hosting on the Enterprise plan | ## No shared vault password The Ansible documentation is direct about the trade. "To use Ansible Vault you need one or more passwords to encrypt and decrypt content." For a larger team it suggests multiple passwords: per user, per level of access, per directory or per environment. Each extra password is one more secret to store, hand out and change, and the vault ID that names it is, in Ansible's words, "only a hint". Ansible tries each password it is given, and does not enforce that a label always maps to the same one. *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.* Crunu replaces the password with keys that belong to people and machines. A Reader on `payments-api / staging` holds the staging key and nothing else. An Operator can enroll machines and request access for them without ever seeing a value. When someone leaves, the [member removal flow](https://crunu.com/features/offboarding) rotates the keys of every environment they could read, shows which versions they received and when, and lists the values to reissue at each provider. Nobody else has to learn a new password. *Figure: Example: in Crunu, Kiteline’s owner opens Jonas Lindqvist’s member page. Environment access shows him as an Editor on development and staging through the “Developers” access profile, and every production cell says none. A card beside it shows what the server stores: environment keys sealed to Jonas for payments-api development and staging, and no production key sealed to him at all.* Ansible Vault's warning that it "ONLY protects 'data at rest'" holds for Crunu too, in its own way: once a value is decrypted on a laptop or a server, that device can read it. Crunu's [limitations page](https://crunu.com/security/limitations) lists what this means in practice. ## Where Ansible Vault is stronger - **It is already there.** Ansible Vault ships with Ansible. There is no account, no server and no new tool to approve. Crunu adds a service, even when you host it yourself. - **Secrets next to the playbooks.** Encrypted files and variables live in the same repository as the roles that use them and change in the same pull requests. Crunu keeps environments outside your repository. - **It encrypts anything.** Whole task files, templates and inventories can be encrypted, which hides even the names of the variables inside. Crunu stores environment files and text, not encrypted playbooks. - **Open source and free.** Ansible is GNU GPL v3. Crunu's source code is not published. ## Moving from Ansible Vault to Crunu > **Note:** Crunu does not import files made by Ansible Vault. You decrypt them with `ansible-vault` 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 or inventory, and an environment for each vault ID or stage you use, such as `development` and `production`. 3. On a trusted computer, decrypt each vault file with `ansible-vault decrypt --output `, or print it with `ansible-vault view`, and save the variables you need as `.env` or YAML files. 4. Drag the files into the matching environments and invite the team, giving each person a role per environment. 5. Run playbooks through `crunu run --env / -- ansible-playbook site.yml` and read the values with the `ansible.builtin.env` lookup, for example `lookup('ansible.builtin.env', 'DB_PASSWORD')`. 6. Give pipelines service tokens with OIDC binding instead of the vault password, then delete the plaintext files and retire the old password. Single variables encrypted with `encrypt_string` need to be decrypted one by one, since Ansible cannot rekey them in bulk either. Everyone who held the vault password could read every value it protected, so reissue the important ones at their providers after the move. If a playbook still needs a vault file, Crunu can [export an environment to Ansible Vault](https://crunu.com/integrations/ansible-vault) as a `keys.vault.yml` file with its own password. > **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 Ansible Vault alternatives [SOPS](https://crunu.com/alternatives/sops) also keeps secrets in Git, but encrypts only values and uses age, PGP or cloud KMS keys instead of one password. [SOPS vs Ansible Vault](https://crunu.com/compare/sops-vs-ansible-vault) covers that choice in detail. [git-crypt](https://crunu.com/alternatives/git-crypt) encrypts whole files with GPG keys per person, though it cannot revoke access once granted. If you want a vault service rather than encrypted files, [HashiCorp Vault](https://crunu.com/alternatives/hashicorp-vault) adds dynamic secrets, at the cost of running a cluster. The [roundup of secrets managers for small teams](https://crunu.com/guides/best-secrets-managers-small-teams) compares the wider field by use case. ## FAQ ### Is Crunu an alternative to Ansible Vault? Yes, for teams that use Ansible Vault to share environment secrets between people, servers and CI. Crunu replaces the shared vault password with per-person and per-machine keys for each environment. If you encrypt whole task files or templates, keep Ansible Vault for those. ### How do I move from Ansible Vault to Crunu? Decrypt your vault files with `ansible-vault decrypt` or `ansible-vault view` on a trusted computer, drag the plaintext files into Crunu environments, and run playbooks through `crunu run` with the `ansible.builtin.env` lookup. There is no importer for Ansible Vault files. ### What do I change in Ansible Vault when someone leaves? Choose a new vault password, run `ansible-vault rekey` on every encrypted file, and re-create variables made with `encrypt_string`, which cannot be rekeyed. Then share the new password with everyone who stays and reissue the values the person could read. ### Can Ansible still read secrets that live in Crunu? Yes. Start the run with `crunu run`, which passes the environment's variables to `ansible-playbook`, and read them in the playbook with the `ansible.builtin.env` lookup. Crunu can also export an environment to a `keys.vault.yml` file that `ansible-vault view` opens. ### Does Crunu keep a record of who decrypted secrets? Yes. Crunu records which versions of which environments each person and machine received, when and from where, in a hash-chained log kept 365 days by default. Ansible Vault protects data at rest and keeps no such record. ## Sources - [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) - [Ansible: env lookup plugin](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/env_lookup.html) (accessed 2026-10-30) - [ansible-vault command reference](https://docs.ansible.com/ansible/latest/cli/ansible-vault.html) (accessed 2026-10-30) - [Ansible license (GNU GPL v3)](https://github.com/ansible/ansible/blob/devel/COPYING) (accessed 2026-10-30)