Ethical Tech

Leaving Zapier Without Leaving the EU

Zapier is American, and in 2026 that is more than a GDPR question. Putting this much of a practice in US hands has started to look unwise, whatever the compliance paperwork says. Here is what the European alternatives offer, and the catch that decides whether switching changes anything.

31 May 2026 · 6 min read · By Sophie Kazandjian

Zapier is a great tool. The unease is about where it comes from, and the answer to that is messier than swapping one logo for another.

A client's registration list sits in MailerLite. When someone joins a particular group, a row needs to appear in a spreadsheet and a note needs to reach the team. For two years a single Zapier automation did exactly that, set up in about ten minutes, and it never once complained. The only thing wrong with it is the passport.

Zapier is American. San Francisco, hosted on Amazon's infrastructure, certified under the EU-US Data Privacy Framework, the legal scaffolding that lets American companies process European data after the previous arrangement was struck down in court. None of that makes it careless. It makes it foreign, and for a practice that recommends European hosting and privacy-first choices to its clients, foreign is something you have to be able to account for.

There is a second reason, and it is newer. For years the American-ness of a tool was a line in a data register, noted and forgotten. It reads differently in 2026. The arrangement that lets European data sit with American companies depends on a political relationship that no longer feels guaranteed. Concentration is its own exposure, and a practice that has quietly let most of its stack settle with American firms is more dependent on decisions made in Washington than anyone chose to be.

So you go looking for the European Zapier. The first problem is working out what European even means.

What the worry is actually about

Three different things hide inside the phrase "is it European", and they come apart the moment you press on them. There is where the company is registered, where it keeps its servers, and where the data finally sits once the automation has run. People reach for the first because it is the easiest to read off a website, and it tells you the least.

The flow I described ends in Microsoft 365. The spreadsheet lives on OneDrive, the notification goes out through Outlook, and Microsoft is about as American as Zapier. Whatever tool sits in the middle moving data from MailerLite to that spreadsheet, its destination is a US processor. Choosing a European automation tool for that flow changes where one hop runs. It does nothing about where the data ends up.

That does not make provenance pointless. It means provenance buys you something real only when the flow stays inside Europe from start to finish. A MailerLite trigger writing to an EU-hosted database, sending through a European mail provider, with no American app anywhere in the chain. For that, the tool's nationality counts. A flow that ends in Microsoft 365 or Google Workspace is a different case: you are mostly buying a cleaner sentence to say to a client, and that is what you are buying, before you spend a fortnight migrating to get it.

The hosted options first, where someone else runs the software and you log in:

The self-hosted route

If the flow does stay inside Europe, and you want nothing leaving a machine you control, self-hosting is the cleanest answer there is. You rent a small virtual server in a European data centre, four to fifteen euros a month, install the software, and the data never touches anyone else's infrastructure. Three stand out.

n8n is the one most people reach for. Run from Berlin, with a generic HTTP step to fall back on when a service is not covered. It is also the tool that set this whole thing off, because its MailerLite trigger returned an empty payload and quietly dropped every event I sent it. That is not a reason to dismiss it. It is a reminder that "open source and self-hostable" describes who controls the server. It says nothing about whether every part works on the first try. You are the support desk now.

Activepieces sits close behind, with a permissive MIT licence and the interface that feels most like Zapier of any of them. The company is American and its hosted version runs in the US, so the European version of Activepieces is the one you host yourself.

Automatisch is the most clearly European of the three, built in Berlin and licensed under the AGPL. It is also the quickest to get running. The catalogue is small, so it suits a handful of clean flows rather than a sprawling stack.

A word on the lists that circulate. Be wary of any comparison that waves the EU flag without checking the passport. One I was sent recently put a tool called viaSocket in its European column; it is operated from India. The label is cheap to print and easy to get wrong, which is the problem with reading provenance off a marketing page.

Running your own instance asks two things of you that a hosted tool does not. A server you keep patched, and the time to fix it when an update breaks something at an awkward hour. I am comfortable on that ground. I already run things on Cloudflare's network, so the technical floor is not the problem. The upkeep is. It is real, and easy to underestimate when you are three clients deep and a node stops firing on a Friday.

Why I have settled on Make, for now

For client work I need a broad catalogue and low upkeep, with enough flexibility for the awkward jobs that never fit a template. The self-hosted tools beat Make on flexibility and hand me a server to run in exchange. The simplest hosted tools keep upkeep low and run out of room. Make is the one that holds all three at a level I can live with.

The data zone is European, set when I created the account and confirmed in the settings, so the scenarios and everything passing through them run in an EU data centre. The catalogue runs to a couple of thousand apps, MailerLite and Microsoft 365 among them, and the MailerLite trigger hands over the subscriber's details rather than an empty shell. For the flow that broke in n8n, that one difference settles it.

Two things behave differently from Zapier. Make polls on a schedule rather than firing the instant something happens, so a trigger set to every fifteen minutes carries up to a fifteen-minute lag. For a registration notice, fine. The second is quieter and costs money: every scenario consumes operations on its interval whether or not anything new arrived, so a pile of low-traffic automations on short polling intervals will eat your monthly allowance in idle checks. The number to watch as you add scenarios is operations.

Make's parent, Celonis, keeps a US entity and a Data Privacy Framework registration, so there is an American thread in the corporate structure even with European hosting. I promote European hosting, and my most frequent client automation now runs through a tool with an American company in its parentage. The defence is narrow and specific: the data it carries was already going to Microsoft, so a European middle would not move the destination an inch. On a flow that stayed in Europe end to end I would have no such cover, and I would be renting a small server in Frankfurt and patching it myself.

The flexibility is the part I would defend hardest, and it is also where I have been burned. Make was the only tool I got working for a fiddlier job: pulling a client's overdue-invoice report out of Xero and emailing it to them, formatted, on a schedule. None of the simpler tools would touch it. It ran for months. Then Xero moved its API access behind a plan tier above what most of my clients pay for, and the automation went quiet. Make had not broken. The price of reaching Xero's own data had gone up, and the connector in the middle could do nothing about it.

FAQs

Is there a true European alternative to Zapier?

Sort of, and it depends on what you mean by European and on where your data ends up. Make is owned by a German company and lets you choose an EU data zone. n8n and Automatisch are German and can be self-hosted inside the EU. None of that helps if the automation finishes in Microsoft 365 or Google Workspace, because the data still rests with a US processor at the end.

If the flow ends in Microsoft 365, does a European tool in the middle help?

Not much. Provenance buys you something real only when the whole flow stays inside Europe. If the last step writes to OneDrive or sends through Outlook, a European tool in the middle changes one hop and leaves the destination where it was. For those flows you are mostly buying a cleaner sentence to tell a client.

Should I self-host n8n or use Make?

Self-host n8n or Automatisch when the flow stays in Europe end to end, you want nothing leaving a server you control, and you are willing to patch that server. Use Make when you need a broad app catalogue and low upkeep, and you can accept an American thread in its parent company. I run client work on Make for now, for the catalogue and the flexibility.

Back to the Journal