That distinction matters because workflow automation is unusually powerful infrastructure. An n8n workflow can receive a webhook, read a database, transform a document, call an external API, and notify staff—all using credentials with access to real systems. Where n8n runs is important, but it is only one part of the privacy and security boundary.
What self-hosting actually changes
n8n supports self-hosting on infrastructure controlled by the operator, including on-premises systems and private-cloud deployments. Its documented deployment choices include Docker Compose, a one-line setup method, and other approaches. Docker Compose is described as the production-oriented option.
A self-hosted instance is more than a different account tier. The operator determines where the service runs, who administers the host, and how it is connected to the rest of the environment. For a business with internal databases, line-of-business software, or sensitive operations, that can reduce the number of parties directly operating the automation platform itself.
For WindowsForum readers, the benefit is practical rather than ideological. A workflow might react to an event from an internal application, transform the information, write a result to another internal system, and alert a team. Hosting the automation engine within infrastructure your team manages can make its network placement and administrative boundary clearer. It may also fit existing firewall, identity, monitoring, and recovery practices.
Self-hosting does not, however, make a deployment automatically private, secure, or resilient. It changes who is accountable for those results. n8n’s own comparison says self-hosted users must provide and manage the infrastructure, and that maintenance is their responsibility.
A bounded Windows deployment note
Windows users should be careful not to mistake an old local-installation tutorial for a production deployment plan. n8n documents direct npm installation as suitable for local development or testing, but says that npm installation is deprecated from n8n 3.0.
For the one-line setup method, n8n requires Docker on Linux or macOS, or Windows Subsystem for Linux on Windows. In other words, it is not a direct native-Windows npm production route. For a service expected to carry business workflows, Docker Compose is the documented production-oriented path; a successful local experiment should not be treated as evidence that the eventual deployment has a sound update, backup, access, and recovery design.
Before making an instance a dependency for real work, decide where it will run, how it will be updated, which people can administer it, how restores will be tested, and what the fallback is when the host or a connected service is unavailable. Those choices will matter longer than the initial setup command.
“Your server” does not mean all workflow data stays local
The most important privacy boundary is often the workflow design, not simply the location of the n8n server.
n8n states that any workflow node can send execution data to an external system. A workflow that calls a SaaS application, AI service, payment provider, messaging platform, or web API can send data to that destination. If it forwards customer details, document contents, support messages, or inventory information to an external API, self-hosting n8n does not prevent that transfer.
This is not a peculiarity of n8n. It is a basic characteristic of integration software. It does mean that a useful privacy assessment needs to follow data through the complete workflow: its triggers, nodes, credentials, storage, and destinations. Stopping the review at the server hosting the workflow engine creates a false sense of assurance.
A practical review of a proposed workflow should ask:
- What enters through a webhook, form, database, file, or application connection?
- What information is retained in the n8n environment?
- Which nodes send information outside the organization’s network?
- What credentials authorize those destinations?
- Who can edit the workflow or view its executions?
The answers may show that a workflow is well suited to controlled infrastructure. They may instead show that its greatest privacy exposure is a connected third-party service, not the n8n host.
Telemetry requires a separate decision
A self-hosted n8n instance communicates with n8n for telemetry by default unless the operator opts out. Most telemetry is event-driven, while workflow-execution counts and an instance pulse are sent every six hours.
The technical privacy documentation says this collection does not include credential information or execution data. It describes system and instance information including the operating system, RAM, CPU count, an anonymous instance identifier, and IP address.
The legal privacy policy describes self-hosted Usage Data in different terms and with broader categories. Unless the operator opts out, those categories include user identifiers, account settings, user events, workflow usage metrics, and enabled integrations. The technical documentation and legal policy therefore describe different scopes and categories of data. Neither description supports the simplistic claim that self-hosting means no information leaves the instance, but the supplied material also does not justify a definitive statement about precisely what is transmitted in every configuration.
For a team with strict data-handling requirements, telemetry should be an explicit deployment decision. Review the relevant setting, decide whether an opt-out is appropriate, and record the choice. Do not rely solely on the physical or virtual location of the server.
Community edition is free, but not feature-identical
The self-hosted Community edition can be used indefinitely without a time limit. That makes it a legitimate option for individuals, labs, and smaller teams that want automation without a recurring platform subscription.
Free does not mean every self-hosted feature is included. Documented Community-edition exclusions include custom variables, environments, external secrets, external binary storage, single sign-on, projects, workflow and credential sharing, and Git version control.
A single technically confident administrator may find those omissions unimportant. A team may not. Centralized secrets, access management, separate environments, shared credentials, and version-control practices become operational requirements when several people build and maintain automations.
The right question is not merely whether n8n can run without a subscription. It is whether the chosen edition supports the way the organization needs to govern, maintain, and collaborate on workflows. Feature availability can change, so a purchasing or architecture decision should be checked against the current edition details.
Privacy controls are not access controls
n8n offers execution-data redaction on Enterprise Self-hosted and Enterprise Cloud plans. This can limit what users see in the execution viewer, which can be useful when logs contain sensitive values.
Its boundaries are just as important as its benefit. Redaction does not encrypt or alter data in the database. It does not restrict data moving from one workflow node to another. It does not change outbound requests to external services, webhook responses, or outbound authentication headers.
Redaction is therefore a viewer-focused control, not a complete data-protection system. It may reduce exposure in the interface, but it cannot compensate for an overly permissive workflow, broadly shared administrative access, a compromised database, or an external transmission that should never have been designed into the workflow.
A sound automation design needs distinct answers for who can view logs, who can edit workflows, who can use or retrieve credentials, where records are stored, and where data is permitted to travel.
Patching is part of the self-hosting bargain
The strongest argument against casual self-hosting is not that it lacks value. It is that an unattended automation server can become a security liability.
A n8n security advisory disclosed a critical issue affecting self-hosted versions 1.65 through 1.120.4 under specific form-workflow conditions. In those affected configurations, an unauthenticated remote attacker could expose system information. The issue was fixed in version 1.121.0, and affected operators were advised to update promptly.
Independent reporting that cited Shadowserver data recorded 59,559 internet-connected instances vulnerable to that flaw on January 11, 2026. That is explicitly a historical observation, not a current exposure count. It also does not show that current n8n releases are vulnerable: the advisory concerned particular versions and conditions, and a fixed release was available.
The lesson is not that every self-hosted n8n installation is unsafe. The lesson is that a self-hosted service needs a credible process for tracking versions and applying updates. n8n’s security audit can flag concerns including unprotected webhooks, missing security settings, outdated instances, risky built-in nodes, community or custom nodes, and issues involving credentials, databases, and file-system use.
A reasonable baseline is to keep the instance current, minimize unnecessary public forms and webhooks, limit workflow-editing access, review installed nodes, retain the recovery material needed for the environment, and maintain tested backups. These are ordinary service-management responsibilities, but their importance rises when one platform can connect many systems using powerful credentials.
Cloud versus self-hosted: the actual operational trade
n8n documents a clear division of responsibility: self-hosted users provide and manage infrastructure and its maintenance, while n8n Cloud handles hosting, updates, and scaling. That can be a material advantage for a team without the capacity to operate a workflow service.
It should not be read more broadly than the documented comparison. Cloud handling hosting, updates, and scaling does not by itself mean that it assumes an organization’s backup policy, workflow access governance, connected-service credential practices, data-handling obligations, or incident-response duties. Those remain matters an organization must define and manage according to its own requirements and arrangements.
Self-hosting is a strong fit when there is a clear reason to control the automation deployment and the operator can support it over time: a technically capable individual, a team with established infrastructure practices, or an organization that needs the service within a controlled network boundary. It is less compelling when the sole objective is avoiding a subscription and nobody owns maintenance, recovery, access decisions, and security response.
The useful conclusion is neither “self-hosting keeps everything private” nor “managed cloud is always better.” Self-hosting can materially increase control over where n8n runs and who operates that service. Its privacy outcome still depends on telemetry choices and workflow destinations; its security outcome depends on patching, configuration, and operational discipline. Treat it as an infrastructure decision rather than merely a free alternative, and the trade-offs become much easier to judge.