Pipedream secrets and connected accounts → n8n credentials

Pipedream secrets, environment variables and connected accounts don't move to n8n automatically. Pipedream's export replaces secret values with <redacted>, keeps only an authProvisionId for app props, and leaves out connected accounts, OAuth tokens and environment variables entirely. In n8n you recreate them as credentials, and in a few cases as Variables. This page is the checklist.

Where each Pipedream secret goes

In Pipedream	In n8n
Connected account (this.slack.$auth…, app props on actions)	A credential of that app's type, selected on the app node or HTTP Request node
Environment variable used as an API key	A credential (often Header Auth or the service's own type)
Environment variable used as config (URLs, IDs, flags)	n8n Variables $vars on supported plans, or a Set node / hard-coded value
Secret prop on an action	The credential or field on the matching n8n node
HTTP trigger Custom token	Webhook node Header Auth credential

Step 1. Make the list

manifest.json in the export has a warnings list for each workflow that names every step and prop you must re-enter. Add every app you see in app props and this.<app>.$auth references. Our free report builds this list for you: one line per credential to create, with the workflows that need it.

Step 2. Collect the values

Pipedream environment variables default to secret, and a secret value is never shown again in the UI. So for most keys you have two options:

• Get the value from the source (the provider's dashboard, your password manager).
• Rotate the key: create a new one at the provider and use it only in n8n. This is the cleaner option, because it also cuts off the old copy that Pipedream deletes by April 30, 2027.

OAuth connections (Google, Slack, HubSpot) can't be copied at all; you sign in again from n8n.

Step 3. Create credentials in n8n

Create a credential from the Overview or a project, or straight from a node's credential dropdown. n8n tests a credential when you save it (docs). Credentials are encrypted with the instance's N8N_ENCRYPTION_KEY; on self-hosted n8n, back up that key, because it is what encrypts them (deployment variables).

Then open each imported node that shows a credential warning and select the new credential.

Code steps that read secrets

Pipedream code read secrets with process.env.KEY or this.<app>.$auth.<field>. In n8n:

• Code nodes can't read credentials (Code node common issues). Move the API call into an HTTP Request node with the credential (guide) and keep the Code node for logic.
• $vars.KEY works in code and expressions, on Cloud Pro and Enterprise and self-hosted Business and Enterprise. Variables are read-only in workflows, and only owners and admins create them (docs). They're visible to anyone who can edit workflows, so don't treat them as a vault.
• $env reads instance environment variables, but per the 2.0 breaking changes the default of N8N_BLOCK_ENV_ACCESS_IN_NODE is now true, so on a default install nodes can't read them (the environment variable reference page still lists false; test on your version).

Our converter turns this.<app>.$auth.<field> into a named variable and lists it. OAuth tokens stored that way don't refresh, so for OAuth apps move the call to an HTTP Request node with the app's n8n credential.

External secret stores

n8n Enterprise can read secrets from 1Password, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault or Infisical, via $secrets in credential fields (docs). Not needed for most migrations.

Next steps

• Full process: migrate Pipedream to n8n
• What else the export leaves out: Pipedream data deletion checklist
• Credential list for your workflows: free report

Not affiliated with Pipedream or n8n.