# 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

```yaml
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`](/docs/guides/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:

```dockerfile
# 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](/docs/guides/run#in-a-container) has a complete
multi-stage Dockerfile that downloads the binary from `run.seekrit.dev` and
verifies its checksum.

```bash
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:

```dockerfile
# 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:

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

> **Warning:** 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:

```yaml
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.