n8n has become the default choice for teams that want open-source workflow automation without the data-exfiltration concerns of SaaS platforms. But "self-hosted" alone does not make a deployment GDPR-compliant. Where the data lives, who can access the logs, how credentials are stored, and which subprocessors touch the queue all matter. This guide explains how to deploy n8n in a GDPR-compliant EU configuration, with a practical architecture you can replicate.
What n8n Processes and Why It Matters
A typical n8n workflow moves personal data: CRM records, payment metadata, HR events, customer support tickets, marketing leads. Under GDPR Article 4, your n8n instance is a processor (and often a controller) for every field that passes through it. The execution history, which stores full input and output of each node by default, contains the same data at rest. That makes the executions table one of the most sensitive artefacts in your stack.
EU Hosting Baseline
Start by fixing data residency at the infrastructure layer. Every component of the n8n stack must reside in the EEA:
- n8n main and workers on EU-located cloud servers (Frankfurt or Amsterdam).
- PostgreSQL primary plus standby in a second EU zone.
- Redis queue backend inside the same EU VPC.
- Object storage for binary data and backups in an EU S3-compatible endpoint.
- Monitoring and logging on an EU-based stack, not a non-EU SaaS.
MassiveGRID operates EU data centers in Frankfurt and London that satisfy GDPR residency for both EU and UK subjects. Pairing the deployment with our data sovereignty option keeps support access, monitoring metadata, and backup copies fully within EU jurisdiction.
Execution Data and Retention
By default n8n stores every execution. Under GDPR's data minimisation principle (Article 5.1.c) and storage limitation principle (Article 5.1.e), you should set a retention period that matches actual operational need. Configure the following environment variables:
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168 # 7 days in hours
EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true
EXECUTIONS_DATA_SAVE_DATA_ON_PROGRESS=falseThis keeps error diagnostics for 7 days while discarding successful executions, which are the bulk of stored personal data. For workflows that must keep full history (audit trails, regulated processes), create a separate n8n instance with a dedicated database so retention policies can diverge.
Credential Encryption
n8n encrypts stored credentials with a single symmetric key defined in N8N_ENCRYPTION_KEY. For GDPR Article 32 (security of processing), rotate this key annually and store it in a KMS or HSM located in the EU. Never commit it to a repository, and never log it. When you rotate the key, re-encrypt the credentials table using n8n's built-in migration command.
Network and Access Controls
- Terminate TLS 1.3 at NGINX or Traefik with HSTS, OCSP stapling, and a modern cipher list.
- Require SSO via SAML or OIDC from your corporate IdP; disable local accounts for everyone except break-glass admins.
- Enforce MFA at the IdP layer.
- Restrict the n8n editor UI to a VPN or IP allowlist; only the webhook path needs public exposure.
- Rate limit
/webhook/at the reverse proxy to mitigate enumeration.
Logging and Data Subject Requests
GDPR Article 15 gives data subjects the right to know what you process about them. For n8n that means being able to search executions and workflows for a given email, user ID, or other identifier within 30 days. Ship logs to an EU-based log store (OpenSearch, Loki, or a managed SIEM), and design workflows so that personal identifiers are tagged in a consistent field. That way a DSAR becomes a single query, not a reverse engineering exercise.
Maintain an in-workflow process for Article 17 (right to erasure): when a controller asks you to delete a subject's data, you need to remove it from the database, from execution history, and from any downstream systems that n8n wrote to. Document this runbook and test it quarterly.
Subprocessor Management
Every third party API a workflow calls is a potential subprocessor. Keep an up-to-date register with the vendor name, data categories transmitted, location of processing, and legal transfer mechanism. If a workflow sends personal data to a non-EU vendor, ensure you have SCCs in place and document the transfer impact assessment.
Backups and Disaster Recovery
Encrypt all backups at rest with keys you control. Replicate PostgreSQL to an EU standby using streaming replication with TLS. Store off-site backups in a second EU region, never in a non-EU region. Our disaster recovery services automate replication and provide a tested runbook for regional failover.
Monitoring Without Leaking Data
Observability is a frequent GDPR blind spot. If you export n8n logs to a non-EU SaaS, the personal data in those logs just left the EU. Use an EU-hosted monitoring stack, and redact payloads in the log formatter where possible. See our guide on monitoring n8n with Uptime Kuma for an entirely self-hosted approach.
Compliance Documentation
Maintain these artefacts for auditors:
- Record of Processing Activities (Article 30) covering every workflow category.
- Data Protection Impact Assessment for any workflow processing special-category data.
- Subprocessor register with signed DPAs.
- Encryption key management policy.
- Incident response runbook with 72 hour notification workflow.
Getting Started
Our managed n8n hosting provides a production-ready, EU-resident, GDPR-aligned environment with encrypted backups, SSO-ready configuration, and on-call support. Review our GDPR compliance framework for the full control catalogue, or contact us for a deployment plan tailored to your workflows.
Published by the MassiveGRID team, specialists in GDPR-aligned n8n hosting and European workflow automation.