How to Back Up & Restore n8n: Complete 2026 Guide

n8n backup and restore is the process of exporting workflows, credentials, and encryption keys so an instance can be fully rebuilt after failure or migration. A complete n8n backup requires three components: workflow JSON files, credential data, and the encryption key stored in the N8N_ENCRYPTION_KEY environment variable.

The most common failure is credential loss. Because n8n encrypts all credentials with this single key, restoring a backup without it makes every credential return a decryption error — rendering the backup unusable. Practitioners consistently report that missing encryption keys, rather than corrupted data, are the leading cause of failed n8n restorations. As one practitioner guide puts it, “a single corrupted database” is far less common than a restore that fails because the key was never captured (jservo.com backup guide).

To back up n8n correctly, follow three steps:

1. Export workflows and credentials: run n8n export:workflow --all and n8n export:credentials --all.
2. Save the encryption key from ~/.n8n/config or your environment variables.
3. Store all three offsite, encrypted, with versioned copies.

Restoration reverses this process, importing data first, then applying the original encryption key. The classic failure mode: an operator backs up thousands of workflow JSON files, feels completely safe, then discovers during a server migration that every restored credential returns a decryption error — because they never backed up the one file that mattered most.

Backing up n8n properly means capturing three distinct components plus one secret: workflow definitions, credentials, execution data, and the encryption key that unlocks those credentials. Miss any one and your recovery fails. That’s the gap most tutorials skip, and it’s the gap that costs founders a weekend of downtime.

Quick Summary: How to Back Up and Restore n8n

• An n8n backup consists of four elements: workflow JSON files, encrypted credentials, execution and history data, and the N8N_ENCRYPTION_KEY. A complete backup requires all four; missing any one results in partial or unusable recovery.
• The encryption key is non-negotiable — restored credentials are useless without the original N8N_ENCRYPTION_KEY. If you don’t manually set this key, n8n generates a random one automatically on first run and stores it in the ~/.n8n/config file, meaning many users don’t realize they have a key until a restore fails.
• Three main backup methods exist: editor UI export, n8n CLI export/import, and full database backup (SQLite file copy or Postgres dump).
• Untested backups aren’t backups — run a quarterly restore drill against a staging instance to prove recoverability.
• Compliance matters in MENA/GCC: credential backups can contain personal data subject to Saudi PDPL and UAE data-residency rules, so encrypt at rest and control where copies live.
• Automate off-site backups using n8n itself, pushing versioned copies to Git or cloud storage on a schedule.

Published: 31 July 2026. Last reviewed: 31 July 2026. Written from generic topical expertise in workflow-automation operations; commands and behaviours below were verified against publicly documented n8n CLI and self-hosting guidance current as of mid-2026. Always confirm exact flags against your installed version with n8n --help.

What Exactly Are You Backing Up in n8n?

An n8n backup is a complete copy of four components — your workflows, credentials, execution data, and the encryption key — that together let you restore a working instance after data loss, corruption, or a failed migration. Skip the encryption key and your restored credentials stay permanently locked, because n8n encrypts credential data with a key that is stored separately in the ~/.n8n/config file (or the N8N_ENCRYPTION_KEY environment variable) by default rather than inside the workflow data.

n8n stores its state in a database (SQLite by default, or PostgreSQL for production deployments), which holds workflows and execution logs, while the encryption key lives outside that database. This separation is the single most common reason backups fail: teams export the database but forget the key file. A database-only backup restores your workflow logic but leaves every stored password, API token, and OAuth credential unusable — so a complete backup requires both the database and the encryption key together. RapidDev’s guide makes the same point, stressing that a full backup must include workflows, the database, and the encryption key (RapidDev, Back Up n8n Workflows).

Understanding each storage layer is the difference between a real backup and a false sense of security. A recurring mistake practitioners correct is a team that exported workflows but assumed credentials came along for the ride. They don’t — not usably, anyway.

The four components of a complete backup

• Workflow definitions — stored as JSON, these describe every node, connection, and parameter. They are human-readable and version-control friendly, with a typical workflow file spanning only a few kilobytes to a few dozen kilobytes.
• Credentials — API keys, database passwords, and OAuth tokens. Stored encrypted in the database, they are decryptable only with the matching encryption key. Restore workflows without this key and every stored integration credential will fail.
• Execution data — the historical logs of every workflow run, including inputs, outputs, and errors. In high-volume deployments this is typically the largest share of the database, which is why many teams prune executions on a rolling schedule (for example, older than 30 days).
• The encryption key — a single secret string held in N8N_ENCRYPTION_KEY (environment variable) or in ~/.n8n/config. Without it, exported credentials cannot be decrypted on the target instance. As backup practitioners often summarise it: a backup you can’t decrypt is not a backup.

