Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.capy.sc/llms.txt

Use this file to discover all available pages before exploring further.

GitHub Actions runners are Node-capable containers. You can run capy run in any workflow step that needs decrypted secrets - builds, tests, deploys, anything that reads process.env.

​
Workflow

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      SECRETS_BLOB: ${{ secrets.CAPY_SECRETS_BLOB }}
      PROJECT_KEY: ${{ secrets.CAPY_PROJECT_KEY }}
    steps:
      - uses: actions/checkout@v4

      - uses: oven-sh/setup-bun@v1

      - name: Install deps
        run: bun install

      - name: Install Capy
        run: bun add -g @capy/cli

      - name: Test
        run: capy run -- bun test

      - name: Build
        run: capy run -- bun run build

      - name: Deploy
        run: capy run -- <your deploy command>
The two GitHub Secrets the workflow reads:
  • CAPY_SECRETS_BLOB
  • CAPY_PROJECT_KEY
Set them via Settings → Secrets and variables → Actions in your repo, or gh secret set: 
capy deploy       # pick GitHub Actions; copy the values

gh secret set CAPY_SECRETS_BLOB --body "<value>"
gh secret set CAPY_PROJECT_KEY --body "<value>"

​
One job, one decrypt

Every step under the job’s env: block inherits SECRETS_BLOB and PROJECT_KEY. Each capy run invocation does its own service fetch, but the job-level env means you don’t have to pass them per step. If you want to share a single decryption across steps, run capy run once to produce a file and have subsequent steps read it. Example for Next.js builds that produce a .capy/next-env.js manifest: 
- name: Build (emits .capy/next-env.js)
  run: capy run -- bun run build

- name: Upload artifact
  uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: |
      .next/
      .capy/next-env.js

​
Per-environment secrets

For deploys that target multiple environments (production, staging), use GitHub’s environment secrets. Each environment has its own CAPY_SECRETS_BLOB and CAPY_PROJECT_KEY, so the same workflow deploys different secrets to different targets based on environment: in the job. 
jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production
    env:
      SECRETS_BLOB: ${{ secrets.CAPY_SECRETS_BLOB }}
      PROJECT_KEY: ${{ secrets.CAPY_PROJECT_KEY }}
    steps:
      - run: capy run -- <deploy cmd>

​
Pull requests from forks

By default, GitHub Actions doesn’t pass secrets to workflows triggered by PRs from forks - a security baseline. That means forked-PR builds can’t decrypt with Capy. Usually fine: run CI without decrypted secrets, use mock values, or gate deploy jobs on github.event.pull_request.head.repo.full_name == github.repository.