Connect CI

Create a service token for one pipeline, store it as CRUNU_TOKEN, add the CI setup values, and run your tests with only the environment the job needs.

Last updated October 27, 2026

On this page

A CI pipeline reads its variables from Crunu with a service token and the crunu command. The token gets only the environments you choose, so a pipeline that runs tests never holds the production key.

Example. Kiteline is a fictional company. Priya creates github-actions-web-app for the web-app repository. It reads only web-app / staging and works only in jobs of kiteline/web-app on main.

1. Create the token

Owners and admins create service tokens. On Service tokens, choose New token:

Name, such as github-actions-web-app.
Environments, only those the job needs, such as web-app / staging. The dialog warns you if the token would get a production environment.
Lease duration, from 1 hour to 30 days. The token stops working if it isn't used for longer. Leave room for weekends and pauses between runs.
Optional: Networks and a Usage limit.
Optional: tick Add a CI binding (OIDC) right after creating to bind the token to your repository and branch.

Choose Create token.

2. Store the token

The token is shown only once. The server knows only its public keys and can't show it again. Copy it and store it right away in your CI's protected variables as CRUNU_TOKEN.

The same window has a CI setup block with tabs for Bitbucket Pipelines, GitHub Actions and GitLab CI. It lists the other variables to add:

Variable	What it is
`CRUNU_TOKEN`	the token, marked secret
`CRUNU_SERVER`	the server address, `https://app.crunu.com` for the cloud
`CRUNU_VERSION`	the `crunu` version to install
`CRUNU_INSTALL_URL`	the address of the install script for that version
`CRUNU_INSTALL_SHA256`	the install script's checksum
`CRUNU_BINARY_SHA256`	the binary's checksum

The version and checksums come from the signed release manifest. Only CRUNU_TOKEN is a secret.

Use Copy example under Pipeline step to get a step for your CI. Then tick I've saved the token and choose Done.

3. Add the step to your pipeline

The step installs a pinned crunu without root, checks both checksums and runs your command:

Shell

curl -sSf "$CRUNU_INSTALL_URL" -o /tmp/crunu-install.sh
echo "$CRUNU_INSTALL_SHA256  /tmp/crunu-install.sh" | sha256sum -c -
sh /tmp/crunu-install.sh --version "$CRUNU_VERSION" --sha256 "$CRUNU_BINARY_SHA256" --user-install
exec crunu run --env web-app/staging -- npm test

crunu run signs in with the token, verifies everything against the organization key whose fingerprint is built into the token, decrypts the variables in memory and starts your command with them. Nothing is written to disk.

Ready-made versions for each CI:

GitHub Actions, with the setup-crunu action;
GitLab CI, with the .crunu template;
Bitbucket Pipelines, with the crunu run pipe;
any other CI that runs a shell on Linux or macOS.

4. Keep the token contained

Set CRUNU_TOKEN only on the step that runs crunu, not on the whole job.
Start crunu with exec, so the step's shell doesn't keep the token.
Give the token the smallest grant, and production only with a CI binding.

Production deploys

The recommended setup keeps production secrets out of CI. The production server runs the agent and fetches its own secrets, and the pipeline only ships code and restarts the service. See Install the agent.

If a job really needs a production value, for example to push variables into a hosting platform, give it a separate token bound to the main branch and the production deployment environment. See Bind a service token to CI with OIDC.

If the token leaks

Revoke it in Service tokens, rotate the keys of the environments it had, reissue the values in them at their providers, and create a new token. With a CI binding, a leaked token is useless outside the bound pipeline. See Service tokens.