n8n Credential Management: Share API Keys Securely Across Teams

Your n8n workflows are only as secure as the credentials that power them. One leaked API key can compromise your entire automation infrastructure, and potentially your business.

The Problem Every n8n Team Faces

You’re working on a project with another developer. They need to test workflows that use your OpenAI, Stripe, and Supabase credentials. You’re self-hosting n8n on a VPS.

The challenge? You don’t want to hand over VPS root access. You don’t want to share production API keys. But the workflows won’t run without those credentials.

This isn’t hypothetical. It’s the exact situation teams face every day when scaling n8n.

The Solution Most Users Don’t Know Exists

n8n provides multiple solutions for secure credential management:

Built-in encryption for credential storage
Team sharing without exposing actual values
Environment variables for configuration management
External secrets with AWS, HashiCorp Vault, and Infisical

The problem? Most users don’t know these options exist.

What You’ll Learn

This guide covers everything you need for secure credential management:

How n8n’s built-in credential system works (and how to configure it properly)
Sharing credentials with team members without security risks
Using environment variables for dev/staging/production separation
Integrating external secrets managers for enterprise requirements
Practical patterns for teams collaborating on workflows

Why Credential Security in n8n Matters

Before diving into solutions, let’s be clear about the risks. n8n workflows often connect to critical business systems: payment processors, CRMs, databases, email providers, and AI services.

The credentials for these services are high-value targets.

The Real Risks

Risk	Impact	Common Cause
Credential exposure in shared workflow JSON	API keys visible to anyone with workflow access	Hardcoding secrets in Code nodes
Unauthorized access to connected services	Data breaches, financial fraud, service abuse	Weak access controls, shared passwords
Revoked credentials breaking production	Workflow failures, business disruption	No rotation strategy, single point of failure
Compliance violations	Regulatory fines, audit failures	Improper credential storage, missing audit trails
Lateral movement in security incidents	Attackers pivot from one service to others	Overprivileged credentials, no segmentation

Common Credential Mistakes

The most frequent credential security mistakes we see in n8n workflows:

Hardcoding in Code nodes: Developers paste API keys directly into JavaScript code for “quick testing” and forget to remove them. These credentials end up in workflow exports, Git repositories, and forum posts.

// DON'T DO THIS
const apiKey = "sk_live_abc123xyz789"; // Exposed in workflow JSON

Sharing workflow JSON with embedded credentials: When troubleshooting, users share workflow exports without realizing they contain credential references or hardcoded values.

Using personal credentials for team workflows: One person’s API key powers a workflow that the whole team depends on. When that person leaves or changes roles, workflows break.

No encryption key configured: Self-hosted n8n instances without a proper N8N_ENCRYPTION_KEY store credentials with weaker protection.

Before you deploy any workflow to production, scan it for exposed secrets using our credential scanner tool. One quick check can prevent a serious security incident.

n8n’s Built-in Credential System

n8n includes a credential management system designed to keep your secrets secure. Understanding how it works helps you use it effectively.

How n8n Stores Credentials

When you create a credential in n8n, the sensitive values (API keys, passwords, OAuth tokens) are encrypted and stored in the database. They’re not stored in the workflow JSON itself. Workflows reference credentials by ID, not by their actual values.

This means when you export a workflow, the credential values aren’t included. The export contains a reference like "credentials": {"openAiApi": {"id": "1", "name": "OpenAI API Key"}} but not the actual key.

Setting Up the Encryption Key

For self-hosted n8n instances, configuring a proper encryption key is critical. Without it, n8n generates a random key on startup. This means credentials become inaccessible if you restart with a different key.

# In your environment configuration
N8N_ENCRYPTION_KEY=your-32-character-encryption-key-here

This key should be:

At least 32 characters long
Randomly generated (use a password manager or openssl rand -hex 16)
Stored securely outside of n8n (in your infrastructure secrets management)
The same across all n8n instances in a clustered deployment

For Docker deployments:

# docker-compose.yml
services:
  n8n:
    image: n8nio/n8n
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}

