Usage Examples

CI / CD

The pattern is consistent across providers: store an API key as the CI provider's secret, expose it as ENVVAULT_TOKEN, optionally pin ENVVAULT_PROJECT and ENVVAULT_ENV, and run any envv command in your job. Use a service-account key with project scope and IP allowlist for tightest security.

# .github/workflows/deploy.yml
name: Deploy
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - name: Install envv
        run: curl -sSL https://envvault.com/install.sh | sh
      - name: Test
        env:
          ENVVAULT_TOKEN: ${{ secrets.ENVVAULT_TOKEN }}
          ENVVAULT_PROJECT: proj_xxx
        run: envv run -e test -- npm test
      - name: Deploy
        env:
          ENVVAULT_TOKEN: ${{ secrets.ENVVAULT_TOKEN }}
          ENVVAULT_PROJECT: proj_xxx
        run: envv run -e production -- npm run deploy

Use envv generate --type=github-actions to scaffold the env block when you don't want to invoke envv at runtime.

Best Practices for CI Tokens

Service-account keys. Create a dedicated key per CI pipeline; never reuse personal keys.

Project-scope. Restrict the key to the projects this pipeline deploys.

IP allowlist. Pin to the CI provider's IP ranges where available.

Short expiry. 30–90 days. Automate rotation in a calendar reminder.

Rotate on incident. Revoke and replace immediately if a build log leaks the token.