n8n backups: a snapshot is not a backup

Short answer

A snapshot is a manual, short-lived rollback point on the same host. A backup is scheduled, retained, and stored off the box. For n8n, neither helps unless it holds the .n8n folder — the credential encryption key and, on the default database, SQLite — or a Postgres dump plus .n8n. Without that key, restored credentials cannot be decrypted. Some hosts document scheduled backups, some document snapshots, and every remaining cell is not yet verified. The host table was checked on October 18, 2026.

In October 2026, one self-hoster reported their VPS came back from an old snapshot after emergency maintenance — we could not verify this report, and it is not evidence about any specific host's current practice.

The sentence about the encryption key is from n8n's backup and restore docs, checked Oct 18, 2026. n8n Community Edition does not include a host. You pay for the server + backup storage/time. A dash in the table below is not a “no”.

What does a complete n8n backup actually need to include?

A complete backup of a self-hosted n8n instance is two parts, from backup and restore. First, the .n8n user folder (~/.n8n by default). It holds the config file, which stores the credential encryption key. With the default SQLite database, it also holds the database file. If binary data or execution data uses filesystem storage, it holds that data too. You can move the folder with N8N_USER_FOLDER. n8n then uses the .n8n subfolder of the path you set. Second, your external database, if you use PostgreSQL instead of SQLite. Back that up with the database's own tooling. The .n8n folder is still part of the backup, because credentials in the database are encrypted with the key it holds.

If binary data or execution data lives on S3, Azure Blob Storage, or a custom filesystem path, include that location too. If you load custom nodes from directories in N8N_CUSTOM_EXTENSIONS, back those directories up. A restored instance without them is missing nodes its workflows reference. How much RAM and CPU n8n needs is the sizing guide for the SQLite-versus-Postgres choice, including queue mode. Queue mode is the layout with worker processes, Postgres, and Redis. It does not change this list. It changes where the database lives, and it means a copy of only the VPS disk can miss a database you moved off the box.

I lost my n8n encryption key — can I restore my credentials?

No. n8n saves credentials in encrypted form. Without the encryption key from the config file, or the same custom N8N_ENCRYPTION_KEY, a restored database or an encrypted credential export cannot be decrypted (backup and restore, checked Oct 18, 2026).

SQLite, Docker, and where the files actually are

With the default SQLite database, stop n8n before copying .n8n. Copying the database file while n8n is writing to it can produce an inconsistent backup. If you cannot stop n8n, use a tool that takes a consistent snapshot of the SQLite file. That wording is n8n's, for the database file. It does not turn a VPS snapshot into a backup.

If you run n8n in Docker, .n8n lives in the n8n_data volume, mounted at /home/node/.n8n. A backups/ directory inside the container is not persisted. Bind-mount a host directory for your exports, or copy them out before you recreate the container.

Checklist

• The .n8n user folder (~/.n8n by default), including the config file that holds the credential encryption key. With the default SQLite database, that folder also holds the database. If binary data or execution data uses filesystem storage, it holds that data too.
• Your external database, if you use PostgreSQL, using that database's own tooling. The .n8n folder is still required, because credentials in the database are encrypted with its key.
• External binary or execution storage, such as S3 or Azure Blob Storage, if you configured it. A custom filesystem path for that data, if you set one.
• Directories in N8N_CUSTOM_EXTENSIONS, if you load custom nodes from them. A restored instance without those directories is missing nodes its workflows reference.
• With SQLite, stop n8n before copying .n8n. Copying the database file while n8n is writing can produce an inconsistent backup. If you cannot stop n8n, use a tool that takes a consistent snapshot of the SQLite file.
• On Docker, .n8n lives in the n8n_data volume, mounted at /home/node/.n8n. A backups/ directory inside the container is not persisted. Bind-mount a host directory, or copy exports out before recreating the container.
• A second copy of the encryption key, kept apart from the only backup that contains it. The key is what decrypts credentials. If that one backup is the copy you lose, the database export cannot be decrypted.

The checklist is the backup-and-restore page, checked Oct 18, 2026. The last item is the practical consequence of the key living inside .n8n: keep another copy of the key apart from the only backup that contains it. This page does not name a tool for that copy.

Why the CLI export is not a backup

n8n export:workflow --backup and n8n export:credentials --backup write workflows and credentials as separate JSON files. The --backup flag sets --all --pretty --separate. Use a different output directory for each command. import:credentials --separate currently fails when the input directory also contains workflow files. That is a known issue in the docs.

The docs say those exports do not include:

