seekrit

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. The token is bound to one application environment, so seekrit run/export need no --app/--env flags — it resolves its own org, app, environment, and composed groups.

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. In containers the best fit is seekrit-run — a tiny static binary with no Node/OpenSSL/CA dependency, so it works in distroless, alpine, and scratch images. Copy it in and make it the entrypoint:

# Fetch the static musl build in a build stage (see the run guide for the full
# pinned + checksum-verified version), then copy it into your runtime image.
COPY --from=seekrit /usr/local/bin/seekrit-run /usr/local/bin/seekrit-run
ENTRYPOINT ["seekrit-run", "--"]
CMD ["./start-server"]

The seekrit-run guide has a complete multi-stage Dockerfile that downloads the binary from run.seekrit.dev and verifies its checksum.

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

If Node is already in your image you can use the CLI instead — same behavior:

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

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
caution

Never seekrit export into a build stage that gets committed to an image layer. Fetch secrets at container start, into a tmpfs or process environment.

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.

note

A dedicated agent-proxy that swaps tokenized placeholders for real credentials on outbound requests (so an agent never sees secret values at all) is on the roadmap. The grant/wrap model already supports it — a proxy is just another principal.