# How to Back Up and Restore n8n Workflows and Credentials

- Link: https://offshorehosting.pk/back-up-restore-n8n-workflows/
- Published: 2026-10-25T10:39:00+00:00
- Author: admin

# How to Back Up and Restore n8n Workflows and Credentials

n8n is the kind of tool that quietly becomes load-bearing. One week it sends a few
notifications; a few months later it runs your order confirmations, your CRM sync,
and your invoicing reminders. If the server fails, or an upgrade goes wrong, rebuilding
those workflows from memory is slow and error-prone. A backup routine is the difference
between a bad afternoon and a lost week.

The complication is that n8n does not store everything in one place. Workflows, 
credentials, execution history, and the encryption key that protects your credentials
each live in different places, and each backup method covers a different subset.
This guide explains what to back up, how to do it, and how to prove a restore works
before you actually need one.

## What an n8n backup actually has to cover

Before choosing a method, understand the four pieces:

 1. **Workflows.** The logic: nodes, connections, settings, and schedules. Exported
    as JSON, they are portable and easy to version.
 2. **Credentials.** API keys, OAuth tokens, and passwords. These are stored encrypted,
    and the encryption is tied to one key.
 3. **The encryption key (`N8N_ENCRYPTION_KEY`).** Without the original key, encrypted
    credentials cannot be decrypted. There is no reset mechanism and no support ticket
    that can recover them. Losing this key means re-entering every credential by hand,
    including redoing every OAuth consent flow.
 4. **The database and execution history.** Workflows and credentials live in the database(
    SQLite by default, PostgreSQL in production setups). Execution history, users, 
    and settings live there too.

A workflow export alone is not a backup. It is a useful starting point, but it will
not restore your credentials, your history, or your users.

## Method 1: Export workflows from the editor

For a single workflow, the simplest route is the editor itself. Open the workflow,
use the menu in the top-right corner, and choose Download. n8n saves a JSON file
containing the complete workflow: every node, its parameters, the connections between
nodes, and references to the credentials it uses.

What it does **not** contain is the credential secrets themselves. The JSON carries
credential names and IDs, not the API keys. If you import that file into a fresh
instance, the workflow will appear complete but will fail at runtime until you re-
link each credential. That is expected behaviour, not a bug — but it catches many
people out during a migration.

Use editor exports for single workflows, not as your only backup.

## Method 2: Bulk export with the n8n CLI

For a full set of workflows and credentials, the command-line interface is the right
tool. The CLI can export everything at once, which is what you want for scheduled
backups and migrations.

Export all workflows:

    ```bash
    n8n export:workflow --all --output=workflows.json
    ```

Export all credentials (still encrypted with your key):

    ```bash
    n8n export:credentials --all --output=credentials.json
    ```

For a cleaner backup layout, use the `--backup` flag, which exports each workflow
and credential as a separate, readable JSON file in the directory you specify:

    ```bash
    n8n export:workflow --backup --output=backups/workflows/
    n8n export:credentials --backup --output=backups/credentials/
    ```

Keep workflows and credentials in separate directories. Mixing them in one folder
can cause problems during import.

If you run n8n in Docker, run these commands inside the container, for example with`
docker exec`, and copy the output files out to the host. The exact container name
and paths depend on your own Docker Compose setup, so check your configuration before
running the commands.

### The `--decrypted` option — use it with care

The CLI also offers a `--decrypted` flag, which exports credentials in plain text:

    ```bash
    n8n export:credentials --all --decrypted --output=credentials-decrypted.json
    ```

This is useful when you are migrating to an instance with a different encryption
key, because the plain-text values can be imported under the new key. It is also
dangerous: the resulting file contains every API key and password in readable form.
Treat it like a password vault export. Transfer it over an encrypted channel, store
it encrypted, delete it as soon as the migration is done, and never commit it to
a Git repository. In most routine backups, prefer the encrypted export plus a safely
stored copy of the encryption key.

## Method 3: Back up the data folder and database

CLI exports cover workflows and credentials, but they do not include execution history,
users, or settings. For a complete restore, back up the underlying data as well.

 * **SQLite (default):** stop n8n first, then copy the `.n8n` folder (which holds
   the SQLite database and the `config` file containing the encryption key). Copying
   the database while n8n is writing to it can produce an inconsistent backup, so
   the stop-then-copy order matters.
 * **PostgreSQL (production):** take a database dump with `pg_dump` on a schedule,
   and back up the `.n8n` folder or at least the encryption key separately. Make
   sure the database dump and the key backup are taken at roughly the same time,
   so a restore is consistent.

For Docker: stop the container, archive the data volume, restart, and copy the archive
off the server. A backup that lives only on the machine that fails is not a backup.

## The encryption key deserves its own plan

The single most common n8n restore failure is a missing or mismatched encryption
key. n8n generates a key automatically on first launch and stores it in `~/.n8n/
config` (in Docker, `/home/node/.n8n/config`). If that file is lost — for example
because a container was recreated without a persistent volume — n8n generates a 
new key, and every previously encrypted credential becomes unreadable.

The fix is to set the key explicitly as an environment variable, `N8N_ENCRYPTION_KEY`,
before you add credentials, and to store that value in a password manager or secrets
store, separate from the workflow backups. Generate it with a command such as:

    ```bash
    openssl rand -hex 32
    ```