• Users and their roles. After importing into a fresh instance, n8n shows the owner setup screen again, and the first person to complete it becomes the owner.
• Execution history and logs.
• Variables.
• Instance settings, including the encryption key.

A CLI export is enough to move workflows between instances. It is not enough to recover an instance. For that, keep .n8n and the external database. The export is still the right tool for an off-host copy of workflows and credentials: a copy you can take with you if the host itself is the failure. On Docker, copy that export out of the container. It is not kept for you.

Is a VPS snapshot a backup for n8n?

No. A snapshot is a manual, short-lived rollback point on the same host. A backup is scheduled, retained, and stored off the box. A snapshot of the same disk the VPS boots from can roll that disk back. It is not, by itself, a copy that survives the box.

Hostinger's English support article is one host stating that split in its own words. How to back up or restore a Hostinger VPS, checked Oct 18, 2026: backups are automated weekly by default, and daily if you enable that upgrade. They are stored separately from the server. Up to four are retained, two daily and two weekly. Snapshots are manual, only one at a time, expire after 1 day, and are deleted if you reinstall the OS or restore from a backup. Restoring either overwrites the VPS. The action cannot be stopped, and the server is locked until it finishes.

English-edition flag. The Spanish edition of the same article, also checked Oct 18, 2026, says snapshots are deleted after 20 days. It also says each new weekly backup replaces the previous one, and that daily backups are deleted after 7 days. This page prints the English figures, with the English URL. It does not average the editions.

The same warning applies to a live copy of SQLite. n8n says to stop n8n before copying .n8n, or to use a tool that takes a consistent snapshot of the SQLite file. A host disk snapshot taken while n8n is running inherits that consistency warning. Where a host documents the same limit, the table quotes that host. This page does not add a restore-time estimate.

Which n8n hosts include real backups, and which only include snapshots?

A host is a fit for n8n backups only when official docs cover the rows that apply: the copy contains .n8n or a Postgres dump plus .n8n; it is stored off the box; a frequency and a retention are stated, not implied by the word “included”; you can restore it yourself, and you have tested that restore; and you can get an n8n export off the host entirely. Order below is dataset order. Affiliate status is not an input. This table is not a ranking.

1. The right things. A disk image of a stopped or consistent state, or an export you control. A live snapshot against SQLite inherits the consistency warning above.
2. Off the box. Stored separately from the VPS. A snapshot on the same failure domain is a rollback tool.
3. Scheduled and retained. A frequency and a retention count or a number of days, from the host. “Backups included” with no numbers leaves frequency and retention as — / not yet verified.
4. Restorable by you. A self-serve restore, with the overwrite and lock consequences the host actually documents. An untested backup is a hope. This site has not run a test restore.
5. Exportable. A workflow and credential export, plus the key, that you can take off the host if the host is the failure.

Disclosure: Some host links below are affiliate links. We may earn a commission if you sign up, at no extra cost to you. Prices and order are not affected.

Plan names are the plans in prices.json. Dated prices: n8n hosting prices — October 2026. Backup add-on prices are quoted only where the host publishes them. A percentage is the host's formula, not a price this site computed. How checks work.

Backups are a separate cost from the server. The dated tables are on what n8n costs at 2,500, 10,000, and 50,000 executions a month. The renewal-aware calculator takes your own backup amount per month. Neither page turns a dash into zero. For fit and price context, see best n8n hosting, cheapest way to host n8n, and free n8n hosting. Those pages do not rank a cheapest backup.

A backup routine that survives your host

The host table is what the host documents. It is not the only copy you should have. The minimum that does not depend on one panel:

1. A scheduled copy, stored off the box, of everything in the checklist: .n8n, and the Postgres dump if the database is not inside that folder.
2. A separate CLI export of workflows and credentials, also off the host. Use different output directories. Copy the files out of Docker.
3. The encryption key stored apart from the only backup it unlocks. The key decrypts credentials in the database. If the only copy of the key is inside the backup you lose, a database export cannot be decrypted. This page does not recommend a product for that second copy.
4. Retention you set, long enough that you can notice a bad workflow or a bad update before the last good copy expires. Where a host publishes a retention, the table quotes it. Where it does not, the cell stays — / not yet verified. This page does not add a number of its own.
5. A test restore. This site has not run one. An untested backup is a hope.

Test the restore

1. Restore to a scratch instance, not over the one you are using.
2. Log in.
3. Run one workflow.
4. Confirm one credential decrypts and connects.

If the credential does not decrypt, the key in that restore does not match the database. Stop there. Do not treat the host panel's “restore” button as proof until this works.

