Is n8n GDPR compliant? Self-hosted n8n and data protection

A client's data protection officer sent me a 40-question vendor questionnaire last spring, and question one was "Is n8n GDPR compliant?" The truthful reply took a paragraph. n8n is software; the regulation applies to processing, so what can be compliant or non-compliant is a deployment plus the organisation running it. If you use n8n Cloud, n8n GmbH, a company based in Berlin, is your processor, publishes a data processing agreement at n8n.io/legal and states that the platform and its data are hosted in the European Union. If you self-host, n8n GmbH doesn't process your data at all (with one telemetry caveat covered below), and every obligation that a DPA would have pushed onto them stays with you and your hosting provider. Self-hosting makes the paperwork shorter and it doesn't make it optional. The questionnaire got answered, the workflow went live and the notes I made while filling it in became this article.

What personal data an n8n instance holds

Before any of the legal articles make sense you need the inventory, and an automation server holds more than people expect. Execution data is the big one: by default n8n saves the input and output of every node for every run, successful or failed, so a workflow that syncs CRM contacts keeps a copy of each contact's record in the execution_data table for as long as the retention settings allow. Binary data (attachments, exported CSVs, images) sits in the binary data folder or in the database depending on N8N_DEFAULT_BINARY_DATA_MODE. Credentials are encrypted, but the OAuth token for a Google account is still personal data about the account's owner. User accounts carry names and emails. Workflow definitions can contain pinned data, which is a snapshot of real records that someone pinned during testing and forgot about; I found a customer's full address in a pinned Webhook node output once, eighteen months after the test. And then the logs: at N8N_LOG_LEVEL=debug n8n can write request details to stdout, which Docker keeps in its json-file log driver until rotation.

Data tables, the built-in tabular storage, are the newest place to look. If a workflow writes leads into one, that table is a personal data store with no retention policy unless you build one.

Records of processing under Article 30

Article 30 asks controllers to keep a record of processing activities listing purposes, categories of data subjects and data, recipients, transfers outside the EU, envisaged erasure deadlines and a description of security measures. Paragraph 5 exempts organisations under 250 people, except when the processing is likely to create a risk, involves special categories or is not occasional. A workflow that runs every fifteen minutes is the definition of not occasional, so in practice the exemption rarely applies to an n8n instance doing real work.

What I do is one line per published workflow in a spreadsheet: workflow name and ID, purpose, data categories, every node that sends data to a third party (those are the recipients), the retention setting for that workflow and the date it was last reviewed. Tagging workflows in n8n with the data category they touch makes the review pass faster, and n8n export:workflow --all once a quarter gives you the node list to check the recipients column against.

Retention and data minimisation with execution settings

Storage limitation is the principle that data shouldn't be kept longer than its purpose needs, and n8n's execution settings are the control. These are the defaults in 2.x and what I change:

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_PROGRESS=false
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000

Out of the box n8n saves everything and prunes after 336 hours, which is 14 days. SAVE_ON_SUCCESS=none is the single biggest reduction: a successful run keeps its status and timing and drops the payloads, so the sync that ran fine at 03:00 leaves no copy of the contacts behind. Failed runs keep their data so you can debug them, and seven days is enough for that on my instance. The guide to pruning n8n executions goes through the soft and hard delete cycle and why SQLite doesn't give the space back, which matters here because a pruned row on SQLite is still on disk until a VACUUM runs. Workflows can override these in their own settings, which is how a payment workflow keeps errors for 30 days while a newsletter sync keeps nothing. Binary data attached to an execution is removed with it.

Enterprise instances also have execution data redaction, per workflow from 2.16.0 and enforceable instance-wide from 2.26.0, which replaces node input and output with a placeholder while keeping status and timing. It has documented gaps, Code node console.log output isn't redacted and webhook response bodies aren't either, so it's a layer on top of retention rather than a replacement for it. For everyone else, short retention is the tool.

Telemetry: the one thing self-hosting still sends to n8n

A self-hosted instance sends diagnostic events to n8n by default. Per n8n's privacy page that includes the n8n version, an anonymous instance ID, OS and hardware details, the graph of each workflow (node types and how they connect, without parameters other than resource and operation), execution counts every six hours, UI usage and the error messages of failed executions without payloads. It excludes credentials, node parameters and execution data, and the page is explicit that the only personally identifiable item collected is the IP address. Two variables switch it off:

N8N_DIAGNOSTICS_ENABLED=false
N8N_VERSION_NOTIFICATIONS_ENABLED=false

The second one only stops the version check. With both off, the vendor questionnaire's "does the software vendor recieve any data" question gets a clean no. A Business or Enterprise licence changes that, since the licence server contacts n8n to report usage, and that arrangement is covered by the licence terms you sign rather than by the community privacy page.

Third-party nodes and the subprocessor list you now own