Do not change the key casually on a running instance. If the configured key disagrees
with the one in the settings file, n8n will refuse to start rather than silently
corrupt data. The supported way to move to a new key is to export credentials with`--
decrypted`, change the key, and re-import them.

## How to restore

Restoring is the reverse of exporting, but the order matters:

 1. **Set up the target instance** with the same n8n version as the source where possible,
    and configure `N8N_ENCRYPTION_KEY` to the source value before first launch.
 2. **Restore the database** (if you took one), or start with a fresh database and 
    import from exports.
 3. **Import credentials first**, then workflows, so credential references resolve:
    `
    bash n8n import:credentials --input=credentials.json n8n import:workflow --input
    =workflows.json If you exported separate files, add --separate and point --input
    at the directory.
 4. **Restart n8n** and check that workflows load, credentials decrypt without errors,
    and active workflows are re-activated. Imports do not always restore the active
    state, so verify each scheduled workflow is actually running.
 5. **Test one workflow end to end** with a manual run before relying on schedules.

If you restore to a new server, update `WEBHOOK_URL` and your DNS, since webhooks
will have a new public URL. Our companion article on [n8n webhooks, queues, and execution retention](https://offshorehosting.pk/blog/n8n-webhooks-queues-execution-retention/)
explains how webhook delivery interacts with queue mode and retention.

## A backup schedule that actually gets done

A backup nobody runs is worthless. Pick a cadence that matches how fast your workflows
change:

 * **Weekly CLI exports** of workflows and credentials, stored off-server, are a
   sensible minimum for a business instance.
 * **Daily database backups** if executions and history matter to you, or if you
   run customer-facing automations.
 * **Immediate export** before any upgrade, migration, or major workflow redesign.
 * **A restore test at least once**, on a spare or staging instance, before you 
   declare the routine trustworthy. A backup you have never restored is a hope, 
   not a backup.

Version-control the workflow JSON files if your team is comfortable with Git: separate
files (via `--backup`) make diffs readable, and you can see exactly what changed
in a workflow and when. Keep credentials out of Git entirely.

## Common mistakes to avoid

 * **Backing up workflows but not the key.** The restore will look successful and
   every credential will fail.
 * **Storing decrypted credential exports in the same folder as everything else**,
   or in a shared drive, or in Git.
 * **Copying the SQLite database while n8n is running**, producing a corrupt restore.
 * **Upgrading without a backup**, then discovering a breaking change in a workflow
   you cannot roll back.

## Where this fits on your server

n8n runs best on a server you control, with a persistent volume for its data folder,
a PostgreSQL database for production use, and enough memory for your workload. If
you are setting up or moving an n8n instance, a [VPS hosting](https://offshorehosting.pk/vps-hosting/)
plan gives you the persistent storage, the ability to run Docker and PostgreSQL,
and the control to set environment variables such as `N8N_ENCRYPTION_KEY` properly.[
TO BE CONFIRMED: whether Offshore Hosting VPS plans include managed n8n setup or
backups — confirm before publishing any such claim.]

## Key takeaways

 * Back up four things: workflows, credentials, the encryption key, and the database.
 * Workflow JSON never contains credential secrets; plan to re-link or restore credentials
   separately.
 * Store the encryption key in a password manager, separate from the backups. Losing
   it is unrecoverable.
 * Use `--backup` for readable, versionable exports, and `--decrypted` only for 
   migrations, with strict handling.
 * Test a restore on a non-production instance. If it has never been tested, it 
   is not a backup.

## Sources

 * Massive Grid, “n8n Backup Strategy: How to Protect Your Workflows, Credentials,
   and Execution Data” — https://massivegrid.com/blog/n8n-backup-disaster-recovery/
 * Instapods, “The n8n Encryption Key: Where It Is and What Breaks” — https://instapods.
   com/blog/n8n-encryption-key/
 * OVHcloud Docs, “How to Migrate an n8n Configuration Between Two VPS” — https://
   docs.ovhcloud.com/en/guides/bare-metal-cloud/virtual-private-servers/import-export-
   n8n
 * Rapid Developers, “Back Up n8n Workflows: Export JSON, CLI and Git” — https://
   rapidevelopers.com/n8n-tutorial/how-to-back-up-n8n-workflows

## Sources

 * {‘title’: ‘n8n Backup Strategy: How to Protect Your Workflows, Credentials, and
   Execution Data’, ‘url’: ‘https://massivegrid.com/blog/n8n-backup-disaster-recovery/’}
 * {‘title’: ‘The n8n Encryption Key: Where It Is and What Breaks’, ‘url’: ‘https://
   instapods.com/blog/n8n-encryption-key/’}
 * {‘title’: ‘How to Migrate an n8n Configuration Between Two VPS’, ‘url’: ‘https://
   docs.ovhcloud.com/en/guides/bare-metal-cloud/virtual-private-servers/import-export-
   n8n’}
 * {‘title’: ‘Back Up n8n Workflows: Export JSON, CLI and Git’, ‘url’: ‘https://
   rapidevelopers.com/n8n-tutorial/how-to-back-up-n8n-workflows’}