n8n Backup: Workflows, Credentials, and the Encryption Key

An n8n backup is only complete when it secures workflows, credentials, and the matching encryption key together. If the key is missing or differs from the original, n8n can no longer decrypt stored credentials, and every saved connection to an email inbox, CRM, or API must be set up again by hand. Workflows themselves can be exported and imported as JSON via the web interface or the CLI; credentials additionally require the original encryption key or a deliberately decrypted export. For companies that self-host n8n and are responsible for their automations, the encryption key is therefore the single most important building block of a working backup strategy. As of: July 2026.

What does the encryption key actually do in n8n?

The encryption key encrypts all credentials stored in n8n before they are saved in the database; without the matching key, this data remains permanently unreadable. On first launch, n8n automatically generates a random key and stores it in the ~/.n8n folder. Anyone who wants to use their own key instead must set the N8N_ENCRYPTION_KEY environment variable before the settings file is created; a later change is not applied automatically. If n8n runs in queue mode with multiple workers, the same encryption key must be set for each individual worker according to the documentation (n8n documentation on the encryption key).

What happens if the encryption key is lost?

If the encryption key is lost or differs from the one originally used to encrypt the credentials, n8n reports that the credentials could not be decrypted because a different encryption key was presumably used. The workflow logic itself remains intact as a JSON structure, but every stored credential such as API keys, OAuth tokens, or SMTP access becomes unusable and must be reconnected manually. With just a few workflows this is annoying; with grown automations that have many connections to accounting, CRM, or inventory management systems, it effectively means starting the entire credential management from scratch. The encryption key therefore belongs in every backup routine, separate from, but just as reliable as, the database backup itself.

How do you back up workflows and credentials correctly?

For backups, n8n offers ways both through the interface and through the server CLI; for regular backups, the CLI is the more reliable route. In the web interface, a workflow can be downloaded as a JSON file via the three-dot menu, or imported from a file or a URL.

• Export workflows: n8n export:workflow with the --backup and --output options saves all workflows individually, formatted for readability, in a target folder.
• Export credentials: n8n export:credentials --all saves the encrypted credentials; with the additional --decrypted option, they can also be exported in plain text, for example to transfer them specifically to an instance with a different encryption key.
• Import: n8n import:workflow and n8n import:credentials load the JSON files back in; IDs contained in them overwrite existing workflows or credentials with the same ID.

Details on all commands can be found in the n8n documentation on export and import as well as on the command line (Export and import in n8n, n8n CLI commands).

What should you watch out for when changing the encryption key or sharing exports?

Changing the encryption key is not a routine operation but an intervention that can lead to permanent data loss without a prepared backup. n8n distinguishes between the instance encryption key, which as the master key never changes, and an underlying data encryption key, which actually encrypts the credentials and can be renewed via its own rotation function. According to the documentation, this rotation is explicitly not reversible; if the associated function is disabled again, all data encrypted since then becomes permanently inaccessible, a complete database backup beforehand being the only safeguard (n8n documentation on key rotation). Caution is also advised when sharing exported workflow JSONs, as the files contain credential names and IDs, and HTTP request nodes imported from cURL can even contain authentication headers in plain text. This information should be removed before any handover.

Anyone who operates their own n8n instance and needs support setting up backup routines or migrating between servers will find guidance in the n8n offering from NordFlux.

Frequently asked questions about n8n backup and the encryption key

Is a database backup alone enough to fully back up n8n?

No, a plain database backup does secure workflows and encrypted credentials, but without the associated encryption key, these credentials remain unreadable upon restore. By default, the key is located in a separate settings file in the ~/.n8n folder and must therefore be deliberately backed up as well, ideally separately from the database backup in an access-protected location.

Can I export workflows without the associated credentials?

Yes, exporting a workflow via the interface or with n8n export:workflow contains only the workflow structure with references to credential names and IDs, not the credentials themselves. To take the credentials along as well, a separate export with n8n export:credentials is required, and the destination must either have the same encryption key, or the credentials must first be exported in plain text using the --decrypted option.

How do I migrate credentials to an n8n instance with a different encryption key?

The most reliable way is the decrypted export with n8n export:credentials --all --decrypted on the source instance, followed by the regular import on the destination instance, which automatically re-encrypts the data with its own encryption key. Since the file is briefly in plain text during this process, it should be securely deleted immediately after the import.

What do I do if the encryption key has actually been lost?

Without the original key or a backup of the settings file, already encrypted credentials can no longer be recovered; every affected connection must be manually re-authenticated in the respective workflows. The workflow logic itself is not lost in the process; the effort is limited to re-entering the credentials, which can nonetheless mean several hours of work for extensive automations.