How to back up and restore n8n workflows

Learning how to back up and restore n8n workflows is essential for protecting your automation infrastructure. You have four core methods available: exporting workflows as JSON files, backing up the underlying database (SQLite or PostgreSQL), using version control with Git, and automating exports through the n8n CLI. A backup is a complete copy of your workflows, credentials, and execution data that lets you restore your instance after data loss.

A single corrupted database migration can erase hours of careful workflow engineering in seconds — and because credentials and the encryption key live separately from the workflow JSON, an incomplete backup can leave you with automations that import but no longer authenticate. The n8n Community discussion on backing up and restoring workflows and credentials is a recurring example: self-hosted Docker users repeatedly report losing access to credentials after an upgrade because they captured only the workflow JSON.

To back up n8n on a self-hosted instance, run n8n export:workflow --all --output=backup.json to export all workflows, then back up your .n8n directory containing credentials and the encryption key. To restore, run n8n import:workflow --input=backup.json against a matching n8n version. Schedule automated backups and test restores on a regular cadence to verify your recovery process works before you actually need it.

How to back up and restore n8n workflows comes down to four proven methods: GitHub sync for version-controlled automation, local/FTP dumps for full credential redundancy, API-based bulk export for n8n Cloud users without database access, and direct database snapshots for self-hosted instances. The right choice depends on whether you’re on n8n Cloud or self-hosted, and how much you value disaster-recovery speed over setup simplicity.

This guide compares every method head-to-head, walks through a security-hardened approach to credential backups, and gives n8n Cloud users a practical disaster-recovery runbook — the part missing from most tutorials online.

Quick Summary: How to Back Up and Restore n8n Workflows

• Four core methods cover most deployments. GitHub sync is the most automated, committing workflow JSON on every change and enabling version rollback. Local and FTP dumps store complete copies off-site for disaster recovery. API bulk export is the practical path for n8n Cloud users, exporting all workflows through the REST API. Database snapshots deliver the most complete full restore in a single operation.
• Self-hosted users can back up the underlying SQLite or PostgreSQL database directly — the single most complete restore option, because it captures workflows, credentials, execution history, and settings together. For production, n8n’s own guidance favours PostgreSQL over SQLite, since SQLite can degrade under concurrent writes.
• n8n Cloud users lack CLI and database access, so API-based export is the only viable automated path, as the RapidDev backup guide confirms.
• Credentials are the danger zone: they hold raw API keys and must be restored with the original N8N_ENCRYPTION_KEY to decrypt correctly.
• Automate on a schedule: a daily backup with around 30 days of retention covers most small-business disaster-recovery needs.
• The official GitHub sync template detects new, edited, renamed, and deleted workflows automatically and commits them with descriptive messages and an index for tracking.

Published: 13 June 2026. Last updated: 13 June 2026. This guide reflects n8n behaviour at the time of writing; always confirm command syntax against the current n8n documentation, as CLI flags and API endpoints change between releases.

Who should read this guide

This article is written for n8n operators — self-hosted administrators running Docker on a VPS or Linux VM, and n8n Cloud users who manage production automations and need a recovery plan. It is based on the publicly documented n8n backup mechanisms and community-reported failure patterns cited throughout, not on any private benchmark. Where this guide gives a recommendation (for example, daily backups or pre-upgrade snapshots), it is general best-practice guidance you should adapt to your own change rate, compliance requirements, and risk tolerance. No author or organisation profile is attached to this piece; treat the recommendations as topical guidance and verify each command in a test environment before running it in production.

What does it mean to back up and restore n8n workflows?

Backing up n8n workflows means exporting your automation logic — nodes, connections, settings — and your credentials into a portable, recoverable format. Restoring means importing that data into a working n8n instance to recover from data loss, migrate servers, or roll back a broken change.

There are three common backup formats:

• JSON files: individual workflow exports, ideal for sharing or version control.
• Git repository: tracks every change with full revision history.
• Database dump: captures all workflows, credentials, and execution data at once.

Backups protect against three main risks: data loss, failed migrations, and broken upgrades. A useful rule of thumb practitioners repeat is that a backup you have never restored is not a backup — it is an assumption. For best results, back up on a regular schedule, store copies in at least two locations, and test restores periodically.

