Is Self-Hosted Automation Better for Privacy and GDPR?
Yes, self-hosted automation is generally better for GDPR than cloud services like Zapier, but it does not make you automatically compliant. With Krom Automation, a WordPress-native workflow plugin, every execution log, credential and piece of personal data processed by a workflow stays inside your own database.
That removes Zapier or Make as a data processor under Article 28 of the GDPR, which is a meaningful reduction in third-party risk. The free plugin covers the core controls; Pro adds incoming webhooks and advanced integrations for teams with more complex pipelines.
Cloud automation platforms route your data through servers you do not control, often in the United States. That matters because Schrems II invalidated the EU-US Privacy Shield in 2020, and any transfer of EU personal data to a US processor requires either Standard Contractual Clauses or another lawful transfer mechanism. Your DPA with Zapier covers this on paper, but the underlying data still travels across the Atlantic and sits in infrastructure you cannot audit.
Self-hosting changes the structure of that risk. Your data stays on your server, in your jurisdiction, in your database.
You can choose an EU hosting provider, apply your own retention rules, and delete execution logs on a schedule that matches your privacy policy. None of that is possible when the data lives in someone else’s SaaS.
Browse the full Krom Automation feature listWhat Changes When You Self-Host Automation
When you use Zapier or Make, those platforms become data processors under GDPR Article 28. You must sign a Data Processing Agreement with them, and they in turn rely on their own subprocessors, adding more links to the chain. Self-hosting removes that processor relationship entirely for the automation layer itself.
With Krom Automation installed on your WordPress site, the workflow engine runs inside your own application. Triggers fire, actions execute, and logs are written, all to your own database. No data leaves your server unless a specific action in the workflow sends it somewhere, such as an HTTP request to a third-party API.
That last point matters. Self-hosting the automation platform does not automatically self-host everything the automation touches.
If a workflow sends a contact’s email address to Mailchimp, Mailchimp is still a processor for that data. The Mailchimp integration documentation describes exactly what fields are transmitted, which is useful when documenting your Records of Processing Activities.
Self-hosting removes the automation platform as a processor. It does not remove the obligation to document every destination that personal data reaches inside your workflows.
Where Your Data Lives With Krom Automation
Krom Automation stores everything in 9 custom database tables inside your WordPress installation. This includes trigger event data, action parameters, execution logs with a full per-step audit trail, and any merge tag values captured at runtime. Your hosting provider is the only infrastructure party involved.
The analytics dashboard shows total executions, active workflows and failed execution counts. That same data is what you would reference in a GDPR audit or a Data Subject Access Request response, because it tells you exactly which workflows touched a given user’s data and when.
If you choose an EU-based hosting provider such as Hetzner, OVHcloud or Scaleway, the entire automation stack, including logs, sits inside the EU. That eliminates the Schrems II transfer question for the automation layer. No SCCs required, no transfer risk to document, no US cloud infrastructure in the processing chain for that component.
The GDPR Obligations Self-Hosting Does NOT Remove
This is the section that most self-hosting guides skip, and it is the one that gets teams into trouble. Self-hosting removes one processor relationship. It does not replace a lawful basis for processing, a retention policy, or a breach response plan.
The obligations that remain regardless of where your automation runs:
- Lawful basis: Every automated action that processes personal data needs a lawful basis under Article 6. “We have a workflow” is not one. Consent, legitimate interest or contract performance must be documented.
- Data Subject Access Requests (DSARs): If a contact requests their data, you must provide everything you hold, including anything captured in automation execution logs. Krom’s per-step audit trail makes this answerable, but you still need a process to handle the request within 30 days.
- Right to erasure: Deleting a contact from your CRM does not automatically purge their data from execution logs. You need a retention policy that covers your workflow history, and you need to enforce it.
- Data Protection Impact Assessments (DPIAs): Automated processing that is likely to result in high risk to individuals requires a DPIA under Article 35. Self-hosting does not change that obligation. If you automate credit scoring, health-related segmentation or systematic profiling, a DPIA is required.
- Breach notification: If your server is compromised and execution logs containing personal data are exposed, you have 72 hours to notify your supervisory authority. Self-hosting means the breach is yours to detect and report.
- Records of Processing Activities (RoPA): Article 30 requires a record of every processing activity, including automated ones. Each workflow that touches personal data should have an entry in your RoPA describing the purpose, the legal basis, the categories of data, and the recipients.
The biggest GDPR mistake with self-hosted automation is believing that moving data to your own server is a compliance strategy. It is a risk reduction step. The governance work still applies.
Does Krom Automation Require Pro for GDPR-Relevant Controls?
The free version of Krom Automation includes the controls most sites actually need for privacy-conscious automation. The execution log with a full per-step audit trail is free. Workflow import and export as portable JSON is free.
The run-once-per-entity setting, which prevents a workflow from processing the same user twice, is free. The workflow simulator for dry-run testing with zero side effects is free, which matters when you are testing a workflow that would otherwise write to a real user’s record.
Pro adds capabilities that become relevant as workflows grow in complexity:
- The incoming webhook receiver with HMAC-SHA256 signature verification and 9 security layers, for receiving data from external systems without exposing a generic endpoint. See the incoming webhook documentation for the signature verification setup.
- The schedule trigger, useful for running automated data retention or cleanup workflows on a daily or weekly cadence. The schedule trigger documentation covers interval options including one-time runs.
- Advanced conditional branching, so a workflow can route differently based on a user’s consent status or data category.
- 25 integrations with forms, CRMs, email platforms and membership plugins, each of which represents a potential data destination that needs to appear in your RoPA.
For most WordPress sites, the free plugin is the right starting point. The free vs Pro comparison lays out exactly which features sit at which tier.
Comparing Cloud Automation to Self-Hosted on the Dimensions That Matter for GDPR
| Dimension | Cloud (Zapier, Make) | Self-Hosted (Krom Automation) |
|---|---|---|
| Where execution logs live | Vendor’s servers, typically US | Your own database |
| Article 28 processor relationship | Required, DPA with vendor needed | None for the automation layer |
| Schrems II transfer risk (automation layer) | Present if vendor uses US infrastructure | Eliminated with EU hosting |
| Subprocessor chain | Vendor plus their subprocessors | Only the services your workflows call |
| Credential storage | Vendor’s encrypted store | Your WordPress database |
| Retention control over logs | Subject to vendor’s retention policy | Fully configurable by you |
| DSAR response for automation data | Requires vendor cooperation | Direct database query, no third party |
| Breach ownership | Shared with vendor | Yours entirely |
| Lawful basis requirement | Still required | Still required |
| DPIA requirement for high-risk processing | Still required | Still required |
The Schrems II Question, Answered Concisely
Schrems II applies to transfers of EU personal data to third countries, specifically where those countries lack an adequacy decision or where the transfer mechanism (such as SCCs) cannot be demonstrated to protect the data in practice. The US falls into a complicated category: the EU-US Data Privacy Framework restores some adequacy coverage, but it has faced legal challenges and its long-term status is uncertain.
When you use a cloud automation platform headquartered in the US, your workflow data, including the personal data of EU contacts, is processed on their infrastructure. Even with SCCs in place, the underlying legal risk is real, especially for organisations subject to regulatory scrutiny.
Self-hosting on EU infrastructure eliminates this transfer entirely for the automation layer. The data never leaves your server, so no transfer mechanism is needed and no adequacy question arises. That is a clean legal position, not just a practical convenience.
What Cloud Automation Genuinely Does Better
Honest trade-offs matter here. Cloud platforms like Zapier connect two external services with no WordPress involvement, which self-hosted WordPress automation cannot do natively. If your workflow connects Salesforce to HubSpot with no WordPress touchpoint, Krom Automation is not the right tool.
Cloud platforms also handle infrastructure. Updates, uptime monitoring, scaling under load, and backup are all the vendor’s problem. Self-hosting shifts that responsibility to you or your hosting provider.
On a shared host with poorly configured server cron, WP-Cron timing can be unreliable. Scheduled automation and delayed actions depend on WordPress Cron firing on schedule, which requires real server cron configuration on low-traffic sites. The delays and scheduling documentation explains how to configure this correctly.
Teams already running hundreds of Zapier workflows should factor in migration cost honestly. Moving existing automations to a new platform takes time, typically 30 minutes to 2 hours per complex workflow depending on how many steps and integrations are involved.
How Cloud Automation Pricing Compares Over Time
| Scenario | Zapier Professional (as of September 2026) | Krom Automation Pro (Standard) |
|---|---|---|
| Cost in year 1, 1 site | ~$240/year (750 tasks/month) | Starts at $69/year (launch pricing) |
| Cost in year 2, 1 site | ~$240/year, recurring | $69/year, or $199 once (lifetime) |
| Cost at 5 sites | ~$240/year per account (no multi-site) | $149/year covers 5 activations |
| Task or execution limits | 750 tasks/month, overage charges apply | No per-execution billing at any tier |
| AI actions | Premium add-on tier required | Included free, bring your own API key |
| Execution data ownership | Vendor’s servers | Your server |
Zapier’s per-task billing model means a high-traffic Black Friday campaign or a sudden registration spike costs more than the monthly plan suggests. How much Zapier can cost during Black Friday is a real calculation worth running before a busy period. Krom Automation has no execution caps at any tier, so a workflow that fires 10,000 times in a day costs the same as one that fires 10 times.
AI Actions and Privacy: What You Need to Know
Krom Automation includes three AI actions in the free version: AI Generate Text, AI Content Moderation, and AI Auto-Tag. These use the API key you supply, and the request goes directly from your server to the AI provider. wpRigel never sees the content, never charges per token, and does not sit in the middle of the request.
The providers supported are OpenAI (GPT-4o Mini, GPT-4o), Google Gemini (Gemini 2.0 Flash, Gemini 2.5 Flash Preview, Gemini 2.5 Pro Preview) and Groq (Llama 3.3 70B, Llama 3.1 8B). Each of these is a data processor for any personal data included in the prompt. If your AI workflow sends a customer’s name or email to an AI API, that provider needs to appear in your RoPA and your DPA list.
If your compliance position requires keeping AI inference entirely on-premise, you would need a locally hosted model, which Krom Automation’s HTTP Request action can reach but which requires separate infrastructure. That is outside the scope of the plugin itself, but the full actions reference covers the HTTP Request action parameters that make external API calls possible.
Bringing your own API key is not the same as keeping data on your server. Every AI action that processes personal data creates a new processor relationship that needs to be documented.
Setting Up Krom Automation for Privacy-Conscious Workflows
Installing Krom Automation takes the same path as any WordPress plugin. The installation documentation covers both the free and Pro setup. Once installed, the first practical step for a privacy-conscious deployment is reviewing which triggers capture personal data and where the corresponding actions send it.
A workflow that fires on User Registered and sends a welcome email stays entirely inside your server if you use the Send Email action. A workflow that fires on the same trigger and adds the user to Mailchimp creates a processor relationship with Mailchimp. The how Krom Automation works documentation explains the trigger-action model in full, which is the right starting point for mapping your processing activities.
For teams using form integrations as the entry point for personal data, the integration documentation for Gravity Forms, Contact Form 7 and WPForms each describe exactly which fields are available as trigger data, making it straightforward to document what personal data enters each workflow.
Also from wpRigel
Pollify is wpRigel’s Gutenberg-native poll, survey and quiz plugin. Polls are built directly inside the block editor as real blocks, with no shortcodes to paste and no separate configuration interface to learn. It is the natural companion if you collect audience feedback alongside automation.
Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K to search anything, jump anywhere in the admin, or run actions without clicking through menus. It is the only WordPress command palette with real WooCommerce order, product and customer management built in.
Our Verdict
Self-hosted automation is genuinely better for GDPR than cloud services on the dimensions that matter most: data residency, processor relationships, credential storage and log retention control. Krom Automation delivers all of those advantages as a WordPress plugin that requires no cloud account, no subscription to a third-party automation service, and no per-execution billing.
Who should act on this: agencies managing client sites in regulated industries, SaaS founders whose user data must stay in the EU, and any team that has looked at their Zapier DPA and felt uncertain about what it actually covers. The free plugin is the right starting point for most sites, and a realistic look at automation costs usually makes the case for switching clear. You can download Krom Automation free from the WordPress.org plugin directory with no trial period and no feature caps.
Who should not switch yet: teams with hundreds of existing Zapier flows connecting external services that have no WordPress component. Migration has a real time cost, and if the automation does not touch WordPress, Krom Automation is not the right fit. Everyone else should run the numbers.
See Krom Automation pricing and compare plansFrequently Asked Questions
Does self-hosting automation make me automatically GDPR-compliant?
No. Self-hosting removes the automation platform as a third-party processor, which is a meaningful reduction in risk.
But you still need a lawful basis for every processing activity, a retention policy covering your execution logs, a process for handling DSARs within 30 days, and a DPIA for any high-risk automated processing. Compliance is a governance question, not an infrastructure one.
Do I still need a Data Processing Agreement if I run automation on my own server?
You do not need a DPA with your automation platform if it is self-hosted, because there is no processor relationship for that layer. You will still need DPAs with any third-party services your workflows send data to, such as email marketing platforms, CRMs or AI providers. Every external destination your workflow reaches is a potential processor.
What happens to personal data in execution logs when I delete a contact?
Deleting a contact from your CRM or WordPress user table does not automatically remove their data from automation execution logs. You need a defined retention policy for your log data and a mechanism to enforce it.
Krom Automation stores logs in your own database, so you control deletion directly. The right approach is to set a log retention period in your privacy policy and run a scheduled workflow or database cleanup to match it.
Do I need a DPIA for automated data processing even if I self-host?
Yes, if the processing is likely to result in high risk to individuals. The DPIA requirement under Article 35 applies to the nature of the processing, not the infrastructure running it. Automated profiling, systematic monitoring of publicly accessible areas, and large-scale processing of special category data all trigger the DPIA obligation regardless of where the automation runs.
If my self-hosted automation runs in the EU, do Schrems II transfer rules still apply?
Not to the automation layer itself. If the automation and your server are both in the EU, no international transfer occurs for that component.
Schrems II transfer rules apply when data moves to a third country, so keeping both the site and the automation engine on EU infrastructure eliminates that obligation for the workflow platform. Any action that sends data to a US-based service creates a transfer that still needs a lawful mechanism.
Can I process EU customer data in automated workflows without consent?
Consent is one lawful basis under Article 6, but it is not the only one. Contract performance, legitimate interest and legal obligation are all valid alternatives depending on the purpose.
What you cannot do is process EU personal data in automated workflows without any documented lawful basis at all. The basis needs to be determined before the workflow runs, not after someone asks.