Store the actual key value in a .env file that’s excluded from version control, or use Docker secrets for production deployments.

Credential Types

n8n supports different credential types for different authentication patterns:

Credential Type	Use Case	Example Services
API Key	Simple key-based authentication	OpenAI, SendGrid, many REST APIs
OAuth2	User-delegated access with token refresh	Google, Microsoft, Salesforce
Basic Auth	Username/password authentication	Legacy systems, internal APIs
Header Auth	Custom header-based authentication	APIs with X-API-Key or custom headers
Query Auth	Key passed as URL parameter	Some older APIs

Always use the appropriate credential type for each service. OAuth2 credentials, for example, handle token refresh automatically. You’d have to implement this manually if using a static API key.

For authentication troubleshooting, see our guide to fixing n8n authentication errors.

Why Never to Hardcode in Code Nodes

The Code node is powerful, but it’s also where most credential leaks happen. Here’s why hardcoding is dangerous:

Workflow exports include code: When you download a workflow, all Code node contents are included
No encryption: Hardcoded values aren’t encrypted like credential fields
No access control: Anyone with workflow access sees the code
No rotation: Changing a hardcoded value means editing the workflow

Instead, access credentials properly:

// In a Code node, reference credentials from previous nodes
const apiKey = $('HTTP Request').params.authentication.credentials;

// Or use environment variables (covered later)
const apiKey = process.env.MY_API_KEY;

This is one of the common self-hosting mistakes that can compromise your entire n8n installation.

When multiple people work with n8n workflows, credential sharing becomes essential. But it needs to happen securely.

n8n’s credential sharing (available in Cloud and Enterprise editions) allows users to use credentials without seeing the actual values. This is the key security feature: team members can execute workflows that require credentials, but they can’t view or copy the API keys themselves.

The owner creates a credential, shares it with specific users or projects, and those users can select the credential in their workflows. The actual secret never leaves the secure storage.

Permission Levels

Role	Can Create	Can Use	Can View Values	Can Share	Can Delete
Credential Owner	Yes	Yes	Yes	Yes	Yes
Project Admin	In project	In project	No	Within project	In project
Project Member	No	Shared only	No	No	No
Instance Admin	Yes	Yes	Yes	Yes	Yes

Understanding these permissions helps you structure your team’s access appropriately:

Owners should be limited to people who actually need to create and manage credentials
Project Members can use credentials to build and test workflows without security risk
Instance Admins have full access and should be limited to your security/DevOps team

Projects in n8n provide a natural boundary for credential sharing. When you create a credential within a project, all project members can use it in their workflows.

To share a credential with a project:

Navigate to Credentials in your project
Create a new credential or select an existing one
The credential is automatically available to all project members

For credentials that span multiple projects, you can share from your personal credentials with specific projects or users.

The Self-Hosted Challenge

Here’s where things get tricky. Many teams self-host n8n on a VPS for cost savings and control, but the Community Edition has limited built-in user management. This creates the exact scenario from the Reddit community:

“I can create a second ‘Member’ inside n8n, but members don’t get access to credentials. Many workflows depend on API keys. I don’t want to share real production API keys with another developer.”

Solutions for self-hosted teams:

Upgrade to Enterprise: Gets you full RBAC and credential sharing
Separate instances: Give each developer their own n8n instance with their own credentials
Development credentials: Create separate API keys for development (covered in detail later)
Environment-based separation: Use different credentials per environment

For a properly configured self-hosted setup with security considerations, our self-hosted setup service can help you implement these patterns correctly.

Environment Variables Strategy

Environment variables provide a flexible way to manage configuration across environments without hardcoding values in workflows.

When to Use Environment Variables

Environment variables work well for:

Configuration that changes between environments (dev/staging/prod)
Values that multiple workflows share
Integration with infrastructure secrets management (Docker secrets, Kubernetes secrets)
Settings that shouldn’t be in workflow JSON at all

They’re less ideal for:

Per-user credentials (use n8n’s credential system instead)
Values that need the n8n credential UI for management
OAuth tokens that require refresh (use OAuth credentials)

