How Crunu works: encryption, keys, machines and CI
How Crunu encrypts secrets on your devices, gives every environment its own key, and gets values to teammates, servers and CI without the server reading them.
On this page
Crunu is an end-to-end encrypted secrets manager for teams: .env files, API keys and cloud credentials are encrypted on your devices, and the server stores only ciphertext. This page explains how that works in plain language, from your first sign-in to a production server and a CI job, and where the design stops protecting you.
The short version
- Encryption and decryption happen only in your browser and in the
crunuagent, never on the server. - Your account key comes from your password and a Secret Key that never leave your device.
- Every environment, such as
stagingorproduction, has its own key. You only receive the keys of environments you were given. - People, servers and CI pipelines all follow the same rule: each decrypts for itself.
- Who may read an environment is a signed document, so the server can't add itself as a reader.
- When someone leaves, their access stops, the keys they held are replaced, and you get a list of the values they saw.
Your account key stays on your device
When you create an account, your device generates a Secret Key, a random string of about 128.8 bits. Your account key is derived from that Secret Key and your password together. Neither is ever sent to the server, in any form.
That is why a stolen copy of Crunu's database doesn't help anyone guess your password: every guess would also need your Secret Key. It is also why nobody can reset your password for you, including us. Your Emergency Kit, a printable page with your Secret Key, and an optional recovery code are how you get back in.
Details: Emergency Kit and Secret Key.
Every environment has its own key
Secrets live in projects, one per application, and each project has environments such as development, staging and production. Each environment is encrypted with its own random key, and every saved version is encrypted with it, using AES-256-GCM.
The environment key is then sealed separately to each person and machine allowed to read it, with their public key. A developer with access to development never receives the production key, so they can't read production even if the server sent them its ciphertext by mistake. Access is enforced by cryptography, not only by a permission check.
Details: organizations, projects and environments.
What the server stores, and what it sees
The server keeps ciphertext, public keys and signed documents. It decides whom to send each environment to, but it holds no key that could decrypt it at any point in the protocol. Each version is stored as one record, padded to whole 4 KB blocks, so the server sees neither the names of your variables nor their exact size.
The server does see metadata: the names of organizations, projects, environments and machines, email addresses, the audit log, and when each version was saved and roughly how large it is. Keep that in mind when you name things.
Details: what the server sees.
Signatures keep the server honest
Encryption stops the server from reading values. Signatures stop it from changing who can read them. The list of people and machines that may read an environment is a document signed by an owner or admin, and every version is signed by the person who saved it.
Browsers and agents check those signatures before they trust anything. They also remember the newest state they've seen and refuse anything older, so a server can't quietly roll an environment back on a device that has already seen a newer version.
Details: how encryption works.
Teammates join by invitation
An admin invites a teammate with a link that is valid for up to 7 days. When the teammate accepts, both compare a short fingerprint of the new account's key, so a server can't slip in a key of its own. From then on, the teammate receives the keys of exactly the environments their roles cover, as an Editor, a Reader, or for specific files only.
Details: invite your team and roles.
Servers run the crunu agent
A server that needs secrets is enrolled as a machine. An admin creates a single-use enrollment code; on the server, crunu enroll shows a fingerprint, and the admin approves the machine after comparing it. The machine gets its own keys and only the environments granted to it.
The agent decrypts on the machine and keeps the values in memory. crunu run starts your program with its variables, and crunu pull writes files with safe permissions where a program needs them. If the server is unreachable, the agent keeps serving the last verified state until its lease runs out, 24 hours by default. If you revoke a machine, it wipes its environments from memory at its next check, within minutes while it is online.
Details: machines and leases and install the agent.
CI pipelines use service tokens bound to OIDC
A CI job signs in with a service token that an admin creates in the browser and sees once. The token gets only the environments it needs, for example staging and nothing else.
On GitHub Actions, GitLab CI and Bitbucket Pipelines, or any other OIDC issuer, the token can also require the CI provider's OIDC token for a given repository, branch and deployment environment. A leaked service token is then useless outside that pipeline. The runner receives ciphertext and decrypts it itself, so CI follows the same rule as people.
Details: OIDC binding and connect your CI.
When someone leaves
Removing a person is handled as a security event. The server stops sending them anything at once, and every environment they could read gets a new key that is never sealed to them. Their service tokens, share links and pending invitations are revoked in the same step.
Encryption can't erase what someone already saw, so Crunu shows an exposure report of which versions they received and when, and a checklist of the values to reissue at the providers that issued them.
Details: offboarding a teammate and the offboarding feature.
What this design doesn't protect against
- A tampered web app. A server that has been taken over could serve a modified page. Signed releases, a reproducible build and a local
crunu.htmlfile reduce that risk; they don't remove it. - Malware on your devices. Anything that can read your screen or memory sees what you see.
- Values already seen. Rotation protects new versions. Old values stay valid until you reissue them at the provider.
- Metadata. Names, email addresses and the audit log are visible to the server.
The full list is on known limitations, and the security overview goes deeper into each part of the design.