Skip to main content
The Krypt CLI works the same in CI as it does on your laptop. Generate an API key, store it as a CI secret, and use krypt pull or krypt run in your pipeline to inject secrets without committing .env files.

​
Generate a CI-specific API key

Create a separate API key for each CI environment. This lets you revoke a single key without disrupting other pipelines.
1

Open the API keys page

Go to krypthq.com/dashboard/api-keys.
2

Generate a new key

Click Generate Key and name it descriptively — e.g. “github-actions-staging”, “gitlab-production”, “vercel-preview”.
3

Copy the key

Copy the key (starts with krypt_live_). It’s shown only once.
4

Store in your CI provider

Add the key as a secret/variable in your CI provider’s settings. Never hardcode it in your pipeline file.
Use one key per environment per CI provider. If your staging CI is compromised, you revoke only that key — production keeps running.

​
GitHub Actions

Write secrets to .env before your build step:
Store KRYPT_API_KEY as a GitHub Actions secret: Repository → Settings → Secrets and variables → Actions → New repository secret.

​
GitLab CI

Same pattern in .gitlab-ci.yml:
Store KRYPT_API_KEY in GitLab: Settings → CI/CD → Variables. Mark it as masked and protected for production branches.

​
Vercel deployments

Vercel doesn’t run arbitrary CI steps during its build process. Two options: Option 1 — Build command override In your vercel.json or project settings, set the build command to install Krypt and pull secrets before building:
Add KRYPT_API_KEY as an environment variable in your Vercel project settings. Option 2 — Separate CI job Use GitHub Actions (or another CI) to pull secrets and deploy to Vercel:
For most Vercel projects, adding env vars directly in the Vercel dashboard is simpler. Use Krypt’s CI integration when you manage many environments or want centralized secrets across multiple platforms.

​
Other CI providers

The same pattern works everywhere: install the CLI, login with a stored API key, pull or run.

​
Security best practices

Follow these rules to keep your CI pipelines secure:
  • Never echo secrets to logs — avoid printenv, echo $SECRET, or verbose build flags that dump env vars
  • Scope keys to environments — production keys should only exist on production deploy jobs
  • Rotate keys regularly — regenerate CI keys from the dashboard on a schedule (monthly or quarterly)
  • Revoke immediately if compromised — if a CI environment is breached, revoke its key instantly from the dashboard
  • Use a unique key per CI environment — never share keys across staging and production

​
Troubleshooting

​
”Not authenticated” in CI

Cause: The KRYPT_API_KEY secret is not set, misspelled, or not accessible to the job. Fix: Verify the secret name in your CI settings matches what’s in your YAML exactly. In GitHub Actions, check that the secret is available to the repository (not just the organization level). In GitLab, check variable scope and protected branch settings.

​
Secrets pulled but missing in next step

Cause: Each CI step runs in a fresh shell. Environment variables exported in one step don’t carry to the next. Fix: Either use krypt run to wrap the command that needs secrets, or use krypt pull to write a .env file that your application loads at startup (via dotenv or your framework’s env loading).

​
Rate limiting in CI

Cause: High-frequency CI runs hitting Krypt’s rate limit (600 requests per 15 minutes per API key). Fix: Cache the pulled .env file between steps so you only call krypt pull once per job. If you need higher limits, contact support@krypthq.com.