How n8n encrypts credentials, who can share them in teams, and how External Secrets manage access data outside of n8n.
Credentials are the true backbone of every n8n automation: without an API key, OAuth2 token, or database password, no digital worker can talk to external systems. That is exactly why it pays to take a close look at how n8n actually protects these credentials, who on the team is allowed to use them without seeing them, and how sensitive values can be kept out of n8n entirely by letting an external secrets store manage them. As of: July 2026.
This article cleanly separates three levels: the encryption model running in the background, the sharing rights for teams, and the integration of external secret stores for enterprise setups. By the end, you will be in control of which level is the right one for your setup.
n8n always stores all credentials encrypted in the database, never in plain text. According to the guide to setting your own encryption key , n8n automatically generates a random key on first startup and stores it in the ~/.n8n folder. n8n uses this key to encrypt every credential before it is written to the database. If you want to keep control of this key yourself, for example to manage it centrally or create a backup independent of the file system, set the following environment variable before startup:
1export N8N_ENCRYPTION_KEY=<a random, long string>Important for team and production use: 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 fail at exactly the point where a credential is needed.
For self-hosted instances, n8n also offers encryption rotation. According to the documentation on rotating encryption keys, n8n works with two layers here:
N8N_ENCRYPTION_KEY): the permanent master key that never changes.Data already encrypted remains readable after a rotation; n8n automatically re-encrypts it with the new Data Encryption Key on future write operations. The feature is enabled via the environment variable N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true on all instances, after which rotation can be triggered under Settings > Data Encryption Keys in the interface or via the API (POST /encryption/keys). One point you should absolutely internalize beforehand: once the feature is active and new data has been written in the new format, the rotation can no longer be reversed, and there is no automated tool to convert data back. A complete database backup before activation is therefore not optional, but mandatory.
As soon as several people work on the same workflows, the question arises of who is allowed to see and use which credentials. n8n deliberately separates the use of a credential from insight into its values. According to the documentation on sharing workflows, the rule is: whoever shares a workflow automatically also shares access to all credentials used within it, even if these were not explicitly shared individually. This ensures that shared workflows actually remain runnable for everyone involved.
For roles, n8n distinguishes between two levels:
The principle of least privilege continues to apply consistently: if a credential used in the workflow has not also been shared individually, an Editor can indeed execute the workflow and edit other nodes, but cannot change exactly the node with the unshared credential. The values of a shared credential, i.e. API keys or passwords, remain fundamentally invisible to Editors. They can use the credential, but not read it out. An important practical note on the side: ownership of a workflow cannot simply be transferred, except when a user account is deleted. So if you work in a team from the start, you should ideally create workflows directly in a shared project rather than in the personal workspace, because adding individual users via the "Add users" feature only works, according to the documentation, for workflows in the personal space. For workflows within a project, rights are instead assigned via project membership itself.
For enterprise setups, n8n goes one step further and allows sensitive values to not be stored in n8n at all, but to remain in an external secrets store. According to the documentation on external secret stores, n8n supports six providers for this:
This feature is tied to Enterprise Self-hosted and Enterprise Cloud plans. A vault is set up under Settings > External Secrets via "Add secrets vault": there you assign a unique name to the vault, select the provider, and enter the credentials required for it. Within a credential, you then access the external value via an expression, for example:
1{{ $secrets.<vault-name>.<secret-name> }}For 1Password there is an extended syntax with item title and field label: {{ $secrets.<vault-name>.<item-title>.<field-label> }}. There is one technical limitation you should know about: n8n supports only simple text values for secrets, not JSON objects, and the expressions only work inside credential fields, not in other fields with expression support. On the plus side, the environment variable N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL lets you define how often n8n checks for changes in the external store, by default every 300 seconds.
For smaller teams, in practice a cleanly set N8N_ENCRYPTION_KEY combined with well thought-out project and sharing structures is often already enough: who is allowed to see which workflow automatically also determines who can use which credential. But as soon as several environments, for example staging and production, need the same API access, or a compliance requirement demands that secrets be kept centrally in a vault and also rotated centrally there, External Secrets becomes a sensible addition. Both levels are not mutually exclusive and can be combined: database encryption protects what n8n itself stores, while External Secrets additionally reduces what n8n has to store permanently in the first place.
If you want to set up an n8n instance for a team and plan encryption, permissions, and, where applicable, external secret stores cleanly right from the start, you will find support from the n8n automations by NordFlux, so that sensitive credentials sit where they belong right from the beginning.
By default, n8n stores the key randomly generated on first startup in the ~/.n8n folder and uses it to encrypt credentials before saving them to the database. If you want to set the key yourself, set the environment variable N8N_ENCRYPTION_KEY before the first startup.
Yes, that is exactly the standard case. If a credential is shared with a user or via a project, that person can use the credential in their own workflows, but the actual values, such as API keys or passwords, remain hidden.
If a workflow is shared, the invited person can still run it in full, since workflow sharing automatically includes the use of all credentials it contains. However, the affected node can only be edited if the credential was also shared individually; all other nodes in the workflow remain unaffected.
No. According to the documentation, External Secrets is only available on Enterprise Self-hosted and Enterprise Cloud plans. Six providers are currently supported: 1Password, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault, and Infisical.
No. Once key rotation is activated and n8n has written data in the new format, the feature can no longer be deactivated, and there is no automated tool to revert to the old format. A complete database backup before activation is therefore strongly recommended.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
How to harden n8n: enable 2FA, set up SSRF protection, lock down risky nodes with NODES_EXCLUDE, and disable the Public API when it is unused.
If you lose the n8n encryption key, all stored credentials become unusable. Here is how to back up workflows, credentials, and keys correctly.
How to set up Anthropic and OpenAI credentials in n8n, choose the right model for each task, and keep token costs under control.
Encryption alone does not protect you if team sharing is too broad or External Secrets are missing. NordFlux reviews the permission model of your n8n installation and sets up credential management that fits your team size and compliance requirements. In an initial conversation we go through your current setup together.