Treat the key as the crown jewel, not a footnote. A database dump alone is insufficient if the key lives in a config file you forgot to copy.

How Do I Back Up and Restore n8n Including Workflows, Credentials, and Execution Data?

Backing up n8n requires securing four components: workflows, credentials, the underlying database, and the encryption key. A complete backup involves exporting workflows and credentials via the n8n CLI (n8n export:workflow --all --output=backup.json and n8n export:credentials --all), dumping the database (a SQLite file by default or a PostgreSQL dump for production), and copying the encryption key stored in ~/.n8n/config or the N8N_ENCRYPTION_KEY environment variable. Store all four off-site, ideally in an encrypted repository.

The encryption key is the most critical element: without it, credentials cannot be decrypted, rendering stored credentials unrecoverable even if the database survives. Restore by reversing the process on an n8n instance running a matching or newer version, importing credentials before workflows to preserve references. For teams, schedule automated backups (a nightly cadence is common) and retain several daily snapshots. Test restores quarterly, since an untested backup carries no guarantee of successful recovery.

There are three practical methods, and the right one depends on your deployment. A Docker VPS running Postgres has different mechanics than a single-user SQLite instance. Here’s how each works, with the trade-offs practitioners generally weigh.

Method 1: Editor UI export (fastest, least complete)

The n8n editor lets you download any workflow as JSON from the workflow menu, and export credentials individually. Quick for a handful of workflows, tedious at scale, and it does not capture execution history. Use it for ad-hoc snapshots before a risky edit, not as your primary backup.

Method 2: n8n CLI export/import (recommended for most SMEs)

The n8n command-line interface exports everything in bulk. The core commands:

1. n8n export:workflow --all --output=./backup/workflows.json — dumps all workflow definitions.
2. n8n export:credentials --all --output=./backup/credentials.json — dumps credentials. By default these are still encrypted; add --decrypted only if you’re storing the file in a secured, encrypted vault.
3. Copy the encryption key from ~/.n8n/config or your N8N_ENCRYPTION_KEY environment variable into the same secured location.
4. To restore: n8n import:workflow --input=./backup/workflows.json and n8n import:credentials --input=./backup/credentials.json on the target instance — which must have the identical encryption key set before import.

CLI export/import is a common default recommendation for startups because it’s scriptable, version-control-friendly, and captures the two components that matter most for continuity. Its one gap: it doesn’t include execution history, so pair it with Method 3 if you need audit trails.

Method 3: Full database backup (most complete)

Backing up the database captures workflows, credentials, and execution data in one operation. For SQLite deployments, stop n8n and copy ~/.n8n/database.sqlite. For Postgres, run pg_dump:

1. pg_dump -U n8n -h localhost n8n > n8n_backup_$(date +%F).sql
2. Copy the encryption key separately — the database dump does not contain it in a usable form.
3. Restore Postgres with psql -U n8n n8n < n8n_backup.sql, then start n8n with the matching encryption key.

Groove Technology’s n8n backup guide notes that database-level backups are the method that fully preserves execution history — a requirement if regulators or your own finance team ever ask what a workflow actually did on a given date (Groove Technology, n8n Backup Guide).

Method Comparison: Which Backup Approach Fits Your Setup?

The best backup method depends on scale, deployment type, and whether you need execution history. UI export suits quick snapshots; CLI export fits scriptable SME workflows; full database backup is essential for audit-grade recovery. Most production instances should combine CLI export with scheduled database dumps.

Notice that no single row captures everything and automates cleanly on its own. That’s why practitioners typically layer methods: a scheduled Postgres dump for completeness, plus a CLI-driven Git commit for readable, diffable workflow history. Redundancy costs almost nothing here and buys enormous peace of mind. For a deeper look at self-hosting economics, see our n8n self-hosting cost breakdown.

Why Is the Encryption Key So Critical When You Back Up and Restore n8n?

how do i back up and restore n8n including workflows, credentials, and execution data ? is one of the most relevant trends shaping 2026.

The encryption key is critical because n8n encrypts all credentials at rest, and only the exact matching key can decrypt them on restore. Lose or mismatch the key and every API token, database password, and OAuth secret in your backup becomes unrecoverable — forcing you to re-enter every credential by hand.

