Crunu vs 1Password for team secrets

1Password is a password manager with a set of developer tools: service accounts, a self-hosted Connect server, a CLI that passes secrets to processes, and Environments for project variables. Crunu is narrower: a vault for environment variables, cloud credentials and API keys, with an agent for machines and CI pipelines.

Both encrypt on your devices, and both combine the account password with a Secret Key stored on your devices. Crunu's sign-in model follows the design in 1Password's security white paper. The differences are in removing people, running the server and delivering secrets to machines.

Who each one fits

1Password fits teams that want one tool for website logins, passkeys, shared passwords and developer secrets. It has apps for Mac, Windows, Linux, iOS and Android, plus browser extensions. If your company already runs 1Password Business with single sign-on and automated provisioning from an identity provider, developer secrets can stay in the tool your admins already manage.

Crunu fits engineering teams whose real problem is .env files, ~/.aws/credentials and API keys spread across laptops, chats and CI settings. It is built around projects, environments, machines and pipelines, and around the day someone leaves the team. It also fits teams that want to run the vault server on their own infrastructure.

Side by side

Where 1Password is stronger

• Breadth. 1Password covers logins, passkeys, autofill and developer secrets on desktop and mobile. Crunu has no mobile apps, no browser extension and no Windows agent.
• Identity integration. 1Password Business connects to identity providers such as Okta, Microsoft Entra ID and Google Workspace for sign-in and provisioning. Crunu has no SSO and no SCIM.
• Assurance. 1Password says it is SOC 2 Type 2 certified, publishes the results of independent audits and runs a bug bounty program. Crunu is a new product in early access and does not publish a SOC 2 report or an external audit.
• Kubernetes and SDKs. 1Password offers a Kubernetes Operator, a Secrets Injector, Helm charts, and SDKs for Go, JavaScript and Python. Crunu has none of these; applications use crunu run.
• Cloud sync. 1Password Environments can sync variables to AWS Secrets Manager, a feature 1Password labels beta. Crunu has no built-in sync to cloud secret stores.

What happens when someone leaves

This is the clearest design difference, and 1Password documents it plainly. Each vault member holds a copy of the vault key encrypted to their public key. On removal, that copy is deleted from the server, the server stops sending vault data, and the client is told to delete local copies. The white paper states that removal is not cryptographically enforced and keys are not changed. Someone who saved the vault key earlier could read later items only if they also obtained updated encrypted data. 1Password's suggested mitigation is to move items into a new vault, which has a new key.

Crunu rotates keys on removal. The server stops serving the person, and every environment they could read gets a new key they never had. When an administrator leaves, the organization's signing and recovery keys are replaced too. The member removal flow shows which versions the person received and lists the values to reissue at each provider.

Neither product can make a person forget what they already saw. Those values stay valid until you reissue them at the provider, as Crunu's limitations page explains.

Moving to Crunu

1. Create an account. Your keys are created in the app. Save the Emergency Kit before anything else.
2. Create a project for each application and an environment for each stage, for example development, staging and production.
3. On a trusted computer, put the values you need into .env files, or INI files for tools like the AWS CLI.
4. Drag the files, or folders such as .aws, into the environment. Crunu reads KEY=VALUE files, INI sections, flat YAML and plain text.
5. Invite your team and give each person a role per environment: Editor, Reader, Specific files or Operator.
6. Enroll your servers as machines and give pipelines service tokens, then delete the plaintext files you created in step 3.