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.
The difference in brief
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.
Ansible Vault is the better pick when
- Your deployments are Ansible playbooks, and secrets should sit next to the roles that use them.
- A few people share a few secrets, and one password in a password manager is enough.
- You want no service at all, only the ansible-vault command that ships with Ansible.
Crunu is the better pick when
- You want to stop handing one vault password to every person and every CI job.
- Removing someone should rotate keys and list the values to reissue, not mean a rekey of every file.
- You need a record of who received which secrets, which Ansible Vault does not keep.
Ansible Vault and Crunu, property by property
The same 14 questions we ask of every tool, answered from Ansible Vault’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 | Ansible Vault | Crunuour product | What it changes for you |
|---|---|---|---|
| Separate key per environment | 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. |
| Decrypted only on your devices | 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 | 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 | 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 | 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 | 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 | 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. |
| Audit log | 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 | 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 | 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 | 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 | 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 | 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 | 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 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.
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.
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.
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 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.
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 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
- Create an account and save your Emergency Kit before anything else.
- Create a project for each application or inventory, and an environment for each vault ID or stage you use, such as
developmentandproduction. - On a trusted computer, decrypt each vault file with
ansible-vault decrypt --output <file> <vault-file>, or print it withansible-vault view, and save the variables you need as.envor YAML files. - Drag the files into the matching environments and invite the team, giving each person a role per environment.
- Run playbooks through
crunu run --env <project>/<environment> -- ansible-playbook site.ymland read the values with theansible.builtin.envlookup, for examplelookup('ansible.builtin.env', 'DB_PASSWORD'). - 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 as a keys.vault.yml file with its own password.
Other Ansible Vault 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 covers that choice in detail. 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 adds dynamic secrets, at the cost of running a cluster. The roundup of secrets managers for small teams compares the wider field by use case.
More facts, row by row
Details beyond the 14 questions above, as this comparison states them.
| 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 |
Sources
Every page this comparison relies on, and the day we last verified it.
- 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
- Ansible: env lookup plugin · checked October 30, 2026
- ansible-vault command reference · checked October 30, 2026
- Ansible license (GNU GPL v3) · checked October 30, 2026
Questions about Crunu and Ansible Vault
Something else? Write to support@crunu.com
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.