Here’s the scenario practitioners walk founders back from more than once. A team migrates their n8n instance to a new Docker host. They restore the database perfectly. Workflows appear intact. Then every workflow throws “Credentials could not be decrypted” errors, because the new container generated a fresh random encryption key on startup. The credentials are physically present in the database — just permanently locked.

How to manage the encryption key safely

• Set it explicitly. Define N8N_ENCRYPTION_KEY as an environment variable rather than letting n8n auto-generate one. Auto-generated keys live in ~/.n8n/config and are easy to lose during container rebuilds.
• Store it separately from the backups it unlocks. Keeping the key in the same folder as the credential export is like taping your house key to the front door.
• Use a secrets manager. AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault give you access logs and rotation controls — valuable for audit trails.
• Rotate deliberately, not accidentally. Rotating the key requires re-encrypting existing credentials; never change it casually on a live instance.

Think of the encryption key as the deed to a safe. You can copy the safe and everything inside it, but without the deed no one can prove ownership or open the door. We document key handling in our deployment and security playbook because it’s the failure point vendors most often gloss over.

How Do I Automate n8n Backups Including Workflows, Credentials, and Execution Data?

You automate n8n backups using n8n itself: build a scheduled workflow that runs export commands, then pushes versioned copies to off-site storage like a Git repository, S3 bucket, or FTP server. The n8n community publishes a ready-made “Complete backup solution” template for exactly this.

The n8n.io workflow library hosts a community template titled “Complete backup solution for n8n workflows & credentials (local/FTP),” which saves both workflows and credentials to disk and FTP on a schedule (n8n.io, Complete backup solution). It’s a solid starting point. Here’s a pattern to build on top of it when you need audit-readiness:

1. Schedule trigger — nightly at a low-traffic hour, e.g. 02:00 Gulf Standard Time.
2. Execute Command node — run the CLI export for workflows and credentials into a timestamped folder.
3. Database dump step — trigger pg_dump or copy the SQLite file for full execution-history capture.
4. Push to versioned storage — commit the exports to a private Git repo (readable diffs) and upload the database dump to encrypted cloud storage.
5. Retention pruning — delete backups older than your policy window, e.g. keep 30 daily, 12 monthly.
6. Alert on failure — send a Slack or WhatsApp message if any step fails, because a silently broken backup job is worse than no job at all.

One honest caveat: automating credential export means credential secrets touch disk. Encrypt the destination, restrict access, and never commit decrypted credentials to Git. We cover WhatsApp-based failure alerting in our WhatsApp AI agent guide, which reuses the same notification pattern.

Why Do Restore Drills Matter More Than the Backup Itself?

Restore drills matter because an untested backup is a hypothesis, not a safety net. A backup only proves its value when you successfully restore from it — and the moment to discover a corrupt file or missing encryption key is during a drill, not during a real outage at 3 a.m.

A practical operational habit is a quarterly restore drill: spin up a clean staging n8n instance, restore the latest backup end-to-end, and verify that workflows execute and credentials decrypt. In a typical drill, the fastest way to expose a problem is to run one real workflow that touches an external credential — if it returns “could not be decrypted,” the key wasn’t captured correctly. The drill answers two business questions that matter far more than “did the backup run?”

• RPO (Recovery Point Objective) — how much data can you afford to lose? If you back up nightly, your worst-case data loss is roughly 24 hours of executions.
• RTO (Recovery Time Objective) — how fast can you be operational again? A documented, drilled restore might take 20 minutes; an undocumented one can take a full day of guesswork.

For an SME running billing, payroll, or customer-service automations through n8n, downtime isn’t abstract. If a workflow that sends WPS-compliant salary notifications or VAT invoice reminders is offline, the cost compounds by the hour. Defining RTO/RPO targets turns backup from an IT chore into a business-continuity decision your finance lead can sign off on.

How Should MENA/GCC Businesses Handle Backup Compliance and Data Residency?

how do i back up and restore n8n including workflows, credentials, and execution data ? plays a pivotal role in this context.

MENA/GCC businesses should treat n8n credential and execution backups as personal-data assets subject to Saudi PDPL, UAE data-protection law, and sector rules like GOSI/WPS or RERA where relevant. That means encrypting backups at rest, controlling where copies physically reside, and documenting retention periods for audit.

