Secrets

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 replaced or 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, and the name itself cannot be changed.

Rotating a value

Click Update value in the secret's row menu and enter the new value. The name, description, and sharing stay as they are, so every workflow and app already referencing the name keeps working and picks up the new value from its next step or cold start. The old value is overwritten and is not recoverable.

The action appears only for encrypted values and only for people who can manage the secret. A 1Password reference has no value stored here — rotate it in 1Password instead.

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 credential of the HTTP request node's authentication: the Token of Bearer, the Password of Basic, the Key value of an API key, or a Signature's Signing key. 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.

Store the raw credential. The secret resolves to its stored value, and the HTTP request's Authentication method adds any scheme: Bearer token sends Authorization: Bearer abc123 from a secret stored as abc123, and an API key's optional prefix (Token) goes in front of the same raw value. One secret can serve several header shapes, and rotating it never means retyping a prefix.

Secrets and MCP clients

An AI client connected over MCP can list the secrets it is allowed to use — id, name, kind, description, sharing, and when each was created, rotated, and last used — so it can reference one correctly when it writes a workflow. It can never read a value, and a name it cannot use is reported without saying whether the name is missing or simply not shared with it.

The description travels with the name. It is free text a connected client can read and search on, so treat whatever you write there — an account number, a vault path, a colleague's name — as visible to every client the workspace connects, the same way it is visible to everyone who can see the row on this page.

Creating, rotating, and deleting a secret stay here in Settings > Secrets. That is deliberate. A value sent to an MCP tool would pass through the model's context and the client's transcript before it ever reached encryption, and an agent-written audit entry cannot be attributed to a person the way this page's actions are.

Environment variables in the Run shell script node

The Run shell script 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 use the same injection and redaction path on Rollout and SSH targets, including SSH carried through a connectivity service

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. The confirmation lists what you can open that uses the secret: workflows (marked Current release, Draft, or both), apps and tools. Deleting is still allowed; when something listed uses it, the button reads Delete anyway. 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. The same Used by list is in the secret's details, next to its sharing.

Audit trail

Every secret action is recorded in an append-only audit log — creation, value updates, 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
  • HTTP request — the node most commonly paired with secrets