Secrets

Product documentation

Secrets are named values — API keys, tokens, signing keys — that workflow steps resolve at run time. They are write-only: a value is set once at creation and can never be viewed again, in the UI or anywhere else. Workflows reference a secret by name, and the value never appears in workflow configuration, run history, or logs.

Manage secrets at Settings > Secrets or /settings/secrets.

Secrets are encrypted at rest with envelope encryption. See Security for the encryption scheme, fail-closed reads, and key handling.

Creating a secret

  1. Go to Settings > Secrets
  2. Click New secret
  3. Enter a name, an optional description, and the value
  4. Click Create secret

The value is encrypted immediately and cannot be viewed again — only deleted. Use the description to record what the token is for and where it came from; once the value is sealed, the description is the only way to tell two tokens apart.

Names

Names are UPPER_SNAKE_CASE: a letter, then uppercase letters, digits, or underscores, up to 63 characters (for example DEPLOY_TOKEN). A name is a permanent reference — workflow steps look the secret up by name. To rotate a value, create a new secret under a new name, update your workflows, then delete the old one.

1Password references

When the workspace has a 1Password Connection (see Integrations), the create form offers a second type: instead of storing an encrypted value, a secret can point at a 1Password item.

  • Choose 1Password reference as the type, pick the 1Password Connection, and enter a reference in the form op://vault/item/field
  • The value is resolved through 1Password each time a workflow step uses the secret — it never touches Rollout’s database
  • Referenced secrets show an External badge in the list

If the reference cannot be resolved at run time, the step fails with an error rather than running with a missing value.

Sharing and access

A new secret is private: only its owner can use it or attach it to a workflow. Workspace admins do not bypass private secrets.

To share a secret, click Manage in its Access column and choose a scope:

  • Private — only the owner can use it
  • Team — team members inherit access through the team hierarchy
  • Workspace — anyone in the workspace can use it

Sharing controls both workflow authoring and runtime resolution: the same access is checked when a workflow referencing the secret is saved and again every time a step resolves the value. Revoking access takes effect on the next save or step execution. The access panel also lets the owner transfer ownership to another workspace member.

Using secrets in workflows

Secret fields on nodes

Some node settings are secret fields — for example the API Request node’s Signing key (for the Signed auth mode) and Secret header value with its companion Secret header name, which send a token in a custom request header. Pick a secret from the field’s list, or create one inline with Create & use without leaving the editor.

The node configuration stores only the secret’s name. The value is resolved when the step runs and is redacted from run output and history. Secret fields are not template fields — {{ }} expressions are not resolved in them.

Environment variables in the Shell node

The Shell node has a Secrets section listing secret names to inject into the command environment. Each name becomes an environment variable: a secret named DEPLOY_TOKEN is available as $DEPLOY_TOKEN.

  • Values are decrypted at step start, redacted from run history, and never persisted
  • An injected secret overrides an env entry with the same name
  • Secrets are not available when the Shell node runs on an SSH target — run it on the Rollout runtime instead

When resolution fails

Resolution is fail-closed. If a secret has been deleted, or the workflow’s owner loses access to it, the step fails with a structured error — it never runs with an empty value. In the editor, a secret field whose referenced secret is no longer available keeps the name and flags it rather than silently clearing.

Deleting a secret

Click Delete in the secret’s row. Deleting frees the name for reuse; the value cannot be recovered, and workflow steps that reference the deleted secret will fail until they are updated.

Audit trail

Every secret action is recorded in an append-only audit log — creation, deletion, sharing changes, and every read, including reads by workflow runs and lookups of names that don’t exist. Entries record the actor, action, outcome, and timestamp; secret values are never written to the log.

Workspace admins can review the trail at Settings > Audit or /settings/audit, filtered by action, actor, and date range. The Last used column on the Secrets page is derived from the same trail.

  • Security — encryption at rest, workspace isolation, and the full audit log
  • Integrations — Connections, including 1Password
  • API Request — the node most commonly paired with secrets