Execution data is the sleeper compliance risk. Workflow run history can contain names, national IDs, salary figures, or tenant details that passed through a node. Under Saudi Arabia’s Personal Data Protection Law (PDPL) and the UAE’s federal data-protection framework, that data can carry residency and consent obligations even when it’s sitting in a backup file. You can verify these frameworks directly through the Saudi Data & AI Authority (SDAIA) and cross-reference EU-aligned principles via the official GDPR overview, since many GCC laws mirror GDPR structure.

A practical compliance checklist for backups

• Data residency: keep backup copies in-region (e.g. a KSA or UAE cloud zone) when handling regulated personal data.
• Encryption at rest: encrypt the backup destination, not just the credentials inside n8n.
• Retention policy: define and document how long you keep execution data — indefinite retention is a liability, not a virtue.
• Access logging: track who can read or restore backups, using a secrets manager’s audit log.
• Right-to-erasure readiness: know how you’d purge a specific individual’s data from historical backups if legally required.

The honest caveat here: compliance frameworks evolve, and this isn’t legal advice. Confirm current requirements with a qualified advisor before finalizing your retention and residency policy.

Your Actionable Backup Checklist

Here’s a checklist to prevent incomplete backups — the single most common cause of failed n8n restores.

1. Set N8N_ENCRYPTION_KEY explicitly and store it in a secrets manager, separate from backups.
2. Schedule a nightly CLI export of all workflows and credentials.
3. Schedule a nightly database dump (SQLite copy or pg_dump) for full execution history.
4. Push versioned copies off-site — Git for workflows, encrypted cloud storage for the database.
5. Apply a retention policy and prune old backups automatically.
6. Wire up failure alerts so a broken job screams instead of hiding.
7. Run a full restore drill on staging every quarter and record your RTO and RPO.
8. Keep backups in-region and encrypted at rest for PDPL/GDPR alignment.

Work through all eight and you’ve moved from “we have some exports somewhere” to a defensible, testable disaster-recovery posture. The difference shows up exactly once — on the day something breaks — and on that day it’s worth more than everything else combined.

The next frontier isn’t better backup scripts; it’s backups that verify themselves. As self-hosted automation spreads across GCC SMEs, expect restore-drill-as-code — pipelines that spin up a throwaway instance, restore, run a synthetic transaction, and report green or red without a human watching. When your backup can prove its own recoverability every night, downtime stops being a gamble and becomes a solved problem. If you’d like hands-on help designing a tested, compliant n8n backup and restore setup, reach out to our team.

Frequently Asked Questions

Does exporting n8n workflows also back up my credentials?

No. Exporting workflows via the editor or CLI captures only the workflow JSON, not credentials. Credentials must be exported separately, and they remain encrypted and unusable without the matching N8N_ENCRYPTION_KEY. A complete backup always requires both plus the key.

What happens if I lose my n8n encryption key?

Losing the encryption key makes every backed-up credential permanently undecryptable. Workflows and execution data survive, but you’ll have to re-enter every API key, password, and OAuth token manually on the restored instance. Always store the key in a secrets manager, separate from your backups.

How do I back up n8n execution data specifically?

Execution data lives only in the database, so a full database backup — copying the SQLite file or running pg_dump on Postgres — is the only method that preserves it. CLI and UI exports capture workflows and credentials but skip execution history entirely.

How often should an SME back up n8n?

Most SMEs back up nightly, keeping several daily and monthly copies (a common pattern is 30 daily and 12 monthly). Nightly backups cap worst-case data loss at roughly 24 hours (your RPO). Higher-volume or compliance-sensitive instances handling payroll or billing may warrant more frequent backups and shorter recovery targets.

Can I restore an n8n backup to a different server or Docker host?

Yes, provided the target runs a compatible n8n version and has the identical encryption key set before you import. Restore the database or CLI exports, confirm the key matches, then start n8n. Version mismatches and missing keys are the two most common migration failures.

Sources & References

• RapidDev — Back Up n8n Workflows: Complete Guide (export via editor/CLI, database backup, restore instructions).
• Groove Technology — n8n Backup Guide: How to Secure Your Workflows and Data.
• n8n.io — Complete backup solution for n8n workflows & credentials (local/FTP).
• jservo.com — How to back up and restore n8n workflows.
• Saudi Data & AI Authority (SDAIA) — Personal Data Protection.
• GDPR.eu — What is GDPR?

Last updated: 2026-07-31

Note: This article is for general informational purposes; verify specifics against your own context.

Before committing to a self-hosted setup, it helps to understand how n8n compares to Zapier and Make in 2026 so you can confirm the platform fits your automation and data-control needs.