Secrets

A secret is a named value (or a reference to one) that jobs and deployments can use without it appearing in YAML, logs or the UI.

Scopes

Scope	Visible to
org	Every project in the org (subject to allow-lists)
project	Jobs in that project (default)
environment	Only deploy jobs bound to that environment, after protection rules pass

A secret can additionally list allowed_pipelines and allowed_environments, so a production credential cannot be pulled by an arbitrary pipeline.

Kinds

• static: the value is stored, encrypted.
• external_ref: only a reference is stored (for example vault://kv/data/app#password or aws-sm://eu-west-1/prod/db). The value is fetched at job start using the job’s identity and never stored in Slipway.

slipway secret set DATABASE_URL                      # prompts, value is never echoed
slipway secret set API_KEY --from-file ./key.txt
printf %s "$TOKEN" | slipway secret set TOKEN --stdin
slipway secret set DB_PASSWORD --external-ref vault://kv/data/app#password
slipway secret set STRIPE_KEY --env production       # environment scope
slipway secret list                                  # names and metadata only

Values are write-only: there is no API to read one back. To change a value, set it again (a new version). last_used_at is tracked so stale secrets are easy to find.

Using secrets

steps:
  - run: ./deploy.sh
    env:
      DATABASE_URL: ${{ secrets.DATABASE_URL }}

Allowed in env, with and services.env. Not allowed in name, run or if: the validator rejects direct interpolation into shell text. See Validation.

Encryption

Slipway uses envelope encryption:

1. Each org has a keyring: metadata for its key-encryption key (KEK), with rotation history.
2. Each secret is encrypted with its own data key using AES-256-GCM.
3. The data key is encrypted by the org’s KEK. The KEK lives in a KMS, or in the local keyring derived from the master key.

KEK providers (keyring.provider): local, aws_kms, gcp_kms, azure_kv and vault_transit. Enterprise adds HSM-backed keys.

Bring your own key (Team and above)

Point the org keyring at a key you control in AWS KMS, GCP KMS, Azure Key Vault or Vault transit. Revoking Slipway’s access to the key makes the org’s secrets unreadable. Rotating the KEK re-wraps the data keys without re-encrypting every secret.

Self-hosting: the master key

On a self-hosted install the local keyring is protected by SLIPWAY_MASTER_KEY. Losing it loses every stored secret. Back it up separately from the database, or use a KMS-backed keyring. See Backups.

External secret managers

Slipway can resolve references from HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, 1Password Connect, Doppler and Infisical. See Secret manager integrations. The usual setup uses OIDC job tokens so the job authenticates to the manager with its own identity and no static credential is stored anywhere.

Masking

Every secret value delivered to a job is registered with the runner’s masker, which replaces it in log output before the lines leave the runner. Runtime-generated values can be masked with ::mask::. See Workflow commands.

Auditing

Creating, rotating, deleting and using a secret are audit events, with actor, scope and (for use) the run and job. See Security and compliance.