n8n GDPR Compliance Guide: What You Need to Know

You've chosen n8n for workflow automation. Now your compliance officer asks: is it GDPR compliant? The answer is more complex than a yes or no. n8n itself is 'GDPR-neutral' software. Compliance depends 100% on how you deploy it, what data you process, and which third-party services your workflows call. This guide walks you through what that actually means.

Is n8n Itself GDPR Compliant? The Short Answer: No

n8n holds no SOC2, ISO 27001, or HIPAA certifications. It never will, because n8n is neutral software. Compliance is not a feature n8n can certify; it is a responsibility you inherit when you deploy it.

If you use n8n Cloud (the managed service), n8n acts as a data processor and signs a Data Processing Agreement with you. That shifts some burden to them. If you self-host n8n on your own infrastructure, you become both data controller and the entity responsible for processor security. The same code runs either way. The compliance responsibility changes entirely.

Think of it like MySQL. No database is inherently GDPR compliant. What matters is where you run it, how you configure it, what data lands in it, and how you monitor access. n8n is the same. It has been around since 2019, manages 206.3K GitHub stars, and processes thousands of workflows daily. But the compliance burden is yours.

What Personal Data Does n8n Collect by Default?

n8n stores four categories of data that matter for GDPR:

Execution Data: Every time a workflow runs, n8n logs the inputs, outputs, and status of each step. If your workflow moves customer emails or financial records, those live in n8n's database by default. GDPR treats this as personal data if it contains any information about an identifiable person. This is the biggest compliance risk most teams miss.

Telemetry: n8n sends diagnostic events to its servers: which nodes you use, how many workflows run, how long they take. You can disable this, but it is on by default. If telemetry includes user IDs or customer identifiers from your workflow data, it becomes a data transfer to n8n's infrastructure. For EU data, this is a compliance violation unless you have signed a Data Processing Agreement.

Credentials: n8n stores API keys and passwords for third-party services (Slack tokens, AWS keys, etc.). These are encrypted at rest, but they are still "personal data about accounts" under GDPR. If a workflow authenticates as a specific user or service account, that credential is now in n8n's database.

Workflow Definitions and Pinned Data: Your workflow configurations and any data you manually pin to nodes for reference are stored in the database. If a workflow name or pinned data contains personal information, it is GDPR scope.

How to Configure n8n for GDPR Compliance

Configuring n8n for compliance requires four technical steps:

1. Set Execution Data Retention

Find the environment variable EXECUTIONS_DATA_MAX_AGE and set it to 30 (days). This tells n8n to automatically delete execution records older than 30 days. The default is unlimited retention, which violates the GDPR principle of data minimization: keep personal data only as long as you need it. Thirty days is reasonable for compliance and troubleshooting. Adjust upward only if your workflow SLA requires longer auditing.

Also set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none. By default, n8n saves execution logs even when a workflow succeeds. This logs personal data you do not need. Set this to 'none' to keep logs only for failed executions, reducing what you store.

2. Disable Telemetry

Set the environment variable N8N_DIAGNOSTICS_ENABLED=false. This stops n8n from sending diagnostic data to n8n's servers. If your workflows contain any personal data or customer identifiers, this is non-negotiable. You are no longer an EU data controller if your telemetry includes personal data exports to non-EU infrastructure.

3. Encrypt Credentials

Set N8N_ENCRYPTION_KEY to a strong random 32-character string. n8n encrypts credentials at rest by default if this variable is set. Without it, credentials are stored in plain text in the database. This is not optional for compliance. Your security team will demand this.

4. Backup Strategy

When you delete execution data, deletions must propagate to backups. Set up automated backups and verify that your backup retention policy matches your execution data retention policy (30 days in the example above). A deleted execution that still lives in a backup is not actually deleted under GDPR. Your compliance team will ask how you verify this. Have an answer.

What Compliance Responsibilities Are Yours vs n8n's?

GDPR defines two roles: data controller and data processor.

You are the data controller: You decide what data flows through workflows, why you process it, how long you keep it, and who can access it. You own the compliance liability.

n8n is the data processor IF you use n8n Cloud: If you sign up for n8n Cloud's hosted service, n8n agrees to follow your instructions and provides a Data Processing Agreement. You can now reference n8n's security measures in your own compliance documentation. n8n's data centers hold ISO 27001 certifications, not n8n the company, but that still helps your audit.

You ARE the processor (and controller) if you self-host: If you run n8n on your own server, you are responsible for the security of that infrastructure. n8n's code is open-source and well-maintained, but the server it runs on is your responsibility. No DPA exists between you and n8n because n8n is not processing your data; you are.

Third-party integrations are subprocessors: Every time a workflow calls Slack, Stripe, OpenAI, or another API, that service is a subprocessor. You must maintain a list of all subprocessors your workflows use. GDPR Article 28 requires you to document this and get customer consent if you change subprocessors. If one workflow calls OpenAI, Stripe, and Slack, you have three subprocessors to document.

What Audit Trail Must You Maintain to Prove Compliance?

If a regulator or your customers ask: "Show me you are GDPR compliant," you need these documents:

1. Records of Processing (Article 30 GDPR) List every workflow, what data it touches, why it exists, how long you keep data, and who can access it. This is not optional. You cannot claim compliance without this. Create a spreadsheet: workflow name, data inputs, retention period, who can trigger it, subprocessors it calls.

2. Data Processing Agreement with Processors If you use n8n Cloud or a managed hosting provider, you must have a signed DPA. If you self-host, you do not need an external DPA, but you should document your own responsibilities in writing for audit purposes.

3. Access Logs and Audit Trail n8n records workflow execution history by default. You should not rely on this alone. Enable access logs at the infrastructure level: who logged into the server, when, what changes were made. If someone asks "Did anyone access customer data last month?" you must have an answer within hours.

