Managing Credentials Securely: Encryption, Sharing, External Secrets

Credentials are the actual heart of every n8n automation: without API keys, OAuth2 tokens, or database passwords, no digital worker can communicate with external systems. That's exactly why it's worth taking a close look at how n8n actually protects these credentials, who in the team can use them without seeing them, and how sensitive values can be kept entirely outside n8n by having an external secrets store manage them. As of July 2026.

This article clearly separates three layers: the encryption model in the background, sharing permissions for teams, and the integration of external secret stores for enterprise setups. In the end, you retain control over which layer is right for your setup.

How n8n Encrypts Credentials

n8n stores all credentials encrypted in the database by default, never in plain text. According to the guide for custom encryption keys, n8n automatically generates a random key at first startup and stores it in the `~/.n8n` folder. n8n uses this key to encrypt every credential before it is written to the database. Those who want to retain control over this key themselves, for example to manage it centrally or create a backup independent of the filesystem, set the environment variable before startup:

```

export N8N_ENCRYPTION_KEY=<a random, long string>

```

Important in team and production operation: if n8n runs in queue mode with multiple workers, all instances must use exactly the same value for `N8N_ENCRYPTION_KEY`. Otherwise, workers cannot decrypt the credentials encrypted by the main process, and workflows will fail at exactly the point where a credential is needed.

Two-Layer Model with Key Rotation

For self-hosted instances, n8n additionally offers encryption key rotation. According to the documentation on rotating encryption keys, n8n works with two layers:

• Instance Encryption Key (`N8N_ENCRYPTION_KEY`): the permanent master key that does not change.
• Data Encryption Key: the actual key that encrypts credentials and other sensitive data and can be rotated without touching the master key.

Already encrypted data remains readable after rotation; n8n automatically re-encrypts it with the new Data Encryption Key on future write operations. The feature is activated via the environment variable `N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true` on all instances; after that, rotation can be triggered under Settings > Data Encryption Keys in the interface or via API (`POST /encryption/keys`). One point you should absolutely understand beforehand: once the feature is active and new data has been written in the new format, rotation can no longer be undone and there is no automated tool to convert data back. A complete database backup before activation is therefore not optional but mandatory.

Sharing Credentials in Teams Without Revealing Them

As soon as multiple people work on the same workflows, the question arises of who can see and use which credentials. n8n deliberately separates the use of a credential from the insight into its values. According to the documentation on sharing workflows: whoever shares a workflow automatically also shares access to all credentials used in it, even if they were not explicitly shared individually. This ensures that shared workflows remain fully functional for all involved.

n8n distinguishes between two permission levels for roles:

• Creator (the original person who created the workflow): can view, execute, edit, export, share, and delete the workflow.
• Editor (people with shared access): can view, execute, edit, and export, but cannot share or delete.

The principle of least privilege continues consistently: if a credential used in a workflow is not additionally shared individually, an editor can execute the workflow and edit other nodes, but cannot modify the specific node with the unshared credential. The values of a shared credential, such as API keys or passwords, remain fundamentally invisible to editors. They can use the credential but cannot read it. An important practical note: workflow ownership cannot simply be transferred, except in the course of deleting a user account. So if you work as a team from the start, you should create workflows directly in a shared project rather than in your personal workspace, because adding individual users via the "Add users" function, according to the documentation, only works for workflows in the personal area. For workflows within a project, permissions are granted via project membership itself.

External Secrets: Managing Credentials Outside of n8n

For enterprise setups, n8n goes one step further and allows sensitive values to not be stored in n8n at all, but instead left in an external secrets store. According to the documentation on external secret stores, n8n supports six providers for this:

• 1Password (via Connect Server)
• AWS Secrets Manager
• Azure Key Vault
• GCP Secrets Manager
• HashiCorp Vault
• Infisical

• 1Password (via le serveur Connect)
• AWS Secrets Manager
• Azure Key Vault
• GCP Secrets Manager
• HashiCorp Vault
• Infisical