---
title: Safe CI/CD
description: Resolve Safe references in CI/CD jobs without leaking values into scripts, logs, or process metadata.
section: Safe
order: 6
updatedAt: 2026-06-09
slug: safe/ci-cd
---
# Safe CI/CD

CI/CD should use explicit Safe references only. Resolve values at the job boundary, inject them into the child process, and install redaction rules before the process starts.

## Package script pattern

```jsonc
{
  "scripts": {
    "deploy": "cuitty-safe run --scope acme/prod -- bun run deploy:raw",
    "registry:publish": "cuitty-safe run --scope acme/registry -- bun publish"
  },
  "cuittySafe": {
    "env": {
      "DATABASE_URL": "acme/prod/database-url",
      "REGISTRY_TOKEN": "acme/registry/publish-token"
    }
  }
}
```

## Job flow

1. Load job configuration.
2. Build the Safe reference set.
3. Request a Safe run plan.
4. Resolve values from the configured provider.
5. Inject resolved env only into the child process.
6. Install redaction rules for logs.
7. Emit audit metadata without values.

## Service accounts

For 1Password-backed production CI, use a least-privilege service account scoped to the required vault and fields. Cuitty Safe should read the token from the CI provider's secret store, commonly exposed as `OP_SERVICE_ACCOUNT_TOKEN`.

```bash
cuitty-safe connector 1password test --scope acme/prod
cuitty-safe run --scope acme/prod -- bun run deploy:raw
```

## Cuitty Code and Registry

Cuitty Code can resolve app manifest env, runner env, mirror credentials, webhook signing secrets, OAuth app credentials, deployment keys, Airflow tokens, and Dagger tokens.

Cuitty Registry can resolve npm publish tokens, Cargo registry tokens, PyPI upload tokens, OCI credentials, artifact storage DSNs, signing keys, and provenance keys.

Do not resolve Safe refs inside tight package download paths unless explicitly configured.