Environment variables

What they are

Environment variables are values tied to your user account, not to a single workflow or step. They are intended for API keys, tokens, and other sensitive configuration you want to reuse across many graphs, without storing the secret on the canvas itself.

In the editor you reference them like any other expression variable, for example {{env.vercel_api_key}}. At run time the workflow engine substitutes the stored value from a secure store (see Secure storage below).

Environment variables are not the same as workflow constants ({{const.api_base_url}}, set under Workflow settings) or workflow globals ({{global.tenant_id}}, built on upstream steps during a run). Keeping those namespaces separate helps you choose the right place for each kind of value.

How they differ from constants and globals

Creating variables

Open Settings → Environment variables in the app (under the main Settings section in the sidebar).

1. Choose Add variable and enter a key. Keys are normalised as you type: lowercased, spaces become underscores, and only letters, numbers, hyphens, and underscores are kept (for example vercel_api_key). The key cannot be changed after you save.
2. Add an optional description (up to 250 characters) so you remember what the value is for.
3. Enter the value. Use the eye icon on the right of the field to show or hide what you are typing so you can confirm it before saving.
4. Save. The list shows a masked value (••••••••); Dailify does not show the plaintext again in Settings after save. To change the secret, use Edit value on the row menu.

Using them in workflows

Use the same {{…}} syntax as other expression variables. Examples: {{env.stripe_secret_key}} in a webhook header, or {{env.internal_api_base}} in a URL template.

• Where they work: Execution fields (prompts, code bodies, webhook URL/headers/body), gate value cells, and other tag-capable inputs. Tags resolve in the base context before the step runs (same phase as {{input.*}}, {{const.*}}, and {{global.*}}).
• Autocomplete: In the workflow editor, type {{ and pick entries labelled Env · your_key.
• Validation: Validate workflow reports unknown env keys if you typo a name or delete a variable in Settings.

For the full tag model (when tags resolve, namespaces, and system tokens), see Expression variables.

Secure storage

Each variable has a small metadata row in your database (key, description, and a reference to the secret). The secret value itself is stored with Supabase Vault, so it is encrypted at rest in the database and in backups.

The Settings UI and browser never receive decrypted values after the initial save. When a workflow runs, only server-side code with the appropriate privileges loads the decrypted map for your account and attaches it to the run envelope as user_environment. That map is exposed to templates as env during resolution.

Encryption at rest reduces risk if someone obtains a database dump. It does not by itself prevent secrets from appearing in workflow outputs, run history, or third-party systems once a step uses them (see below).

Security limitations and exposure

Treat environment variables like passwords in code: convenient, but easy to leak if the graph sends them somewhere unintended. Vault protects storage; you control where resolved values go during a run.

At run time

When a step resolves {{env.api_key}}, the plaintext exists in server memory for that execution. Anyone with access to run logs, debugging views, or infrastructure that captures function output may see substituted values if the workflow writes them there.

Workflow outputs and run history

If you map {{env.api_key}} into a step's Output or Globals row, the secret can become part of the object downstream steps read as {{input.*}}. Run detail views and persisted node I/O may then show the value to anyone who can open that run in your workspace.

External and AI steps

• Webhooks and HTTP: URL, query string, headers, and body templates send whatever you interpolate. Prefer secrets in headers, not in URLs. Do not call untrusted endpoints with env values.
• Email and integrations: Same rule: any field that leaves Dailify can carry the secret.
• AI steps: Prompts containing {{env.*}} may send those strings to your model provider according to your configuration and data policy.
• Code steps: Tags are resolved into the script before the sandbox runs. Logging, return values, or thrown errors can expose secrets; never log env values.

Best practices

• Use environment variables only where the workflow truly needs a secret; use workflow constants for non-sensitive shared config.
• Reference the minimum surface: one webhook header is often better than copying a key into five output fields.
• Rotate keys in Settings if you suspect exposure; update dependent workflows if keys change.
• Do not paste secret values into node labels, constants, or chat: keep secrets in Environment variables only.
• Review who can view workflow runs and Settings in your organisation before storing production credentials.

Related

• Expression variables
• Execution settings
• Webhook call
• Steps and behaviour hub
• Workflows overview