Variables vs. secrets
Values are typed —
string, number, boolean, object, datetime, or file — so a flow gets the right shape when it reads one. An object value must be a single object, not a bare scalar or a list.
Scopes
- Workspace variables — shared across everything in a workspace. Manage them in workspace settings.
- Workflow variables — scoped to a single flow, for values that only that flow needs.
Where a value comes from
A variable’s source is where its value lives:- Manual: the value is stored with the variable. Secrets are encrypted at rest.
- Vault: the value is fetched from a vault integration (path and key) each time it is used.
- Environment (enterprise deployments only): the value is read at run time from an environment variable of the backend and worker processes, by the name you give. Nothing is stored on the platform, so this is the way to hand a credential to workspaces from the deployment itself.
AWS_*, AZURE_*, GOOGLE_APPLICATION_* and so on) are refused when the secret is saved and again when it is resolved. Expose the value under a name of your own instead. A platform administrator can also turn the Environment source off for the whole deployment from Settings › System › Security; the option then shows why it is unavailable, and secrets that already use it fail to resolve until they are switched to another source.
Using them
In flows
Reference a variable from a node’s config instead of typing a literal, so one change updates every flow that uses it.
For credentials
Store an API key as a secret, then reference it where a node or integration needs it — the value never appears in the flow definition.