Secrets

The secret store is a per-tenant encrypted key/value store for a single opaque string that no credential type models: a shared token a partner's endpoint expects in a custom header, a signing key one of your own nodes reads.

Values are encrypted at rest with AES-256-GCM and the service never returns them — not to the API, not to Cockpit, not to you.

Manage them in Cockpit, under Integration Studio → Secrets.

Keys

Keys match ^[A-Z0-9_]+$ — uppercase letters, digits and underscores. SUPPLIER_FEED_TOKEN, not supplier-feed-token.

Name them for what the value is for, not for where it came from: a key is the only thing anyone reading a workflow sees, so ACME_PORTAL_TOKEN is a better key than TOKEN_2.

Values are write-only

You can overwrite a secret, but you cannot read it back. If you lose one, you replace it; there is no recovery.

That is worth planning around before you store the only copy of something. Keep the authoritative copy wherever the customer keeps their credentials, and treat the platform's store as a place the value has been put, not the place it lives.

How a node uses one

A node that needs a secret declares a secret-reference configuration field. You pick a key there, and what is stored on the node is the key — something like SUPPLIER_FEED_TOKEN — and nothing more. The value is fetched inside the node as it executes.

The value is therefore never present in:

• the workflow document,
• a revision snapshot,
• the run history, or
• a step's recorded input and output.

See Node configuration for the field type.

Expressions cannot reach secrets

There is no secrets.* reference root, deliberately. The four expression roots are vars, nodes, trigger and in, and none of them touches the secret store — see Expressions.

The secret-reference field is the only way in. If a node you are wiring needs a secret in a place that only accepts an expression — a header value, say — that node needs a secret-reference field of its own; you cannot smuggle the value in through a workflow variable, because a variable's value is stored in the workflow document in the clear.

That is the boundary the design is protecting: a secret that could be interpolated into any field would end up in a run's recorded input the first time somebody debugged a flow.

Deleting one

Deleting a secret breaks any workflow that references it, the next time that workflow runs. As with credentials, Cockpit cannot yet tell you which workflows those are, so check before you delete.

A template's readiness check is the one place that counts secrets for you: it lists the keys a template references and says which are set and which are missing.

Where to go next

• Credentials — the structured alternative, and when to prefer it.
• Node configuration — the two reference field types side by side.
• Expressions — the four roots, and what they deliberately do not include.