Setting Up Redshift for Your CI/CD Pipeline

I recently wired up Redshift to three different CI platforms in the same week. The actual config is straightforward once you see it, but there were a few things I wish I'd known upfront. This is the guide I would've wanted.

Why Not Just Use the Built-in Secrets?

GitHub Actions, GitLab, CircleCI -- they all have secret storage built in. It works fine until you need to share secrets across platforms, or you realize that anyone with repo admin can read them, or you try to figure out who changed a value last Tuesday. The built-in options get you 80% of the way there, but the last 20% is where things get annoying.

Redshift takes a different approach: your secrets live on Nostr relays, encrypted to your identity, and get pulled in at runtime. The CI platform only ever holds one thing -- your Nostr key.

Prerequisites

Before setting up CI/CD integration:

1. Install Redshift locally: curl -fsSL https://redshiftapp.com/install | sh
2. Create a project and add secrets: redshift setup
3. Create a dedicated Nostr identity for CI (recommended for security isolation)

GitHub Actions Setup

This is probably where most people will start. Add your CI identity's nsec as a repository secret called REDSHIFT_NSEC, then your workflow looks like this:

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Redshift
        run: curl -fsSL https://redshiftapp.com/install | sh

      - name: Deploy with secrets
        run: redshift run -p my-project -e production -- ./deploy.sh
        env:
          REDSHIFT_NSEC: ${{ secrets.REDSHIFT_NSEC }}

The REDSHIFT_NSEC secret is your CI identity's private key. Redshift uses it to decrypt secrets from relays and inject them into your deploy script.

GitLab CI Setup

GitLab keeps CI/CD variables in project settings rather than a secrets tab. Go to Settings > CI/CD > Variables and add REDSHIFT_NSEC there. The pipeline config itself is pretty minimal:

# .gitlab-ci.yml
stages:
  - deploy

deploy:
  stage: deploy
  image: ubuntu:latest
  before_script:
    - curl -fsSL https://redshiftapp.com/install | sh
  script:
    - redshift run -p my-project -e production -- ./deploy.sh
  only:
    - main

CircleCI Setup

For CircleCI, you'll find environment variables under Project Settings. The YAML is a bit more verbose than the others, but the Redshift part is identical:

# .circleci/config.yml
version: 2.1

jobs:
  deploy:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: Install Redshift
          command: curl -fsSL https://redshiftapp.com/install | sh
      - run:
          name: Deploy
          command: redshift run -p my-project -e production -- ./deploy.sh

workflows:
  deploy:
    jobs:
      - deploy:
          filters:
            branches:
              only: main

Keep Your CI Identity Separate

Don't Reuse Your Personal Key

This is the one thing I'd really stress. Don't use your personal Nostr identity for CI. If that nsec leaks from a CI log or a misconfigured workflow, you don't want it to be the same key that holds your personal secrets. Generate a dedicated keypair:

# Generate a new keypair using any Nostr tool (e.g., nak, nostr-tools)
$ nak key generate
npub1abc...xyz
nsec1...

# Then login with the new identity
$ redshift login --nsec nsec1...

If the CI key does get exposed, you revoke that one identity and re-share secrets with a new one. Your personal stuff stays untouched.

Scope Secrets by Environment

Use different environments for different pipeline stages. Your test suite doesn't need production database credentials:

• -e ci for build/test jobs (limited secrets)
• -e staging for staging deployments
• -e production for production deployments (restricted access)

Rotate After Team Changes

When someone leaves the team, rotate your CI Nostr identity. Since secrets are encrypted to that identity, you'll need to re-share them with the new keypair -- but that's a feature, not a bug. It forces you to actually revoke access instead of just hoping the old credentials aren't saved somewhere.

Debugging CI Issues

If secrets aren't being injected:

1. Verify REDSHIFT_NSEC is set: echo $REDSHIFT_NSEC | head -c 10
2. Check your identity: redshift me
3. Verify project setup: redshift configure
4. Test locally with the same identity

Next Steps

Once this is running, you get secrets that travel with you across CI platforms, cryptographic access control without passing credentials around, and the same secret values locally and in CI. No more "it works on my machine" because of a missing env var.

For more details, see our CLI documentation or quickstart guide.