n8n updates and backups: who looks after them?

Anyone who runs n8n on their own server needs a named person who updates and backs it up (called the administrator below), and a deputy. The manufacturer’s security advisories are numerous, but of those rated critical, almost all require a logged-in account. A backup is complete only when the encryption key is part of it, and usable only when someone has tried a restore at least once.

n8n is a tool that connects programs into automatic sequences (“workflows”). “Self-hosting” means it runs on a server that you or your service provider set up and maintain, not at the manufacturer. The cost side is covered in the article Cloud or self-hosted.

How many security advisories there are

On the manufacturer’s “Security Advisories” page, 242 published advisories are listed as of 13 November 2026. By the manufacturer’s rating, 22 are critical, 104 high, 114 medium and 2 low. 228 of them were published in 2026. In the ten full months from January to October there were 223, an average of a good 22 a month. They appeared on only 22 days, mostly in batches (on 10 June and on 2 September, 18 on a single day each).

The number alone says little. The title of 106 of the 242 advisories names a single building block (“node”), and 204 name several version lines in which the flaw was fixed. A high number can also mean that a manufacturer discloses its flaws. Whether n8n has more or fewer flaws than other tools cannot be read from it; I have not collected comparison figures.

What the critical advisories say

I read the full text of all 22 critical advisories. According to the wording, 21 of them require a logged-in account, and 18 expressly one with the right to create or change workflows. One example is the flaw CVE-2025-68613 (a CVE number is the standard identifier of a security flaw): expressions that a logged-in user enters in a workflow can run program code on the server. It is fixed from version 1.122.0. As an interim measure the manufacturer names restricting workflow editing to trusted users. The severity is rated differently depending on the source: the entry in the NVD, the US vulnerability database run by NIST, carries two values on a scale of 0 to 10, 9.9 (critical) from GitHub as the reporting body and 8.8 (high) from the NVD itself.

There is one exception: CVE-2026-21858 concerns form-based workflows. An attacker without a login can read files on the server (severity 10.0 out of 10). It affects versions from 1.65.0 up to but not including 1.121.0, and is fixed in 1.121.0. There is no official workaround, only the advice to restrict publicly reachable webhook and form addresses until the update. Webhook addresses are the addresses through which other programs trigger a workflow from outside. The latest critical advisory dates from 13 May 2026, and none has followed up to the retrieval date.

Between January and May 2026 the BSI (the German Federal Office for Information Security) published at least five CERT-Bund warnings on n8n that I have read, all rated “high”. CERT-Bund is the BSI’s reporting point for security warnings. The February warning names several vulnerabilities through which an attacker can run program code. One user reports in the manufacturer’s forum a BSI letter, forwarded by their hoster, that asked them to update. That is an unverified account.

For a small business this means: it needs a fixed rhythm, not haste with every advisory. Three questions decide how fast you act. Is n8n reachable from the internet? Can the flaw be exploited without a login? And who has an account with the right to change workflows?

Who updates

According to the documentation, a new minor version appears in most weeks. For production use the stable version applies, while beta is the newest and may be unstable. As of 13 November 2026, stable was 2.47.7. The documentation advises updating at least once a month, reading the notes on changes and trying the update first on a test instance. Before the update it recommends a complete backup.

With the manufacturer’s cloud service too, the owner of the instance chooses the version and the update rhythm, according to the documentation. The question stays with you there as well.

The following rule is the author’s suggestion, not a requirement of the manufacturer or the BSI:

How to notice a missed backup and other silent failures is described in the article Silent failures: how to tell that a workflow is not running.

The backup and the key

n8n creates a random key at first start and stores it in the .n8n folder. It is used to encrypt credentials before they go into the database. Credentials are the passwords and access keys with which n8n logs in to your mailbox or other services. According to the manufacturer: without the key from the configuration file, or a custom N8N_ENCRYPTION_KEY, a restored database or an encrypted export cannot be decrypted.

The export with n8n export:workflow --backup and n8n export:credentials --backup is therefore not a complete backup. According to the documentation it contains only workflows and credentials. Users and roles, execution history, variables and settings including the key are missing. The export with --decrypted writes credentials in plain text. The manufacturer advises treating that file like the credentials themselves and deleting it after the restore.

According to the documentation, a complete backup consists of the .n8n folder and, if you use PostgreSQL instead of the default SQLite database, the database, backed up with its own tool. The folder stays part of the backup even then, because the key lives there. Added to this are externally stored data and self-installed nodes, where present.

With SQLite, n8n must be stopped before copying, otherwise the copy may be inconsistent. In Docker the folder sits in the volume n8n_data under /home/node/.n8n. A backups/ directory inside the container does not persist, so the files must be placed outside. A restore only works with the matching configuration, that is database access and, if set, a custom key.

Article 32(1) of the GDPR names, as possible measures, the ability to restore data quickly after a technical incident (point (c)) and a process for regularly testing the measures (point (d)). Whether and how that applies to you is for your data protection officer to clarify.

The effort

The cost article in this series assumes 2 hours a month for self-hosting: 1 hour for the update, 0.5 hours to check the backup, 0.5 hours for faults and advisories. These are assumptions, not measured values. With two restore tests of 2 hours a year, that makes 12 × 2 + 2 × 2 = 28 hours a year, a little over 2 hours a month. What matters is that the time is planned and belongs to someone.

Settling it in contracts and in the organisation

If your service provider runs n8n for you, the following belongs in the contract. The licence side is covered in the article n8n licence: what is allowed.

1. Who updates, and within what period after a critical advisory?
2. Who backs up, to where, how often, and how do you verify that the backup runs?
3. Who holds the key? A copy must be with you, not only with the provider.
4. When is the restore tried, and who reports the result?
5. How do you report faults and security incidents to each other, and what happens when the contract ends?

If the provider processes personal data for you in the course of this, Article 28 of the GDPR requires a contract with a defined content (paragraph 3), in writing, including in electronic form (paragraph 9). That includes the provider deleting or returning the data as you choose once the service ends, unless a storage obligation applies (point (g)). Whether that applies to you is for your data protection officer or lawyer to clarify.

In your own business, half a page is enough: the name of the person and the deputy, the table above, the location of the key copy. The deputy has carried out a restore once.

What you can do now

1. Look in your n8n to see which version is running, and compare it with stable in the documentation.
2. Check whether the key is stored apart from the server and whether your management can find it.
3. Name a responsible person and a deputy and adopt the table.
4. Restore the backup once on a test machine and note how long it takes.