The _FILE Suffix Pattern

For Docker and Kubernetes deployments, n8n supports loading sensitive values from files using the _FILE suffix. This integrates with Docker secrets and Kubernetes secrets.

# docker-compose.yml with Docker secrets
services:
  n8n:
    image: n8nio/n8n
    environment:
      - N8N_ENCRYPTION_KEY_FILE=/run/secrets/n8n_encryption_key
      - DB_POSTGRESDB_PASSWORD_FILE=/run/secrets/db_password
    secrets:
      - n8n_encryption_key
      - db_password

secrets:
  n8n_encryption_key:
    file: ./secrets/encryption_key.txt
  db_password:
    file: ./secrets/db_password.txt

For Kubernetes:

# kubernetes-deployment.yaml
apiVersion: v1
kind: Secret
metadata:
  name: n8n-secrets
type: Opaque
data:
  encryption-key: <base64-encoded-key>
  db-password: <base64-encoded-password>
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n
spec:
  template:
    spec:
      containers:
        - name: n8n
          image: n8nio/n8n
          env:
            - name: N8N_ENCRYPTION_KEY_FILE
              value: /secrets/encryption-key
            - name: DB_POSTGRESDB_PASSWORD_FILE
              value: /secrets/db-password
          volumeMounts:
            - name: secrets
              mountPath: /secrets
              readOnly: true
      volumes:
        - name: secrets
          secret:
            secretName: n8n-secrets

This pattern keeps secrets out of your docker-compose files and environment variable exports, which could be logged or exposed.

Accessing Variables in Workflows

Within n8n workflows, you can access environment variables in expressions:

// In an expression field
{{ $env.MY_VARIABLE }}

// In a Code node
const apiEndpoint = process.env.API_ENDPOINT;
const environment = process.env.NODE_ENV;

This is useful for endpoints that change between environments:

// Dynamic API endpoint based on environment
const baseUrl = process.env.API_BASE_URL || 'https://api.example.com';

Environment Separation

A common pattern for teams is running separate n8n instances per environment, each with its own credentials:

Environment	n8n Instance	Credentials	Purpose
Development	dev.n8n.company.com	Dev API keys (limited access)	Building and testing
Staging	staging.n8n.company.com	Staging keys (test accounts)	Integration testing
Production	n8n.company.com	Production keys	Live workflows

This provides complete isolation. A developer with access to the dev instance can’t accidentally affect production.

For comprehensive environment setup, see our n8n self-hosting guide.

External Secrets Management

For enterprises with existing secrets infrastructure, n8n’s external secrets feature provides integration with industry-standard secret managers. This is an Enterprise feature that solves real problems for teams managing credentials across multiple systems.

What External Secrets Solve

External secrets address several enterprise requirements:

Centralized management: All secrets in one place, used by multiple applications
Audit trails: Track who accessed which secrets and when
Rotation: Update secrets in one place, all connected systems get the new value
Compliance: Meet security requirements for secret storage and access control
Separation of duties: Security team manages secrets, developers use them

AWS Secrets Manager

AWS Secrets Manager is a popular choice for teams already on AWS. Here’s how to configure it with n8n.

Step 1: Create an IAM Policy

Create a policy that gives n8n access only to the secrets it needs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListingSecrets",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:ListSecrets",
        "secretsmanager:BatchGetSecretValue"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RetrievingSecrets",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": [
        "arn:aws:secretsmanager:us-west-2:123456789000:secret:n8n/*"
      ]
    }
  ]
}

This policy restricts n8n to secrets with names starting with n8n/. This is a good practice for limiting blast radius.

Step 2: Configure n8n

Set the environment variables for AWS authentication:

N8N_EXTERNAL_SECRETS_PROVIDERS=awsSecretsManager
AWS_REGION=us-west-2
AWS_ACCESS_KEY_ID=your-access-key
AWS_SECRET_ACCESS_KEY=your-secret-key

Or use IAM roles if running on EC2/ECS (preferred for security).

HashiCorp Vault