An n8n workflow is a JSON object describing a sequence of automation steps, trigger conditions, and node configurations. A credential is a separate encrypted record holding the API keys, OAuth tokens, and passwords those nodes use. A complete backup must capture both — and this is where most teams get burned.

n8n stores everything in a database (SQLite by default, or PostgreSQL for production), so the database itself is the source of truth. The n8n Community thread on backing up workflows and credentials documents the common failure mode directly: self-hosted Docker users lose credentials during upgrades when they back up only workflow JSON and forget the encryption key.

Think of it like backing up a house: the workflows are the furniture, the credentials are the keys to the front door, and the encryption key is the deed that proves the keys are yours. Lose any one and you can’t move back in.

What are the main methods to back up and restore n8n workflows?

n8n workflows can be backed up and restored using four main methods: GitHub sync, local/FTP file dumps, API-based bulk export, and direct database snapshots. GitHub sync is the most automated and version-friendly, committing on every workflow change and supporting full version history. Database snapshots (PostgreSQL or SQLite) deliver the fastest complete restore because they capture everything in one file. API-based bulk export is the practical option for n8n Cloud, where there is no database access, handling exports through the /workflows endpoint. Local/FTP file dumps remain the simplest scheduled approach and, unlike GitHub sync, can include credential records.

For production environments, a common recommendation is to combine database snapshots (for disaster recovery) with GitHub sync (for change tracking), since no single method covers both speed and version control. Self-hosted users should schedule automated backups at least daily.

Each method trades simplicity against completeness. A typical pattern looks like this: self-hosted teams pair a database snapshot with GitHub sync, while n8n Cloud teams lean on the API. Here’s the head-to-head breakdown.

GitHub sync: the most automated approach

GitHub sync is the most automated method for version-controlling n8n workflows. The official n8n GitHub sync template automatically detects four types of changes — new, edited, renamed, and deleted workflows — then commits them to GitHub with descriptive commit messages and a JSON index for tracking. Each change becomes a versioned, diffable record, which is exactly what disaster recovery and audit trails require.

This approach eliminates manual exports. Setup requires three components: a GitHub repository, a personal access token with repo scope, and a scheduled trigger (commonly every few hours). Unlike manual JSON exports, GitHub sync runs continuously without human intervention, reducing gaps in your version history. Every commit timestamps the change, identifies the modified workflow by ID and name, and preserves the full node configuration.

GitHub sync shines for teams because Git gives you blame history, rollback to any commit, and branch-based promotion across environments. The catch: it captures workflow JSON only, not credentials. You’ll need a second method to cover the keys.

Local and FTP dumps: full redundancy

The complete backup solution template saves both workflows and credentials to local or server disk, with optional FTP for off-site redundancy. Unlike GitHub sync, this approach captures the encrypted credential records, making it a true full-system backup that you can store on a separate machine or cloud bucket. The trade-off is that flat file dumps don’t give you Git’s diff-and-blame history, so many teams run both: GitHub sync for traceability, an FTP/local dump for credential redundancy.

How to back up and restore n8n workflows on self-hosted instances

To back up and restore n8n workflows on a self-hosted instance, dump the underlying database (SQLite file or PostgreSQL with pg_dump) along with the N8N_ENCRYPTION_KEY environment variable. Restoring means importing that database into a matching n8n version and confirming the encryption key matches so credentials decrypt correctly.

Self-hosted n8n, typically run via Docker on a VPS or Linux VM, gives you the most powerful backup option: direct database access. In the n8n Community thread on backing up all workflows, a user describes a representative production setup — n8n version 1.64.3 on premise with PostgreSQL — where the database holds every workflow, credential, and execution record in one place. That single database is what makes a self-hosted full restore so much simpler than a Cloud one.

Here’s a deterministic, repeatable process for self-hosted backups:

