Every client's keys in their own place, and a clean handover
Agency work means many clients' cloud accounts, payment keys and databases, with people moving between projects. Crunu keeps each client in a separate organization, gives contractors only what their part of the work needs, and when the work ends, removes their access and tells you which values to replace.
Questions teams like yours ask
The questions that come up when a team like yours moves its secrets into one place. The guide below answers each of them.
- How do we keep one client's keys away from another's?
- How do we give a contractor only the environments they work on?
- How do we send a key to the client's staff without email or chat?
- Was the link we sent opened, and when does it stop working?
- What does a contractor still have when the project ends?
- Which values do we replace at the client's providers after a handover?
- How do we hand the whole setup over to the client?
- What record can we show the client afterwards?
The parts of Crunu that cover it
Every part works on the same rule: the server keeps ciphertext, public keys and signed documents, and never holds a key that opens your values.
Access control
Give each person, machine and pipeline only the environments they need, with roles backed by encryption keys rather than by server checks alone.
Learn more
Access links
Share selected files of an environment with someone who has no account, through a link whose decryption key never reaches the server.
Learn more
Offboarding
When someone leaves, the server stops serving them, the keys of their environments change, and a report shows what they saw and what to reissue.
Learn more
Audit log
Sign-ins, grants, versions, rotations and refusals go into a hash-chained log that you can verify in one click and export.
Learn more
Encrypted vault
Keep .env files, cloud credentials and API keys in projects and environments, encrypted on your devices before anything reaches the server.
Learn more
How it works for agencies and contractors
On this page
Two ways client secrets go wrong
Secrets from different clients end up side by side in one shared folder. And access outlives the contract: the contractor who finished in spring still has the staging database password in summer.
The job is to keep every client separate, give each person only their part, and close everything at the end with a record you can show the client.
Separate by client, narrow by person, closed at the end
- One client, one organization. One account can belong to several organizations, and anyone who's signed in can create a new one. Each organization has its own members, projects, machines, keys and audit log.
- Contractors see only their part. Grant Editor or Reader on the environments they work on, or Specific files to give them a sealed copy of only the files you choose.
- Access profiles per role. Keep one profile for front-end contractors and another for whoever deploys. Changing a profile updates everyone in it, and each version is signed.
- Files for people without an account. A share link sends selected files from an environment. Set an expiry of up to 365 days, a view limit as low as once, and a password. The decryption key sits after the
#in the address, which the server never receives. - Previews don't spend a link. A view counts only when the recipient clicks Open, so a chat app's link preview doesn't use it up. The decrypted files live only in the page's memory.
- A clean exit. Member removal shows what the person received, rotates the keys of every environment they could read, revokes the tokens, share links, invitations and enrollment codes they created, and lists the values to reissue.
- A record for the client. The audit log is a hash chain of sign-ins, versions, links and removals. Verify it in one click and export it as JSONL.
From kickoff to handover
- Kickoff. Create an organization for the client, or ask to be invited into theirs if they already use Crunu.
- Set up. One project per app, with its environments. Production goes only to the people who deploy.
- Staff it. Invite contractors and give each an access profile for their role.
- Hand over files. Send one-off credentials to the client's staff with a share link instead of email.
- Close. Remove contractors with the member removal wizard, download the report, and work through the reissue checklist.
- Hand over the organization. An owner invites the client's lead as an Owner, who can then remove your team. Removing an admin or owner also replaces the organization's signing and recovery keys.
What to plan for
- A person's access doesn't expire on its own. There's no end date in an environment's access list. Remove contractors when they finish. Share links, invitations and service tokens do expire.
- What a contractor saw stays with them. Crunu tells you which values they received; you reissue those values at each provider. Crunu doesn't rotate values at providers for you.
- Crunu manages access inside Crunu. Remove the person from cloud consoles, repositories and CI separately.
- A link without a password opens for anyone with the full address. Add a password for anything sensitive. With a password set, nobody can even download the ciphertext without it, and guesses are checked online, under limits.
- Up to 100 new share links per account per day.
Each limit, with what to do about it, is on the limitations page.
Related docs
Questions and answers
Not covered here? Write to support@crunu.com and a person will answer.
Can one person work in several client organizations?
Yes. One account can belong to several organizations, and you switch between them in the app. Keys, members and logs stay separate per organization.
How do I give a contractor access for three months?
You can't put an end date on a person's access. Remove them when the work ends. For one-off files, use a share link with an expiry instead.
Can a contractor see production?
Only if you grant it. Without the production key they can't decrypt production, whatever the server sends them.
What can we give the client at handover?
The downloaded removal report, which lists what each removed person received, when and from where; an export of the audit log as JSONL; and the reissue checklist, which names the values to replace without showing them.
Does the recipient of a share link need an account?
No. They open the link in a browser, check that the owner's signature is verified, and can save the files or download an install script that puts them in place on a computer or server.
Can I see whether a link was opened?
Yes. Each link shows its status and a view counter, and opening it is recorded in the audit log.