HashiCorp Vault is the industry standard for secrets management. It offers advanced features like dynamic secrets, secret leasing, and detailed audit logging.

Configure n8n to use Vault:

N8N_EXTERNAL_SECRETS_PROVIDERS=vault
VAULT_ADDR=https://vault.company.com:8200
VAULT_TOKEN=your-vault-token

For production, use Vault’s AppRole or Kubernetes authentication instead of static tokens.

Infisical

Infisical is an open-source alternative that’s easier to self-host than Vault. It’s a good choice for teams wanting external secrets without the complexity of enterprise solutions.

N8N_EXTERNAL_SECRETS_PROVIDERS=infisical
INFISICAL_TOKEN=your-infisical-token
INFISICAL_SITE_URL=https://app.infisical.com

Using Secrets in Credentials

Once configured, you reference external secrets in credential fields using expression syntax:

{{ $secrets.vault.stripe-api-key }}
{{ $secrets.awsSecretsManager.openai-key }}
{{ $secrets.infisical.database-password }}

The pattern is: $secrets.<provider-name>.<secret-name>

This means your credentials dynamically pull values from your external secrets manager. When you rotate a secret in Vault or AWS, n8n automatically uses the new value without any workflow changes.

Provider Comparison

Feature	AWS Secrets Manager	HashiCorp Vault	Infisical
Pricing	Pay per secret, per API call	Free (self-hosted), Enterprise paid	Free tier, paid for teams
Self-hosted option	No (AWS managed)	Yes	Yes
Dynamic secrets	No	Yes	No
Audit logging	CloudTrail	Built-in	Built-in
Kubernetes integration	IAM roles for service accounts	Native	Good
Learning curve	Low	High	Low
Best for	AWS-native teams	Enterprise, compliance	Startups, simpler needs

For detailed setup of any provider, refer to the official n8n external secrets documentation.

Team Credential Patterns

Beyond the technical features, successful credential management requires good patterns for how teams work together.

Pattern 1: Dev/Staging/Production Separation

The most important pattern is complete separation between environments. Each environment has its own:

n8n instance (or at minimum, separate projects)
Set of credentials
API keys with appropriate access levels

Development credentials should:

Connect to sandbox/test accounts (Stripe test mode, HubSpot sandbox)
Have rate limits that prevent runaway API usage
Be easily rotatable without production impact

Production credentials should:

Be managed by a limited set of administrators
Have proper access scoping (least privilege)
Be rotated on a regular schedule

Pattern 2: Personal Developer Credentials

For development work, give each developer their own set of credentials:

Developer creates their own API keys in services (OpenAI, etc.)
Developer creates credentials in their n8n development environment
Workflows are developed and tested with personal credentials
Before promotion to production, workflows are reconfigured to use shared production credentials

This pattern prevents credential conflicts and makes it clear who’s responsible for which API usage.

Pattern 3: Shared Service Accounts with Rotation

For production workflows, use dedicated service accounts rather than personal accounts:

Create a service account in each connected service (e.g., [email protected])
Generate API credentials for the service account
Store credentials in n8n with clear naming (Production - Stripe API)
Schedule regular rotation (quarterly for most services)

When rotating credentials:

Create new credentials in the service
Update n8n credential with new values
Verify workflows still function
Revoke old credentials

GitOps for Workflow Versioning

A challenge with credential management is version control. You want workflows in Git, but not credentials.

The solution: store workflow JSON in Git without credential values. n8n’s export format already supports this. Credentials are referenced by ID, not value.

{
  "name": "Lead Enrichment Workflow",
  "nodes": [
    {
      "type": "n8n-nodes-base.httpRequest",
      "credentials": {
        "httpHeaderAuth": {
          "id": "1",
          "name": "Clearbit API"
        }
      }
    }
  ]
}

When importing to a new environment:

Import the workflow JSON
n8n prompts you to map credential references to local credentials
Select the appropriate credentials for that environment

This keeps your workflow logic in version control while credentials stay in secure storage.

For more workflow architecture patterns, see our n8n workflow best practices guide.

Security Best Practices Checklist