1. Locate your database. SQLite lives in ~/.n8n/database.sqlite; PostgreSQL is a separate service. Confirm which you run before proceeding.
2. Capture the encryption key. Read N8N_ENCRYPTION_KEY from your environment or ~/.n8n/config. Without it, credentials are unrecoverable.
3. Dump the database. For PostgreSQL run pg_dump; for SQLite copy the file while n8n is stopped or use the CLI export.
4. Export via CLI as a portable fallback. Run n8n export:workflow --all --output=workflows.json and n8n export:credentials --all --output=creds.json.
5. Store off-site. Push the dump to an encrypted S3 bucket, FTP server, or separate VPS. The ucartz guide on Docker and VPS backups recommends a second physical location for true disaster recovery.
6. Test the restore. Spin up a throwaway instance, import the data, and verify a credentialed node actually authenticates.

Worked example: a tested restore on a throwaway instance

A typical restore verification looks like this. Export from the live instance:

$ n8n export:workflow --all --output=workflows.json
Successfully exported 42 workflows.
$ n8n export:credentials --all --output=creds.json
Successfully exported 17 credentials.

Then provision a fresh container running the same major version with the same N8N_ENCRYPTION_KEY, and import:

$ n8n import:credentials --input=creds.json
Successfully imported 17 credentials.
$ n8n import:workflow --input=workflows.json
Successfully imported 42 workflows.

The verification step that actually matters is opening one workflow that uses a credentialed node and running it — if the node authenticates and returns data, your encryption key matched and the restore is real. If credentials show as set but every execution fails with an authentication error, the encryption key did not match (see the troubleshooting note below). Exact counts and messages vary by n8n version, so treat the output above as illustrative of the shape, not a guarantee of wording.

Restoring is the reverse of the backup: provision a fresh n8n container with the same major version and the same encryption key, then import the database dump or run n8n import:credentials followed by n8n import:workflow. Version mismatches are a leading cause of failed restores because node schemas change between releases, so restore credentials before workflows and keep the n8n version aligned with the source instance.

How to back up and restore n8n workflows on n8n Cloud

To back up and restore n8n workflows on n8n Cloud, use the n8n REST API to bulk-export workflows programmatically, since n8n Cloud provides no CLI or direct database access. Build a dedicated backup workflow that calls the API, then saves each workflow JSON to GitHub, Google Drive, or S3 on a schedule.

As the RapidDev backup guide states plainly: “n8n Cloud does not provide CLI or database access. You can export individual workflows as JSON from the editor. For bulk backups, create a workflow that calls the n8n API.” This is the structural limitation Cloud users must design around.

The manual fallback works for single workflows: open the workflow, click the three-dot menu, and select Download to save the JSON. But manual export doesn’t scale past a handful of workflows, and humans forget. Automation is the only reliable path.

The n8n Cloud disaster-recovery runbook

Most tutorials stop at “export your JSON” and leave Cloud users stranded when disaster strikes. Here is a practical runbook for n8n Cloud:

1. Generate an API key in n8n Cloud under Settings → API. Store it as a credential, never hardcoded.
2. Build a scheduled backup workflow that calls GET /workflows to list all workflows, then loops through each to fetch full JSON.
3. Commit to GitHub using the GitHub node, producing a versioned, timestamped archive off-platform.
4. Schedule daily via the Cron/Schedule trigger at a low-traffic hour.
5. On disaster: provision a fresh n8n Cloud workspace or self-hosted instance, then POST each backed-up JSON to /workflows via the API to bulk-restore.
6. Reconnect credentials manually. The API does not export decrypted secrets, so re-enter API keys from your password manager.

The honest limitation: n8n Cloud’s API does not export usable credentials, for security reasons. You must maintain a separate, encrypted record of every API key — ideally in a secrets manager such as 1Password, Bitwarden, or HashiCorp Vault. Documenting every credential dependency up front is what makes a Cloud recovery painless rather than a scramble through old emails.

Why is credential security critical when backing up n8n workflows?

Credential security is critical because n8n credential backups contain raw API keys, OAuth tokens, and database passwords that grant full access to your connected systems. A leaked credentials file is functionally a master key to your entire SaaS stack — far more dangerous than leaked workflow logic.

n8n encrypts credentials at rest using the N8N_ENCRYPTION_KEY, but exported credential dumps and database backups are only as secure as where you store them. Stolen and exposed credentials remain one of the most common entry points for attackers, which makes credential handling the single highest-leverage security control in any automation backup.

Follow these non-negotiable rules for credential backups:

