Where Crunu’s protection ends
Encrypting on your devices means the server can’t read your secrets. It doesn’t make every risk go away. Here is every limit we know of, taken from the product’s own threat model, and what to do about each.
What encryption on your devices can’t stop
Crunu decrypts on your devices, so whatever controls a device, or the page it runs, can see what that device decrypts. Encryption also can’t take back what someone has already seen.
- A tampered page could capture your password and Secret Key.The page at app.crunu.com comes from the server, so a server that’s been broken into or run in bad faith could send one that records what you type. The app checks itself against Crunu’s signed manifest on every load, but that check runs inside the same page. On app.crunu.com you trust Crunu and its hosting with this; on your own server, whoever runs it. What to do: if the app warns “Build signature doesn’t match: do not enter your password”, don’t, and run your own server if the page must come from infrastructure you control.
- What someone has seen can’t be taken back.Removing a person or revoking a machine rotates the keys, so they can’t read anything new. Values they already saw keep working wherever those values are valid. What to do: run Remove from organization, go through the reissue checklist, and reissue each value at its provider, starting where it matters most.
- Whoever controls a device or a machine sees what it decrypts.Malware, a browser extension or root on your computer can read what’s decrypted there. Root on a machine with the agent sees everything delivered to it, and a running program keeps its variables until it restarts. What to do: use devices you control, give machines only what they run, and after a compromise use Device compromised or revoke the machine, then reissue its values.
What the server can still do
On app.crunu.com, Crunu runs the server; on your own server, its operator does. Either way, these limits also cover anyone who breaks into it. The server can’t read your environments, but it isn’t powerless.
- It sees metadata.The server reads the names of organizations, projects, environments, machines and people, email addresses, the audit log, who received which version and from where, and the time and size of each version. Nothing inside an environment, not even variable or file names. What to do: keep secrets out of names. A project named after an unannounced deal tells the server about the deal.
- It can refuse service or drop writes.A server can stop answering, or claim it never received a change, and encryption can’t force it to serve you. What to do: download an offline copy from time to time. It opens with your password and Secret Key, without any server. On your own server, export the database daily. During early access, app.crunu.com has no uptime commitment.
- It could show a new device an old view of your organization.Your devices refuse anything older than they’ve accepted, but a device you’ve never used has nothing to compare with. A compromised server, working with someone you removed, could show it your organization as it was before the removal. Crunu can’t fully close this without an outside source of freshness. What to do: on a new device, use Compare with your other devices in Organization settings, and if the numbers differ, save nothing from it and tell an owner.
- Network rules are its rules, not encryption.A compromised server can ignore an IP restriction. Everyone behind the same NAT or proxy shares one address, so they all count as inside, and content delivered before a restriction stays where it went. What to do: use network rules on top of narrow access, bind CI tokens with OIDC instead of relying on runner IP ranges, and after tightening a rule, reissue values that already left.
Recovery has hard edges
Because the server never holds your password or Secret Key, nobody can reset them for you. The ways back in are yours to keep safe, and they open more than you might expect.
- Nobody can reset your password.If you lose your password, your Secret Key and your recovery code, nobody can open your account, including us. If every owner and admin loses access, nobody is left to manage the organization. What to do: print the Emergency Kit and keep it away from your devices, create a recovery code, and keep at least two owners or admins.
- A recovery code skips your second factor.It opens your account after a waiting period, one hour by default. The server holds the wait and sends the alert, so a compromised server working with someone who has your code could hand over access at once. What to do: store the code apart from your Emergency Kit and devices, and if you get an alert about a recovery you didn’t start, cancel it and delete the code.
- Owners and admins can open shared environments.Every shared environment key is also sealed to the organization recovery key, which owners and admins hold. While personal environment recovery is on, the default, they can open members’ personal environments too. What to do: keep those roles to the few people who run the organization. An owner can turn personal environment recovery off, but then a lost account loses its personal environments.
- A stolen device holds your Secret Key.By default your browser keeps the Secret Key so you don’t type it at every sign-in, which leaves your password as the remaining barrier. What to do: use a strong password unique to Crunu, keep the idle lock short, and from another device remove the stolen one or use Device compromised.
If you run your own server
These are for whoever operates the server. On app.crunu.com, that’s Crunu. One of them affects your devices on any server, app.crunu.com included: restoring the database from a backup undoes every change made after it.
- Without email, invitation addresses aren’t confirmed.A server with no email set up can’t send a code to confirm the address on an invitation, so someone could take an address that isn’t theirs. Fingerprint matching still keeps a stranger’s key out. app.crunu.com has email set up. What to do: set
RESEND_API_KEYandALERT_EMAIL_FROMbefore inviting people from outside your team, and always match the fingerprint. SERVER_KEYis the server’s own secret.It signs sessions, share links and invitations and encrypts authenticator app secrets, but not your environments. Losing it signs everyone out and breaks share links. If it leaks with a database copy, it weakens authenticator app codes. What to do: keep the.envfile in a password manager, apart from backups, and rotate the key with the documented procedure.- A restore rolls everything back.Restoring a backup undoes every change made after it, and devices that saw newer data report a rollback and refuse those environments until their saved state is reset. What to do: back up daily, reset agents and browsers only after a restore you performed, and treat a rollback warning without one as a warning sign.
- Pick the address and platform with care.Sign-in signatures, share links, passkeys and agents are tied to the server’s address, so it can’t change later. On free Cloudflare Workers a request gets 10 ms of CPU time, and on Google Cloud Run and AWS App Runner some alerts arrive late. AWS has closed App Runner to new customers. What to do: use a domain you’ll keep, Workers Paid for a team, and a platform with a scheduler if those alerts matter.
Not in Crunu by design, or not yet
Some things Crunu doesn’t do. One never will, because it would need keys on the server. The others are missing today, so plan around them.
- No dynamic secrets.Crunu doesn’t create short-lived database passwords or cloud credentials on demand. That needs keys on the server, which is exactly what Crunu is built not to have, and this won’t change. What to do: use your provider’s short-lived credentials where it offers them.
- No automatic reissue at providers.Rotation in Crunu changes encryption keys. Values themselves are reissued at each provider by hand, from the reissue checklist. What to do: reissue long-lived credentials on a schedule, and save each new value as a new version.
- No time-limited access for people.Access to an environment has no expiry date. Expiry exists for invitations, share links, service tokens, machine leases and break-glass access. What to do: review who has access to production when people change roles, and use an expiring share link for one-off needs.
Questions about these limits
Can Crunu staff read my secrets?
No. On app.crunu.com, Crunu runs the server, and the server has only ciphertext and no key to decrypt it. We can see metadata such as names, email addresses and the audit log, listed in the Privacy Policy. Reaching your values would take changing the code that runs on your device, which is the first limit on this page.
Does running my own server remove these limits?
Some of them move to you. You decide who runs the server that sends the web page and sees the metadata, and you take on the limits in “If you run your own server”. The limits on your devices stay the same.
Why can’t you reset my password?
Your account key is derived on your device from your password and your Secret Key, and we never receive either. That’s what keeps your data unreadable to us. Your Emergency Kit and a recovery code are the ways back in.
What should we do first when someone leaves?
Remove them from the organization. Crunu stops serving them and rotates every key they held. Then go through the reissue checklist and reissue at each provider the values they saw.
Will Crunu add dynamic secrets?
No. Creating credentials on demand needs keys on the server, and Crunu is built so the server never has them.
Found a limit that isn’t on this page?
Write to security@crunu.com. We’d rather list it here than have you find it the hard way.
Put your team’s secrets where the server can’t read them
Create your account on app.crunu.com. Your keys are created in your browser, and the server gets only ciphertext.