4. Breach Response Procedure GDPR requires you to notify regulators within 72 hours of discovering a data breach. You must have a written procedure: Who discovers breaches? Who calls legal? When do you notify customers? Practice this quarterly. n8n cannot do this for you.

5. Quarterly Compliance Audits Set a calendar reminder to audit every workflow quarterly: Is it still necessary? Is the data retention still correct? Have we added new subprocessors? Document these audits. Regulators expect to see evidence you are actively managing compliance, not just running on initial configuration.

Why Third-Party APIs Break Your GDPR Compliance (Even If n8n Is Perfect)

This is the compliance trap that catches everyone.

You configure n8n perfectly: disable telemetry, set retention to 30 days, encrypt credentials. Then your workflow sends a customer email to Slack or customer records to a US-based analytics API. That is a data transfer to a non-EU controller. The US does not have GDPR equivalent protection. Under GDPR, you now need either:

1. Standard Contractual Clauses (SCCs): A legal agreement with the API provider confirming they will respect EU data protection. Most US APIs (OpenAI, Anthropic, Stripe) now offer SCCs in their terms, but you must explicitly agree to them.

2. A Derogation: A narrow, documented reason why this transfer is necessary and proportionate. "We needed their service" is not a derogation.

3. EU-based alternatives: Use European APIs where possible. This removes the transfer issue entirely.

Here is the critical mistake: Self-hosting n8n does not solve this. A workflow running on a German server that sends customer data to OpenAI (a US company) is still a non-EU transfer. The location of n8n does not matter. The location of the API matters.

If your use case is sensitive (healthcare, financial services, student records), you should audit every API your workflows call and confirm their data protection terms before deploying. One workflow calling a US service without proper SCCs can expose your entire organization to GDPR fines.

Why Managed Hosting Simplifies GDPR Compliance

Self-hosting n8n gives you data control but adds operational burden. You must manage servers, apply security patches, maintain backups, monitor access, and respond to breach incidents. You also remain personally responsible for every aspect of infrastructure security.

Managed n8n hosting shifts this load. A provider like Opsily hosts n8n in EU data centers, handles daily backups, applies patches automatically, and provides a DPA that explicitly covers GDPR compliance. This does not eliminate your responsibility, but it redistributes it.

Here is the practical advantage: Your compliance officer stops worrying about server configuration and focuses on workflow governance (which integrations are allowed, who can deploy, audit trails). Your DevOps team stops managing database maintenance and can focus on business logic.

Managed hosting also ensures you get configuration defaults that align with GDPR. Providers who specialize in EU data residency pre-configure execution retention, disable telemetry, and enable backups in EU regions. Self-hosting requires you to research and implement each of these settings yourself, and mistakes are expensive.

If your team is under 20 people and you are already running other services in the cloud, managed hosting is usually the right choice for GDPR compliance. You trade control for operational simplicity and documented processor liability.

If you self-host, make sure you have actual DevOps capability on your team. A self-hosted n8n running on a server no one fully understands is a compliance disaster waiting to happen.

Frequently Asked Questions

What is n8n's privacy policy?

n8n publishes a privacy policy at n8n.io/privacy covering data collection from their website and n8n Cloud service. The policy states that n8n is "GDPR-neutral" and that compliance depends on deployment. If you self-host, the n8n privacy policy does not apply to your data; your own privacy policy does.

What are the limitations of n8n?

n8n excels at workflow automation but has trade-offs. Workflows run sequentially by default (parallelization requires configuration). Complex conditional logic can become unwieldy at scale. Error handling is basic unless you build custom nodes. It is not a replacement for a custom-built application if you need microsecond latency or complex state management.

Is n8n obsolete now?

No. n8n maintains 206.3K GitHub stars and active development with 25,038 commits. It competes directly with Zapier and Make.com. The workflow automation category is growing, not shrinking. n8n's open-source model gives it advantages in enterprise and compliance-sensitive contexts where users need infrastructure control.

Is n8n losing popularity?

No. Growth in the workflow automation category is strong. n8n's enterprise features (self-hosting, custom nodes, advanced logging) position it well against competitors. Star growth on GitHub has slowed from hyper-growth phase (2021-2023) to steady state, which is normal for a mature project.

Is n8n self-hostable?

Yes. n8n is open-source. You can deploy it on Docker, Kubernetes, or bare metal. Self-hosting is documented but requires DevOps knowledge: setting up databases, SSL certificates, backups, monitoring. Most teams under 50 people should use managed hosting instead.

Is GDPR compliance mandatory in the USA?

No. GDPR is EU law. It applies in the USA only if you process data about EU residents or your company is based in the EU. If your customers are US-only, GDPR does not apply. However, California's CCPA, Virginia's VCDPA, and other state laws now require similar privacy controls.

Does GDPR require a privacy policy?

Yes. GDPR Article 13 requires you to provide a privacy policy to data subjects. It must disclose: what data you collect, why, how long you keep it, who can access it, and data subject rights (access, deletion, portability). A hidden or generic privacy policy is not enough.

The Bottom Line

n8n is GDPR-neutral software that can be run compliantly, but only with configuration, discipline, and ongoing monitoring. You must disable telemetry, set execution retention, encrypt credentials, and audit every third-party API your workflows call. If you self-host, you also own infrastructure security and backup compliance. If you use managed hosting, you reduce operational burden but still retain responsibility for workflow governance.

The decision is not technical; it is operational: Can your team reliably maintain a self-hosted deployment and document compliance quarterly? Or should you invest in managed hosting to eliminate DevOps from the equation? For most founder-led companies under 100 people, managed hosting removes a compliance liability without sacrificing control.

Start with the /hosting/n8n hub to explore options.