• Never commit credentials to GitHub. Use a private repo at minimum, and prefer keeping credentials out of Git entirely — workflows only.
• Encrypt backups at rest. Wrap dumps in GPG or store them in an encrypted bucket (S3 with SSE-KMS, for example).
• Protect the encryption key separately. Store N8N_ENCRYPTION_KEY in a secrets manager, not alongside the backup it unlocks.
• Rotate keys after any suspected exposure and re-encrypt affected credentials.
• Restrict file permissions to 600 on Linux so only the service user can read backup files.

A useful framing: the encryption key is the deed to your automation house — back up the workflows freely, but guard that key like a passport. Treat your n8n credential backups with the same discipline you would apply to production database passwords, because that is effectively what they unlock.

How often should you back up and restore n8n workflows?

You should back up n8n workflows at least daily for active production instances, with roughly a 30-day retention window and additional snapshots before every upgrade or major change. High-volume operations editing workflows hourly benefit from more frequent syncs; low-change instances can drop to weekly.

Backup frequency should mirror your rate of change and your tolerance for re-work. A team shipping new automations daily that backs up weekly risks losing several days of engineering. The GitHub sync method sidesteps this problem by committing on every detected change rather than on a fixed clock.

A sensible default schedule for small-business production instances:

Always snapshot before upgrades. The n8n Community forum contains repeated threads where Docker users lost credentials during version bumps because they had no pre-upgrade backup. A single pg_dump taking under a minute prevents hours of painful reconstruction. Adjust these figures to your own compliance and change-rate requirements — they are a starting point, not a regulatory standard.

Actionable Takeaways: Your n8n Backup Checklist

Put this guide into practice with a deterministic, security-first backup setup:

• Self-hosted? Pair a daily pg_dump (or SQLite copy) with the GitHub sync template for version history.
• n8n Cloud? Build an API-driven backup workflow that commits JSON to a private GitHub repo daily.
• Always store the N8N_ENCRYPTION_KEY in a separate secrets manager — never beside the backup.
• Test restores periodically on a throwaway instance. An untested backup is a hope, not a plan.
• Snapshot before every upgrade. Version mismatches break credential decryption.
• Set 30-day retention as your baseline, longer for compliance-sensitive operations.

The teams that sleep soundly aren’t the ones with the fanciest tooling — they’re the ones who tested their restore recently and watched it work. Reliability is a discipline, not a feature you buy.

Frequently Asked Questions

Where does n8n store workflows and credentials?

n8n stores all workflows, credentials, and execution data in its database — SQLite by default (in ~/.n8n/database.sqlite) or PostgreSQL in production setups. Credentials are encrypted at rest using the N8N_ENCRYPTION_KEY, which must be backed up separately for any restore to succeed.

Can I back up n8n workflows on n8n Cloud without CLI access?

Yes. Since n8n Cloud provides no CLI or database access, you back up workflows using the n8n REST API. Build a scheduled workflow that calls GET /workflows, fetches each workflow’s JSON, and commits it to GitHub or cloud storage. Credentials must be tracked separately in a secrets manager.

What is the most reliable way to restore n8n workflows after a server crash?

The most reliable restore method is importing a full database dump (PostgreSQL or SQLite) into a fresh n8n instance running the same major version with the same encryption key. This recovers workflows, credentials, and history in one operation, unlike JSON imports that capture workflows only.

Why do my n8n credentials break after restoring a backup?

Restored credentials break when the new instance uses a different N8N_ENCRYPTION_KEY than the one that encrypted them. n8n cannot decrypt credentials without the original key, so they appear corrupted. Always back up and restore the exact encryption key alongside your database.

How do I automate n8n workflow backups to GitHub?

Use the official n8n GitHub sync template, which auto-detects new, edited, renamed, and deleted workflows and commits them with descriptive commit messages and an index. Configure a GitHub credential and a schedule trigger, point it at a private repo, and your workflows version automatically on every change.

Sources & References

• Back up and restore n8n workflows with GitHub sync — n8n workflow template
• Complete backup solution for n8n workflows & credentials (local/FTP) — n8n workflow template
• Back Up n8n Workflows — Complete Guide, RapidDev
• Backing up and restoring Workflows and Credentials — n8n Community
• How backup all workflow? — n8n Community
• How to Backup and Restore n8n Workflows — ucartz.com

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