What should I back up before updating n8n?

A full backup, as defined above. n8n's backup docs say n8n recommends taking a full backup before updating (backup and restore). The update docs, checked Oct 18, 2026, say to update at least once a month, to check the release notes for breaking changes, and to test the update in a separate environment first. This page does not add an update guide. Follow those docs. Moving the same backup to another host is the restore procedure in the FAQ: the key, the database, and the deployment configuration.

On n8n Cloud, instance owners can download workflows from the most recent backup (download workflows). Pricing does not state a backup schedule. After a trial ends, the download window is 90 days, and then workflows are permanently deleted. That window is not a retention policy for a paid plan.

FAQ

Is a VPS snapshot enough to back up n8n?

No. A snapshot is a rollback point. It is not a backup. n8n's backup and restore docs say that with the default SQLite database you should stop n8n before copying the .n8n folder, because copying the database file while n8n is writing can produce an inconsistent backup. A host disk snapshot taken while n8n is running inherits that warning. The copy still has to contain .n8n — the encryption key and, on SQLite, the database — or you need a Postgres dump plus .n8n. Without the key, restored credentials cannot be decrypted. Checked October 18, 2026.

What happens if I lose my n8n encryption key?

You cannot decrypt restored credentials. n8n stores credentials in encrypted form. Without the encryption key from the .n8n config file, or the same custom N8N_ENCRYPTION_KEY, a restored database or an encrypted credential export cannot be decrypted. Checked October 18, 2026 on n8n's backup and restore docs.

Does the n8n CLI --backup export back up my whole instance?

No. n8n export:workflow --backup and export:credentials --backup write workflows and credentials only. They do not include users and their roles, execution history and logs, variables, or instance settings, including the encryption key. That export can move workflows. It cannot recover an instance on its own. Use a different output directory for each command. On Docker, a backups/ directory inside the container is not persisted. Checked October 18, 2026.

Which hosts include backups?

The host table on this page is the answer, in dataset order, checked October 18, 2026. A dash means not yet verified from that host's official docs. It does not mean the host has no backup. No host is ranked best for backups. Hostinger KVM documents weekly backups by default, stored separately from the server, with daily backups as an upgrade whose price is not published. The English and Spanish editions of Hostinger article 1583232 disagree on snapshot expiry and on weekly retention. This page uses the English page and does not average them. Hostinger Managed n8n documents daily backups kept 7 days. OVHcloud includes one daily backup of the previous 24 hours. Elestio's managed n8n page documents daily remote backups and a daily snapshot. Retention of the remote backup depends on the support plan, and which plan the managed n8n service in this dataset includes is not verified. Sliplane documents daily volume backups kept 7 days. DigitalOcean, Hetzner, Vultr, and Linode document backups as a paid add-on, not as included. Railway documents volume backups you schedule. They are not on until you schedule them, and wiping the volume deletes them. Weekly and monthly Railway retention figures disagree across two official pages, so those two stay unverified. Oracle Always Free includes five volume backups and does not state that a schedule is already on. Render's persistent-disk page documents a daily disk snapshot kept at least 7 days on a paid service with a disk: snapshot only — not a backup. The Hobby plan is not named there. Contabo's official pages contradict each other on automatic backup, so that cell stays unverified. One snapshot, retained 30 days, is documented, and a snapshot is not a backup. The Contabo row carries needs review: parse failed. netcup's VPS Lite page lists snapshots and does not publish an automatic backup. n8n Cloud docs say owners can download workflows from the most recent backup and do not state a backup schedule.

How often should I back up n8n?

No benchmark is published on this page, and this page does not prescribe one. n8n's update docs say to update at least once a month and to take the update docs' own advice to test in a separate environment. The backup docs say to take a full backup before updating. How often you copy .n8n, the database, and an off-host export is your choice. Judge it by whether a schedule and a retention are written down, whether the copy is off the box, and whether you have restored it to a scratch instance and opened one credential. An untested backup is a hope.

Can I restore n8n onto a different host?

Yes, if you have the encryption key and the database. n8n's restore steps are: stop n8n, restore the .n8n folder and any N8N_CUSTOM_EXTENSIONS directories, restore PostgreSQL if you use it, restore the deployment configuration (database connection, a custom N8N_ENCRYPTION_KEY if you set one, and external storage settings), then start n8n. A CLI export can move workflows to another instance only if that instance can decrypt the credentials, which means the same key, or a decrypted export. A decrypted export is plain text. Checked October 18, 2026.