Secret Management for Open Source Projects

Your open source project has secrets. Here's how to manage them without a corporate account or a budget.

The Open Source Secret Challenge

If you maintain an open source project, you've dealt with this: you need API keys for CI, tokens for publishing, maybe credentials for test infrastructure. But the tools that manage secrets all seem to assume you're a company with a procurement department.

Meanwhile, you're juggling contributors who come and go, public repos where one bad commit exposes everything, and the nagging worry about what happens if you step away for a month. Traditional solutions either cost money or introduce dependencies that'll outlive your interest in the project.

Pattern 1: Environment Separation

This sounds obvious, but I've seen plenty of projects where the same NPM token gets used for local dev, CI, and production releases. Don't do that.

Keep your environments isolated. Use local-only credentials for development, dedicated CI tokens with minimal permissions, and production secrets that only the release automation touches. If a contributor's laptop gets compromised, it shouldn't matter for prod.

In Redshift, each environment is its own namespace, so you can hand out development access freely without anyone seeing production credentials.

$ redshift setup
? Select environment: development
? Select environment: ci
? Select environment: production

$ redshift run -e development -- npm test

Pattern 2: Minimal Permissions

Scope everything down. Read-only tokens for CI jobs that only need to fetch. API keys limited to specific actions. Credentials that expire on their own so you don't have to remember to rotate them.

The goal is blast radius. When (not if) something leaks, a token that can only read public package metadata is a non-event. A token with full admin access is an incident.

Pattern 3: Contributor Access Without Shared Secrets

I've learned this one the hard way. You share one set of credentials with all your maintainers, someone steps away from the project, and now you're rotating everything at 11pm because you're not sure they revoked access on their end.

Give each maintainer their own credentials instead. Define roles—release manager, CI admin—with specific permissions tied to each. Keep audit logs so you know who accessed what. It's more setup upfront, but future-you will be grateful.

Redshift's roadmap includes team features for exactly this: cryptographic access control without needing a central authority.

Pattern 4: Secrets in CI/CD

GitHub Actions, GitLab CI, and the rest all have built-in secret storage. Use it, but think about what you're actually storing there. Here's what a Redshift setup looks like:

# .github/workflows/release.yml
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Redshift
        run: curl -fsSL https://redshiftapp.com/install | sh
      - name: Publish Package
        run: redshift run -e production -- npm publish
        env:
          REDSHIFT_NSEC: ${{ secrets.REDSHIFT_NSEC }}

The CI platform only stores your Nostr identity. Actual secrets get fetched at runtime from decentralized relays, so you're not duplicating sensitive values across GitHub's secret store and everywhere else.

Pattern 5: The Bus Factor Solution

What happens if you take a two-week vacation and something breaks? Or, less charitably, what if you just lose interest?

At minimum: keep a private maintainer doc listing every secret and what it's for. Make sure at least two people can access critical credentials. Write down how to regenerate or rotate each one—you think you'll remember, but you won't.

With Redshift, you can share encrypted secrets with co-maintainers using their Nostr public keys. No central service in the middle, just cryptography.

Pattern 6: Public Secrets for Development

Not everything needs to be locked down. Public API keys for services with generous free tiers, test credentials for sandboxed environments, mock tokens that only work locally—these are fine to share openly.

Put them in a .env.example committed to the repo. New contributors should be able to clone, copy that file, and have a working dev environment without asking anyone for access. The fewer barriers to a first contribution, the better.

Getting Started

Redshift is free for individuals—no credit card, no corporate account needed. Your encrypted secrets live on Nostr relays, so even if Redshift disappears, your data doesn't.

Check the quickstart guide or create your first project.