Self-hosting or n8n Cloud – which is better for data protection?

Self-hosting gives you full control over location and configuration, at the cost of operational effort. The cloud takes the operations off your plate but leaves less influence on the setup. Both can be run in a compliant way. Which fits depends on your requirements, your team and how sensitive the data is.

Where does my data sit when I self-host n8n?

Where your server is. You can deliberately pick a provider with a data center in Germany or the EU, then the workflow data stays in the EU. What matters is that the services n8n passes data on to fit that too.

Is self-hosting alone enough to be GDPR-compliant?

No. Your own server is the basis, but not the whole picture. Otherwise the contracts with host and connected services, a deletion concept for the execution data and clean access are missing. Only the combination makes a setup compliant.

n8n & data protection

Run n8n GDPR-compliant and self-hosted

Q: Do I need a data processing agreement for n8n?

As soon as personal data is processed on your behalf, yes – but not necessarily with n8n itself. When self-hosting you sign the agreement with your hosting provider. With n8n Cloud, n8n is your processor. In both cases each connected tool that receives data needs its own agreement.

Self-hosting on an EU server hands you back control over your data. But the server alone doesn't make a compliant setup. I'll show what matters: data location, the processing agreements, the connected services and how to handle execution data.

Discuss your setupfree intro call, about 15 minutes

EU

TriggerForm / CRM

n8nEU server

HubSpot / DBData stays in the EU

What "n8n GDPR-compliant" actually means

n8n itself is just software, a toolkit for workflows. Whether you use it in a compliant way isn't decided by n8n but by your setup: where the instance runs, who has access, which data goes through the workflows and where it ends up. That's exactly why many people reach for n8n. With the self-hosting variant the instance sits on a server you choose, so control over the data location stays with you.

That's the key difference from many US automation tools, where your data inevitably runs across someone else's servers. With n8n on a German or European server you decide where the processing happens. But the GDPR asks for more than just a good server location. It asks about contracts, clear responsibilities and how you handle the data along its whole path.

This text is practical orientation from a project perspective, not legal advice. For a binding assessment of your specific case, the final word belongs to someone who works in data protection law.

Self-hosting or n8n Cloud

Both paths can be run in a compliant way. They differ mostly in how much control and how much operational effort sit with you.

Self-hostingn8n Cloud

Where the data sitsOn a server you choose – e.g. in Germany or the EUIn the data center of the chosen n8n Cloud plan

Your roleController; the host is your processorController; n8n is your processor

Agreement needed withHosting provider and every connected servicen8n and every connected service

Control over updates and configEntirely yoursWith the provider; you use the supplied environment

Ongoing effortServer, updates and backups are run by you or someone for youThe provider runs it, in exchange for less influence on the setup

If you're still weighing whether n8n is the right tool and how it stacks up against Zapier and Make, the comparison n8n vs. Zapier vs. Make helps. How I set up and run n8n in practice is on the n8n agency page.

Who you need a processing agreement with

A data processing agreement defines that someone processes personal data on your behalf and sticks to your instructions while doing so. With n8n the question isn't "do I need an agreement with n8n" but "who is actually processing on my behalf here". That depends on how you run n8n.

When self-hosting

You are the controller. You sign the agreement with your hosting provider, because the data sits on their infrastructure. n8n as software isn't in between. On top of that comes an agreement with every service your workflows hand data to.

With n8n Cloud

Here n8n runs the instance for you and becomes your processor. So you sign the agreement with n8n. And again: for every connected tool that receives data, a separate agreement.

The point many underestimate: the connected services count. A workflow that distributes contacts from a form to HubSpot, an email tool and a database touches three processors. Most uncertainty around this comes down to exactly that question – who the agreement even has to be signed with.

What to check before you go live

Six points I go through on every n8n setup with a data protection angle, before the first workflow goes live.

Decide where the data sits

Which server runs n8n and where is it located? With self-hosting you choose that yourself, for example a German or EU provider. With n8n Cloud the plan decides the region.

Clarify the roles

When self-hosting, are you the controller and the host your processor? Or, with the cloud variant, is n8n itself your processor? That determines who you need a data processing agreement with.

Put the agreements in place

With every service that processes personal data on your behalf: the hosting provider, n8n in the cloud variant, and every connected tool that data flows into.

Check the connected services

A workflow is only as privacy-friendly as its endpoints. If n8n sends data to a US tool without suitable safeguards, the EU server doesn't help.

Encryption and access

Encryption in transit and ideally on the server, separate accounts instead of one shared admin login, two-factor authentication for the n8n interface.

Logs and execution data

n8n stores executions along with the data that passed through them. That is often personal data. Define how long it is kept and when it is deleted automatically.

Three assumptions that go wrong in practice

"Self-hosted means automatically GDPR-compliant"

Your own server is the foundation, not the finish line. A setup becomes compliant only when the contracts, access, retention and the connected tools are right too. A US service at the end of the workflow can tip the whole chain over again.

Execution data gets forgotten

Many people set up workflows and never think about the stored executions. That's where full names, email addresses or order data often sit. Without a retention rule it piles up indefinitely.

The agreement with the host is missing

When self-hosting, the server provider is your processor. Even though the instance runs in your own account, it needs a contract. This gets overlooked easily, because n8n itself never reminds you.

When the self-hosting route pays off

Your workflows process personal data and you want to keep it in the EU.
Your industry or your clients ask for clear statements on the data location.
You don't want every automation step running across a US provider's servers.
You need control over retention and deletion of the execution data.

If your workflows barely touch personal data and running your own server would be effort without payoff, the cloud variant can be the more pragmatic route. We go through that honestly in the call too.

Common questions on n8n and the GDPR

n8n is a tool. Whether the use is GDPR-compliant depends on how and where you run it and which data goes through the workflows. Self-hosting on an EU server gives you control over the data location; the rest of the compliance comes from contracts, access, retention and the connected services.

Set up n8n cleanly and data-protection-friendly

Tell me briefly which data should run through your workflows and what your current setup looks like. I'll come back with an honest take on whether self-hosting or cloud fits and what to watch out for.

Free intro call, about 15 minutes
A read on data location, processing agreements and connected services
n8n self-hosted on an EU server, cleanly configured