CI/CD & containers

The pattern for every automated environment is the same: provide a service token, point the CLI at your API, and either run your command with secrets injected or export them. No passphrase is involved.

Store the token in your platform's secret store as SEEKRIT_TOKEN, and grant it only the environments that job needs.

GitHub Actions

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      SEEKRIT_TOKEN: ${{ secrets.SEEKRIT_TOKEN }}
      SEEKRIT_API_URL: https://api.your-seekrit.example
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @seekrit/cli
      - run: seekrit run -- ./deploy.sh    # secrets injected into the process

Docker

Prefer injecting secrets at runtime, not baking them into an image. Pass the token in and let the entrypoint fetch secrets:

# entrypoint.sh
#!/bin/sh
exec seekrit run -- "$@"

docker run --rm \
  -e SEEKRIT_TOKEN="$SEEKRIT_TOKEN" \
  -e SEEKRIT_API_URL="https://api.your-seekrit.example" \
  your-image ./start-server

If you must materialize a file (for tools that read .env), write it inside the container at startup and keep it out of any image layer:

seekrit export --format dotenv > /run/secrets.env

Kubernetes

Store the token in a Kubernetes Secret and reference it as an environment variable; run your app through the CLI:

env:
  - name: SEEKRIT_TOKEN
    valueFrom:
      secretKeyRef:
        name: seekrit-token
        key: token
  - name: SEEKRIT_API_URL
    value: https://api.your-seekrit.example
command: ["seekrit", "run", "--"]
args: ["./start-server"]

AI agent sandboxes

Ephemeral environments — like the throwaway sandboxes an AI coding agent spins up — are a natural fit: create a short-lived environment, grant a scoped token, and let the agent's process read secrets through the CLI without ever seeing long-lived credentials. Revoke the token when the sandbox is torn down.