Pipelines get only the secrets you grant
A service token is created in your browser and shown once; the server keeps only its public keys. Grant it the environments a pipeline needs, and add an OIDC binding so it works only inside the right repository and branch.
- Tokens read only what you grant
- OIDC binding for GitHub, GitLab and Bitbucket
- Production can stay out of CI entirely
A token that can’t open more than you gave it
A crunu_svc_ token is generated entirely in the admin’s browser and shown once. It reads only the environments you grant: a token for development never receives the production key.
- Lease, uses and networksGive a token a lease, a usage limit from 1 to 1,000,000 uses, and the networks it may come from.
- Bound to your repositoryWith an OIDC binding, the token works only together with your CI provider’s token for the repository, branch and deployment environment you chose. A replayed provider token is rejected.
- Every use is recordedToken sign-ins and denials appear in the audit log, and a replayed CI token raises an alert.
Three lines in the pipeline
Store the token in your CI’s secret variables as CRUNU_TOKEN, install a pinned version of crunu, and run the step through crunu run. Variables are decrypted in memory and nothing is written to disk.
- A pinned, checked installThe app shows the install command with exact checksums from the signed release manifest.
- Ready-made wrappersA GitHub Action, a GitLab template and a Bitbucket pipe install a pinned version and check its SHA-256.
- Exit codes pass through
crunu runreturns the exit code of the program it ran, so a failing test still fails the step.
What each CI system can check
The agent finds the CI provider’s token by itself in GitHub Actions, GitLab CI and Bitbucket Pipelines. Any other CI works with a token in its secrets.
| CI system | The OIDC binding checks | Wrapper |
|---|---|---|
| GitHub Actions | Repository, ref, deployment environment | Action setup-crunu, copied into your repository |
| GitLab CI | Project path, ref, ref type, deployment environment | Templates .crunu and .crunu-oidc |
| Bitbucket Pipelines | Repository, branch, deployment environment | A crunu run pipe, image built by you |
| Any OIDC provider | Any issuer, keys through OIDC Discovery | Token and crunu run |
| Any CI without OIDC | Token only | Token and crunu run |
Keep production out of the pipeline
The recommended setup never sends production secrets through CI. The agent runs on the production machine, and the pipeline only restarts the service.
- The machine fetches its ownThe production server is enrolled as a machine and receives its environment directly.
- CI only restartsThe deploy step restarts the service;
crunu run --restart on-changealso restarts it when values change. - When CI must touch productionUse a separate production token with an OIDC binding, approved by an owner, with every delivery in the audit log.
What to know before you wire it up
Tokens keep production out of reach. Some parts of the CI story are still recipes rather than buttons.
- Wrappers aren’t in marketplacesCopy the GitHub Action into your repository, and build and publish the Bitbucket pipe image yourself.
- No built-in platform syncNo integration pushes values into Vercel, Cloudflare, AWS Secrets Manager or GitHub Secrets. The documented way is a recipe with crunu run.
- The step reads what it getsWhatever runs inside the job sees the variables it receives. Grant the smallest set of environments.
- Bind production tokensA token without an OIDC binding works from any allowed address until it’s revoked or reaches its lease or usage limit.
Answers to common questions
Something else? Write to support@crunu.com
If a token leaks, can it read production?
Not unless you granted it production. A development token never receives the production key. With an OIDC binding, a leaked token doesn’t work at all without your CI provider’s token for the right repository and branch.
Do I need OIDC?
No. Any CI can use a service token stored in its secrets. OIDC adds a second check that ties the token to your repository and branch.
Where is the token stored?
In your CI’s secret variables. The server keeps only the token’s public keys, which is why it’s shown once and can’t be recovered.
Can a token be used only a few times?
Yes. Set a usage limit anywhere from 1 to 1,000,000 uses, plus a lease and allowed networks.
Can Crunu push variables into Vercel or Cloudflare?
Not with a built-in sync. You can do it from a pipeline step with crunu run and the platform’s own command, using an OIDC-bound token.
Take production secrets out of your pipeline
Create a token for one staging environment and run your tests with crunu run.