Here’s a comprehensive checklist for securing n8n credentials:

Initial Setup

Task	Priority	Notes
Configure N8N_ENCRYPTION_KEY	Critical	Use 32+ character random key
Enable HTTPS	Critical	Use Let’s Encrypt or proper certificates
Set up authentication	Critical	Basic auth minimum, SSO preferred
Use PostgreSQL, not SQLite	High	SQLite isn’t suitable for production
Configure automated backups	High	Include credential backup strategy

Ongoing Management

Task	Frequency	Notes
Rotate API credentials	Quarterly	More often for high-risk services
Audit credential access	Monthly	Review who has access to what
Review workflow permissions	Monthly	Remove unused access
Update n8n version	As released	Security patches often included
Test backup restoration	Quarterly	Ensure credentials can be recovered

Incident Response

If you suspect credential exposure:

Immediately rotate affected credentials in the source service
Review access logs in both n8n and the affected service
Check for unauthorized workflow executions that might indicate abuse
Update n8n credential with new values
Document the incident for future prevention

Network Security

Put n8n behind a VPN if webhooks aren’t needed from the public internet
Use IP whitelisting where supported
Consider a reverse proxy (nginx, Caddy) for additional security layers
Segment n8n from other internal systems

For complex security requirements, our n8n consulting services can help design and implement appropriate security measures.

Frequently Asked Questions

n8n’s export format doesn’t include actual credential values. It only includes references to credential IDs. When you share a workflow JSON file, recipients see that the workflow uses a credential named “OpenAI API Key” but not the actual key value. They’ll need to create their own credentials and map them when importing. For team collaboration where you want shared credentials, use n8n’s credential sharing feature (Cloud/Enterprise) which lets users use credentials without viewing them.

Can team members use credentials without seeing the actual values?

Yes, this is exactly how n8n’s credential sharing works. When you share a credential with a user or project, they can select that credential in their workflows and execute them, but they cannot view or copy the actual API key or password. The secret values never leave n8n’s encrypted storage. Only the credential owner and instance admins can view the actual values.

What’s the best way to manage dev vs production credentials?

The gold standard is complete environment separation: separate n8n instances for dev, staging, and production, each with their own credentials. For smaller teams, at minimum use separate credentials within the same instance with clear naming (Dev - Stripe Test Mode vs Production - Stripe Live). Configure development credentials to use sandbox accounts and test modes where available. Never use production credentials in development workflows.

Is n8n’s built-in credential storage secure enough for enterprise?

For most use cases, yes. n8n encrypts credentials at rest using AES-256 when you configure an encryption key. For enterprises with existing secrets infrastructure or specific compliance requirements (SOC 2, HIPAA, etc.), the external secrets feature integrates with AWS Secrets Manager, HashiCorp Vault, and Infisical. This provides centralized secrets management, audit trails, and dynamic rotation that enterprise security teams typically require.

How do I rotate credentials without breaking active workflows?

The process depends on your setup. For n8n’s built-in credentials: (1) Generate new credentials in the external service, (2) Update the credential in n8n with new values, (3) Test a workflow that uses the credential, (4) Revoke old credentials in the external service. For external secrets: update the value in your secrets manager (Vault, AWS), and n8n will automatically use the new value. No workflow changes needed. Schedule rotations during low-traffic periods and have rollback procedures ready.

Next Steps

Secure credential management isn’t just about security. It’s about building automation that scales with your team. When credentials are properly managed, developers can collaborate without risk, environments are properly isolated, and you can respond quickly to security incidents.

Start with the basics: configure your encryption key, use n8n’s built-in credential system, and never hardcode secrets in Code nodes. As your team grows, implement environment separation and consider external secrets for enterprise-grade management.

If you’re setting up n8n for a team and want to get credential management right from the start, our self-hosted setup service includes security hardening and credential management configuration. For existing deployments that need a security review, our consulting services can audit your setup and recommend improvements.

Before deploying any workflow, run it through our credential scanner to catch exposed secrets, and use the workflow auditor for a complete security and best practices review.