Every node that sends personal data somewhere makes that somewhere a recipient, and if the recipient acts on your instructions it's a processor under Article 28, which requires a contract covering subject matter, duration, nature and purpose of processing, data types and the parties' obligations. On n8n Cloud, n8n's own subprocessors are n8n's problem. On a self-hosted instance the OpenAI node, the Slack node, the Google Sheets node and the HTTP Request node pointed at some SaaS API each add a name to a list that you maintain. Most of those companies publish a DPA you accept by clicking; the point is to have clicked it and to know which workflows send what.

The AI nodes deserve a separate look. Running Ollama on the same server or on a GPU box on the private network keeps the prompt data at home, and the n8n AI integration on a VPS guide covers how to point the chat model nodes at a local endpoint. Sending support tickets to a hosted model provider instead is a transfer to a processor, often outside the EU, and that provider goes on the list.

Hosting location and EU data residency

The server's physical location decides the transfer question. LumaDock runs availability zones in Frankfurt, Paris, Amsterdam, Helsinki, Bucharest, Warsaw and Madrid, all inside the EU, plus London and New York, which are not; the list of LumaDock data centres shows what's in each location, and the n8n VPS template can be deployed into any of them with Docker and Caddy preconfigured. The UK has an adequacy decision from the European Commission, so data in London isn't a restricted transfer, but a strict client can still ask why it isn't in the EU and it's easier to have no answer to give. New York needs a transfer mechanism: standard contractual clauses with the host or a host certified under the EU-US Data Privacy Framework. If you have a choice, and for EU personal data you usually do, pick an EU zone and write the city into the record of processing.

The hosting provider is a processor too, at the infrastructure level. Article 28(3) wants a contract, so get the provider's DPA signed or accepted before production data lands on the disk, and file it with the record. Ask what certifications the facility holds; Tier III+ says something about availability and ISO 27001 says something about the security programme, and both are worth having in the questionnaire folder even though neither one is GDPR compliance by itself.

Security of processing under Article 32

Article 32 lists encryption and pseudonymisation, ongoing confidentiality and availability, the ability to restore data after an incident and a process for regularly testing the measures. Mapped onto an n8n VPS that's four concrete things, and the n8n security best practices list has the instance-level settings behind each of them. Credentials at rest are encrypted with N8N_ENCRYPTION_KEY, and the custody of that key, the backup of it and the official rotation feature are in the article on rotating the n8n encryption key; disk encryption underneath is the host's or your own LUKS setup. TLS at the reverse proxy covers data in transit for both the editor and every inbound webhook. Access control is the owner account and invited users with 2FA switched on, plus 2FA enforcement across all users if you hold a Business licence. Restoration is a tested backup, and "regularly testing" maps onto a quarterly restore drill plus a monthly n8n audit run whose output you keep as evidence.

Pseudonymisation is the one measure n8n gives you little help with. If a workflow only needs a customer ID to do its job, pass the ID and look the record up at the far end, so the execution data never holds the name. A Set node that strips fields before the HTTP Request node is a five-minute change with a large effect on what your executions table contains.

Breach notification within 72 hours

Article 33 requires notifying the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach that risks people's rights. For an n8n instance the realistic scenarios are a leaked database dump together with the encryption key, an editor account taken over and used to add a node that exports data and a workflow bug that posted records to the wrong channel for a week. The first needs the backup and key hygiene above. The second is why 2FA and short-lived API keys matter. The third is the common one, and it's caught by someone reading execution logs, which argues for keeping error executions around long enough to notice.

Evidence is the hard part on a community instance. Log streaming to a SIEM is an Enterprise feature, so what you have is N8N_LOG_OUTPUT=file with N8N_LOG_FORMAT=json shipped off the box by whatever collector you already run, the reverse proxy's access log and the executions table itself. I don't have a good answer for reconstructing who edited a workflow on a community instance beyond the 24-hour workflow history, and I'd be interested to hear from anyone who does.

Data subject requests: access and erasure

The right of access in Article 15 and erasure in Article 17 both arrive as "what do you hold about [email protected] and delete it". n8n has no search across execution payloads by email, and with the retention settings above the honest answer for executions is that nothing older than seven days exists. For the systems n8n writes into, the practical tool is a workflow: a Form Trigger or Webhook that takes an email, calls the delete or export endpoint of each system in the record of processing and posts a summary to the ticket. Set that workflow's own execution saving to none for successes, since otherwise the erasure workflow's execution data would contain the very email it was asked to erase.

Backups are the awkward case. Dumps taken before an erasure still contain the record, and the accepted position is to document the backup retention period, let the copies age out on schedule and make sure a restore is followed by re-running pending erasures. Keep the dump retention short enough that you can say the number out loud in a meeting without wincing; mine is 30 days.