Secrets

Secrets provide an encrypted key-value store for each project. Use secrets to store API keys, access tokens, and other sensitive credentials that your graph nodes need at runtime. Secret values are encrypted at rest and injected only during execution, keeping credentials out of your graph definitions and logs.

Overview

• Encrypted at rest: Secret values are encrypted when stored and decrypted only at execution time. Raw values are never exposed in the Portal UI, execution logs, or API responses.
• Project-scoped: Each secret belongs to a single project, ensuring that teams and environments maintain separate credential stores.
• Referenced by name: Nodes access secrets through {{secrets.keyName}} placeholders. When a node executes, the runtime resolves the placeholder and injects the decrypted value.
• Sensitive flag: Secrets can be marked as sensitive to prevent their values from being revealed in the Portal, even to project administrators.

Managing secrets

Create, update, and delete secrets in the Portal under Storage > Secrets, or through the API.

Create a secret

Add a secret by providing a name and value. Choose a descriptive name that identifies the credential (e.g. openai_api_key, stripe_secret_key). The value is encrypted immediately upon creation.

Update a secret

Change a secret's value at any time. All nodes that reference the secret by name will use the updated value on their next execution. No graph edits are required.

Delete a secret

Remove a secret when it is no longer needed. Before deleting, verify that no active graphs reference the secret to avoid execution failures.

Mark as sensitive

Flag a secret as sensitive to prevent its value from being revealed through the Portal interface. Use this for credentials that should remain hidden from all users, regardless of their project role.

Using secrets in nodes

Reference secrets in node configuration fields that support placeholders. The runtime resolves {{secrets.keyName}} to the decrypted value when the node executes.

Common examples:

• HTTP nodes: Set an authorization header such as Authorization: Bearer {{secrets.apiKey}} to authenticate API requests. See HTTP nodes.
• AI nodes: Provide model API keys through secret references in the node configuration. See AI nodes.
• Code nodes: Access secrets in custom logic where the node configuration supports placeholder resolution.

Secrets are resolved at execution time only. They are never interpolated into graph definitions, exported configurations, or log output.

Best practices

• One secret per credential. Store each API key or token as a separate secret (e.g. one for your LLM provider, one for your CRM, one for your email service). This simplifies rotation and access auditing.
• Rotate keys regularly. When you rotate a credential with an external provider, update the corresponding secret in Swirls. All graphs that reference it will use the new value automatically.
• Use descriptive names. Name secrets clearly (e.g. sendgrid_api_key rather than key1) so team members can identify their purpose without revealing the value.
• Restrict access. Limit who can create, edit, and view secrets in your project to maintain credential governance.
• Mark production credentials as sensitive. Use the sensitive flag for high-value credentials to add an extra layer of protection in the Portal.

Related

• HTTP node -- Reference secrets in request headers and configuration.
• AI node -- Provide model API keys through secrets.
• Portal -- Manage secrets through the Storage section.