Cloud vs Self-Hosted Automation for Sensitive Business Data

Short answer: self-hosting changes where the automation engine runs. It does not change where your AI model calls, connected apps or backups send data. Decide by mapping every place the data goes, then check whether a hosted platform's controls cover each place. Self-host only when a specific part of that map must stay on infrastructure you control, and your team can secure and back it up.

For most teams the hosted options come down to three facts:

• Zapier hosts data in the United States only, keeps run history for 29 to 69 days (adjustable to 7–30 days on Enterprise), and says it is not HIPAA compliant and does not sign business associate agreements.
• Make lets each organization choose an EU or US data-center region when it is created. It can stop storing run data in its logs with Keep data confidential.
• n8n Cloud is hosted in the EU. Self-hosted n8n gives you control over storage, but encrypting data at rest becomes your job.

None of these settings makes a workflow compliant by itself. They are inputs to your own assessment.

Map where the data goes

Pick one sensitive workflow and follow a single record through it. Every row below is a place where a copy of the data can exist.

Self-hosting only changes rows 2, 3 and 6, and partly row 7. Rows 1, 4 and 5 depend on how you build the workflow, whatever hosting you choose.

What each hosted platform lets you control

The convenience of hosted run history and the protection of sensitive data pull in opposite directions. Make's Keep data confidential keeps the record of a run but does not retain its data, which also makes failures harder to debug. n8n's redaction is different: it hides inputs and outputs from people viewing executions, but the data stays in the database and in backups, and owners and admins can reveal it. To keep data out of n8n's storage, stop saving those executions. Decide per workflow, not per account.

The model endpoint is usually the biggest gap

A self-hosted workflow that sends a contract to an external AI model still sends the contract to that provider. The same is true of every hosted platform. Check three things for each model call:

• Whose account it uses. Zapier says it has implemented OpenAI's zero data retention feature for OpenAI calls made through its account, and that its subprocessors may not train on customer content. It does not make the same retention statement for every model provider, and AI by Zapier's default Premium model is an Anthropic model, so ask which provider and terms apply to the model your step uses. When you connect your own OpenAI key, your agreement with OpenAI governs instead. On n8n Cloud, nodes set to use Gateway credits send requests through n8n's gateway rather than your own provider account; check those terms or use your own credentials.
• What the provider keeps. Read the provider's retention and training terms for the exact product and account tier you use.
• What you send. Send only the fields the step needs. Often an ID, a category and a short excerpt are enough.

If the data must not leave your network at all, the model has to run inside it too. That is a separate infrastructure decision with its own costs. Self-hosting the orchestrator alone does not achieve it.

When self-hosting actually helps

Self-host n8n when at least one of these is true and the others are covered:

• The workflow must reach systems on a private network that a hosted platform cannot connect to under your security rules.
• Run history, failed runs or backups containing the data must stay on infrastructure you control.
• You need storage, retention and access settings that the hosted plans you can afford do not offer.

The others that must be covered:

• Every destination and model endpoint is acceptable, or also inside your boundary.
• Someone owns the operational work: security hardening, encryption at rest, backups and restore tests, upgrades, and access reviews.

If you cannot staff that work, a hosted platform with tighter settings is usually the safer choice. For the cost side of the same decision, see n8n Cloud vs self-hosted. For how builder skills and operating duties split, see no-code vs low-code vs self-hosted AI workflow automation.

Worked example: an HR onboarding workflow

Everything below is invented. "Example Co" wants to automate new-hire onboarding. Each packet contains a signed offer, a salary figure, a home address and a scan of an identity document. The automation should:

• extract start date and role with AI;
• create accounts in three internal systems;
• post a welcome message to the manager.

Mapping the flow gives these decisions:

Example Co ends up on a hosted plan in its chosen region with payload storage off for successful runs. Failed runs still hold the full record until someone clears them, so it keeps that queue short, restricts who can open it, and records the retention period. It does not need to self-host unless its rules forbid even short-lived copies of the identity scan on a vendor's infrastructure. In that case it would need a self-hosted orchestrator and a model running inside its own infrastructure.

Who should not move sensitive workflows yet

• Teams that have not mapped the data flow. Changing hosting without the map moves the risk instead of removing it.
• Workflows handling health records on Zapier. Zapier says not to automate protected health information with it.
• Self-hosting projects without an operations owner. An unpatched, unbacked-up server holding run data is a larger risk than a well-configured hosted plan.

Before deciding, run the map with your security or privacy lead, and keep the completed table with the workflow's documentation. For pricing differences between the platforms, see AI workflow automation pricing explained.