Workflow Management
n8n
EU-Made Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by n8n GmbH · n8n.io
Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
n8n at a glance
- Vendor
- n8n GmbH
- Headquarters
- Not stated on the vendor’s pages as of 13 Oct 2026
- Data hosting
- Not stated on the vendor’s pages as of 13 Oct 2026
- Free plan
- Not stated on the vendor’s pages as of 13 Oct 2026
- Starting price
- “Starter Build and run your first workflows and agents. 20€ /mo, billed annually 2.5k workflow executions with unlimited steps Start free tri...” (vendor’s words) source, captured 1 Oct 2026
- Panel verdict
- The AI panel rates n8n 3/5, the mean of 6 judges. n8n is a fair-code workflow automation platform from n8n GmbH of Berlin, with a self-hosted edition next to a managed cloud. how scores are made
- As of
- Vendor pages captured 1 Oct 2026 to 13 Oct 2026; evaluated by the panel 15 Oct 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
n8n is a fair-code workflow automation platform from n8n GmbH of Berlin, with a self-hosted edition next to a managed cloud. The strongest scores come on hosting and portability, clustering at 7-8: the engine deploys with Docker, on-premise and air-gapped if needed, the source code is on GitHub, and workflow definitions export from the cloud and import into self-hosted. Run reliability and governance and audit cluster at 6-7, resting on published execution limits (log retention of 7 days to unlimited, concurrency from 5 to 200+), reusable error workflows, and SAML and LDAP single sign-on with an encrypted credential store. The weakest scores are sovereignty at 3-4, where we found no public information on where cloud workflows execute or on any subprocessor list, and pricing transparency, where the judges genuinely split across a 1-to-4 range: the head of IT credited the published per-tier allowances, while the data protection officer scored 1 because no tier carries a price figure, so no monthly cost can be computed from public pages.
Speaks for it
- A self-hosted edition deploys with Docker, on-premise and air-gapped if needed, with the source code on GitHub
- Workflow definitions export from the cloud dashboard and import into a self-hosted instance, with Git version control on the Business plan
- Execution limits are published per plan — run duration of 5 to 40 minutes by tier, log retention from 7 days to unlimited, concurrency from 5 to 200+
- A dedicated error workflow emails a machine-readable JSON error, and single steps can be re-run without re-running the whole workflow
- SAML and LDAP single sign-on, admin roles, an encrypted credential store, external secret stores and enforced two-factor authentication are listed
Held against it
- The captured pricing pages publish plan contents without any monetary figure, so a monthly cost is not computable from them
- The captured pages give different figures for the integration count — "over 500 integrations", 772 listed apps, and "1000+ apps and services" as the generic HTTP Request node's reach
- We found no public information on cloud execution location, data residency or any subprocessor list, including for the AI model providers behind AI steps
- Migration from cloud to self-hosted is documented as manual only, and credentials cannot be exported from the cloud
- We found no public information on automatic retries with back-off, a public status page or an uptime commitment
Best for
- You want to run the automation engine on your own servers, air-gapped if needed, and keep workflow definitions in Git
- Your team needs to reach systems behind the firewall through a documented HTTP Request node, inbound webhooks and a public API
- You want published execution limits, single-step re-runs and reusable error workflows for operating processes around the clock
- You need SAML or LDAP single sign-on and an encrypted credential store before a department ships automation
Avoid if
- You must verify data residency and a subprocessor list, including where AI model calls are processed, before signing
- You need to compute your monthly cost from published prices rather than through sales-assisted procurement
- You depend on an automated, two-way path between cloud and self-hosted with exportable credentials
- You need approvals routed to platform roles or substitutes rather than a named reviewer email or a ClickUp assignee
The scores
| Criterion | Panel median |
|---|---|
| Process design, forms & approvals | 2.5 of 5 |
| Connectors, API & on-premise reach | 3 of 5 |
| Execution, error handling & monitoring | 3.5 of 5 |
| Governance, credentials & audit trail | 3.5 of 5 |
| Hosting options & portability | 4 of 5 |
| European sovereignty | 1.5 of 5 |
| Pricing transparency | 1.5 of 5 |
Process design, forms & approvals
Show reasoningHide reasoning
How this is scored
Modelling the process people take part in: a visual designer or BPMN, forms, approval steps with roles and substitutes, deadlines and escalation, and versioning of a process that is already running — judged on whether a business owner can change a process without breaking the instances in flight.
0 — Linear trigger-action chains only; no human steps, no forms and no statement on approvals or roles.
3 — A visual builder with branching and a simple approval step, but approvers are named individuals rather than roles, there are no deadlines or escalation, and changing a process has no versioning.
5 — A visual designer with conditions and parallel paths, built-in forms, approval steps assigned to roles or groups, deadlines with reminders, and versions of a process kept with the running instances on their original version.
8 — BPMN 2.0 modelling or an equivalent documented notation, substitutes and escalation chains, multi-stage approvals with four-eyes rules, forms in German with validation and file upload, a task inbox for participants, and a test or simulation mode before publishing.
10 — The process is a governed asset: version history with diff and rollback, migration of running instances to a new version documented, process analytics on cycle time and bottlenecks per step, and the design documented well enough that a business team can maintain it without the vendor.
The Process Owner
The approval patterns I can see are assembled from templates — a Gmail send-and-wait to an approver, and a ClickUp task with configurable poll interval, max attempts, a reminder limit and a timeout outcome — so deadlines, reminders and escalation-on-timeout do exist, and role routing is built from an employee data table. Git version control, a dev and production environment, workflow history and diff are evidenced on the pricing pages. I found no public information on substitutes for an approver on holiday, on built-in forms rather than external Google Forms, or on whether editing a process leaves the requests already in flight on their original version. 1 2 6 7 2 12
The Integration Engineer
Visual building with Switch-node branching, code steps and wait-for-response approvals via Gmail or ClickUp are evidenced, with poll interval, max attempts and reminder threshold configurable to an approval SLA plus timeout handling. Approvals go to named reviewer emails rather than roles, and we found no public information on a native form builder, a participant task inbox, or running instances staying on their original version after a change — workflow history and Git versioning appear only on higher plans. 1 2 6 7 2 12
The Operations Analyst
Visual building with switch-node branching and even parallel branches shows up in the published templates, and approvals are genuinely engineered — configurable polling with poll interval and max attempts, reminders, timeouts, and approve/revision/reject outcomes, plus Git version control and workflow history for changes. But the forms in the examples are external Google Forms, approvers are named individuals reached by Gmail or a ClickUp task, and we found no public information on role- or substitute-based approval assignment or a participant task inbox. 1 2 6 7 12
The Head of IT
Visual building with switch-node branching, human approval steps delivered through Gmail or ClickUp, and configurable poll, timeout and reminder settings for an approval SLA are evidenced, and the Business plan adds Git version control, workflow diff and workflow history for change control. The documented approvals route to named reviewer emails rather than platform roles, and we found no public information on built-in forms, a participant task inbox, or whether running instances stay on their original version when a process changes. 1 2 6 7 2
The Data Protection Officer
Human-in-the-loop approvals are real and SLA-governed — captured templates poll an approval task until approved, revision, rejection or timeout, with configurable reminder thresholds, and route actions by role through switch nodes against an employee data table. But approvals travel to a configured reviewer mailbox or a ClickUp assignee rather than to roles or groups inside the tool, the only form shown is an external Google Form, and we found no public information on a documented notation, substitutes, or how a new version treats instances already running. Git version control and workflow diff exist, on the Business plan. 1 6 7 2 12
The Skeptic
Approvals exist, but they are improvised through a Gmail send-and-wait or a ClickUp task polled until approved, revision, rejection or timeout — the approver is whatever email address or ClickUp assignee you configure, with configurable poll interval, max attempts and reminder threshold standing in for real deadline and escalation handling. The form in the showcased process is a Google Form, and role routing is done with switch nodes reading a data table rather than platform roles or substitutes. Higher tiers add workflow history and Git version control, but we found no public information on running instances staying on their original version when a process changes, or on a task inbox for participants. 2 6 7 12
Connectors, API & on-premise reach
Show reasoningHide reasoning
How this is scored
Reaching the systems a European company actually runs: maintained connectors judged by name rather than count, a generic HTTP and webhook step, custom connectors, and a way to reach systems behind the firewall without opening it.
0 — No connectors beyond email, and no API or webhook step.
3 — A large connector count on a logo wall, with no statement of which actions each supports or who maintains them, and no generic HTTP step.
5 — Named connectors with their triggers and actions documented, including Microsoft 365 and at least one ERP or accounting system common in DACH (e.g. SAP, DATEV, Microsoft Dynamics), a generic HTTP/REST step, inbound webhooks, and a documented API to start and query workflows.
8 — Custom connectors buildable from an OpenAPI description or code, an on-premise agent or self-hosted runner reaching internal databases and file shares, SOAP and database steps, OAuth handled per connection, and connector maintenance ownership (vendor, partner or community) stated.
10 — Integration is engineered: a versioned public API with a deprecation policy, connector changelogs, rate limits per connector published, event-driven triggers rather than polling where the source allows it, and the vendor maintaining the German-market connectors (DATEV, SAP, ELO or d.velop) itself.
The Process Owner
Named connectors are documented — Google Sheets, Gmail, Microsoft Excel 365, Postgres and MySQL among them — alongside a documented HTTP Request node, inbound webhooks, a public REST API to list workflows and credentials, and JavaScript or Python code plus self-hosted custom nodes for everything else; the self-hosted edition itself runs inside our infrastructure, which reaches internal databases. I found no public information on SAP, DATEV or any other ERP common in DACH, on SOAP steps, or on who maintains each connector. 1 2 9 13 2 8 9
The Integration Engineer
The generic HTTP Request node with its own docs and examples, an inbound Webhook node, JavaScript and Python code steps, and custom nodes on self-hosted cover the long tail, with a documented REST API behind an API-key header plus CLI control, and the whole engine runs on your own infrastructure so Postgres and MySQL are reachable without a firewall hole. The captured integration pages give different counts (500+, 772, 799) and popular app names without per-connector action lists, and we found no public information on DATEV, SAP or Dynamics connectors, connector maintenance ownership, or per-connection OAuth. 1 8 9 13 1 2
The Operations Analyst
A documented HTTP Request node and webhook node, a public API exposing workflows and credentials, custom nodes in the self-hosted edition, and the whole engine deployable on-prem beside named Postgres and MySQL connectors cover most of what must reach behind the firewall. We found no public information on SAP, DATEV or any DACH ERP connector, on connector maintenance ownership, or on per-connection OAuth handling, which keeps it a notch short of the top. 1 9 13 2 9
The Head of IT
The HTTP Request node with docs and examples, a documented Webhook node, and a public API exposing workflow and credential endpoints give generic reach, and a self-hosted edition with custom nodes in JavaScript or Python plus Postgres and MySQL nodes can talk to internal systems. We found no public information on connectors for DACH ERP or accounting systems such as SAP or DATEV, on SOAP steps, on per-connector trigger and action documentation, or on who maintains each integration. 1 8 9 13 2
The Data Protection Officer
A generic HTTP request node and an inbound webhook node are each documented with examples, the REST API exposes workflows and credentials under an API key, and JavaScript, Python and self-hosted custom nodes cover what the 500-plus prebuilt nodes do not. Microsoft 365 appears by name, but we found no public information on connectors for ERP or accounting systems common in DACH such as SAP or DATEV, on per-connection OAuth, or on who maintains each connector; the captured pages also give different figures for the number of listed integrations. 1 8 9 13 1 2
The Skeptic
The captured pages give different figures for the count — "over 500 integrations" on the homepage, 772 apps listed on both the HTTP Request and Webhook pages, and "1000+ apps and services" as the reach of the generic HTTP Request node — so the big number is really one generic gateway counted many times. Underneath that, the HTTP Request and Webhook steps have documentation, Postgres and MySQL connectors are named, the public API exposes workflows and credentials endpoints, and custom nodes plus bash scripts are buildable on self-hosted, which is genuine reach into systems behind the firewall. We found no public information on SAP, DATEV or Microsoft Dynamics connectors for the DACH stack, on SOAP support, or on who maintains each connector. 1 8 9 13 2
Execution, error handling & monitoring
Show reasoningHide reasoning
How this is scored
What happens when a step fails at 3 a.m.: retries, error paths, alerting, an execution history someone can search, limits on runtime and throughput, and a status page that admits incidents.
0 — Nothing stated about failed runs; an error stops the workflow silently.
3 — Failed runs are marked and an email is sent, but retries are manual, execution history is short or undocumented, and runtime and throughput limits are unstated.
5 — Automatic retries with configurable back-off, an error path or error workflow, a searchable execution log with input and output per step, failure alerts by email or chat, and runtime, payload and rate limits documented.
8 — Replay of a failed run from the failing step, idempotency guidance, queueing and concurrency controls, execution history retention stated per plan, monitoring exportable to the customer's own tools, and a public status page with incident history and an uptime commitment.
10 — Operations are designed for production: an SLA with service credits, horizontal scaling or high-availability setup documented for self-hosted installs, dead-letter handling, end-to-end tracing across workflows, and post-incident reports published.
The Process Owner
A dedicated, reusable error workflow emails the failed workflow id, name and error message plus a machine-readable JSON, single steps can be re-run without re-running the whole process, executions are searchable by the data they contain, and execution duration, storage, concurrency and log retention are documented per plan. Logs can be streamed to our own tools such as Datadog. I found no public information on automatic retries with back-off, a public status page, or an uptime commitment with service credits. 1 2 11 2
The Integration Engineer
Re-running single steps instead of the whole workflow, an error-workflow setting per workflow, executions searchable by the data they contain, and per-plan retention (7 days / 30 days / unlimited) with saved-execution, storage and concurrency caps are exactly what a 3 a.m. failure needs. Queue mode for scaling and log streaming to Datadog or OpenTelemetry cover monitoring export. We found no public information on automatic retries with back-off, idempotency guidance, a public status page with incident history, or an uptime commitment. 1 2 11 2
The Operations Analyst
Error workflows send email carrying the failed workflow id, name, error source and a machine-readable JSON body, executions are searchable by the data they contain, single steps can be re-run without the whole run, logs stream to tools like Datadog, and — rare and welcome — the caps are public: run duration of 5 to 40 minutes by tier, log retention from 7 days to unlimited, concurrency from 5 to 200+. We found no public information on automatic retries with back-off, a status page with incident history, or a service commitment with credits. 1 2 11 2
The Head of IT
Error workflows reusable across many workflows, debug in the editor, re-running single steps, searchable execution data, audit logging and log streaming to services like Datadog are evidenced, with execution duration, storage, concurrency and log retention stated per plan and queue mode for scaling. We found no public information on automatic retries with configurable back-off, idempotency guidance, a public status page or an uptime commitment. 1 2 11 2
The Data Protection Officer
Failures route to a dedicated error workflow that emails the workflow id, error source and a machine-readable JSON body, executions are searchable by the data they contain, single steps can be re-run, and per-plan limits for log retention, execution duration, storage and concurrency are published — the log keeps its copy of the payload for 7 or 30 days or unlimited depending on plan. Logs can stream to external services such as Datadog, and tracing via LangSmith or OpenTelemetry is self-hosted only. We found no public information on an automatic retry policy, a status page with incident history, or an uptime commitment with service credits. 1 2 11 2
The Skeptic
A designated error workflow emails the failed workflow's name, error source and a machine-readable JSON error, single steps can be re-run instead of the whole workflow, executions are searchable by the data they contain, and per-plan limits on duration, concurrency, saved executions and log retention of 7 days, 30 days or unlimited are published. But we found no public information on automatic retries with configurable back-off, a public status page with incident history, or any uptime commitment — the only SLA mentioned covers support. OpenTelemetry tracing exists as a preview on self-hosted only, and queue mode for scaling sits on the Business tier. 1 2 11 2
Governance, credentials & audit trail
Show reasoningHide reasoning
How this is scored
Keeping automation from becoming shadow IT: roles and permissions, SSO, where connection credentials are stored, separate environments with controlled publishing, an audit trail of changes and approvals, and what the execution log retains of the payload. An approval record is also a record of employees' behaviour, so what the trail captures matters to a works council.
0 — Single-user accounts or one shared login; no roles, no audit log and no statement on credential storage.
3 — Admin and member roles and shared team folders, but credentials are visible to anyone who can edit a workflow, there is no audit log, and execution payloads are kept without a stated period.
5 — Role-based permissions per workflow or folder, SSO via SAML or OIDC, credentials stored encrypted and usable without being revealed, an audit log of workflow changes, and the retention period of execution data stated.
8 — Separate development, test and production environments with a publishing approval, SCIM provisioning, external secret stores supported, payload redaction or log-off per workflow, configurable execution data retention, and the audit trail exportable — with the fields it records about users described.
10 — Governance a works council and an auditor can both sign off: field-level masking of personal data in logs, delegated administration per department, a central inventory of every workflow and connection with its owner, certifications published (ISO 27001 or SOC 2), and documentation of what the platform records about individual users.
The Process Owner
SSO via SAML and LDAP, enforced two-factor authentication, an encrypted credential store that blocks credential export from the cloud edition, external secret stores and execution data redaction are documented, with audit logging and execution-log retention stated per plan, and the privacy policy describes what is collected about users on a self-hosted instance including a telemetry opt-out. I found no public information on SCIM provisioning, a publishing approval between the dev and production environments, an exportable audit trail naming the user fields it records, or published certifications. 2 3 15 2
The Integration Engineer
Admin roles, SAML and LDAP SSO, an encrypted credential store with sharing controls, external secret store integration, execution data redaction and enforced 2FA are all published, and audit logging plus a credentials-inventory API let me map which workflow touches which credential without exposing the secrets themselves. Dev and prod instances with Git version control give separate environments. We found no public information on SCIM provisioning, a publishing approval between environments, or what the audit trail records about individual users and whether it can be exported. 2 13 2
The Operations Analyst
SAML and LDAP single sign-on, admin roles, an encrypted credential store with external secret store integration, execution data redaction, instance-wide 2FA enforcement, audit logging and stated log retention per tier are all published, with dev/prod instances, Git and workflow diff on the upper tiers. We found no public information on SCIM provisioning, export of the audit trail, what the trail records about individual users, or ISO 27001/SOC 2 certification — the details a works council would ask about. 2 15 2
The Head of IT
SSO with SAML and LDAP, admin roles, separate dev and prod instances with Git version control and workflow diff, an encrypted credential store, external secret store integration, execution data redaction, enforced 2FA, audit logging and stated per-plan retention give me most of what I demand before a department ships automation. We found no public information on SCIM provisioning or an exportable audit trail with its recorded fields, and a central inventory of workflows and credentials exists only as a community template I would have to build myself via the API. 2 13 2
The Data Protection Officer
The platform evidences an encrypted credential store, external secret store integration, execution data redaction, SAML and LDAP SSO, enforced two-factor authentication, and separate dev and prod instances under Git with a workflow diff, alongside stated execution-log retention per plan. What the works council asks next is unanswered: we found no public information on SCIM provisioning, on exporting the audit trail, or on which fields the audit log records about individual users, and the credential inventory shown is a community template rather than a governed central register. 2 13 2
The Skeptic
SSO with SAML and LDAP, admin roles, an audit log, an encrypted credential store that stays encrypted even when audited, external secret stores, enforced two-factor authentication and execution data redaction are all listed, with execution log retention stated per plan. Separate dev and prod environments with Git and workflow diff exist on Business, but we found no public information on a publishing approval between environments, SCIM provisioning, whether the audit trail is exportable, or which fields it records about individual users — which is what a works council would ask. Self-hosted instances transmit usage data including user identifiers and workflow metrics unless the customer opts out. 2 3 13 2
Hosting options & portability
Show reasoningHide reasoning
How this is scored
Where the engine runs and whether the workflows can leave: cloud regions, self-hosted or on-premise editions, the licence of the engine, and export of workflow definitions in a format another tool or a later version can read.
0 — Cloud-only with no stated region, and no export of workflow definitions.
3 — Cloud-only with a region named, and an export that produces a proprietary file only the same product can import.
5 — An EU cloud region selectable, workflow definitions exportable as documented JSON or BPMN 2.0, and an API to read definitions and execution history for backup.
8 — A self-hosted or on-premise edition with its system requirements documented, workflow definitions versionable in Git, the engine's licence published, and a documented migration path between cloud and self-hosted in both directions.
10 — The customer owns its automation: an open-source or source-available engine, definitions in an open standard executable elsewhere, air-gapped installation supported, and a stated exit process that hands back definitions, credentials metadata and execution history in documented formats.
The Process Owner
The engine deploys on our own infrastructure — on-prem and air-gapped, via Docker — with the source code on GitHub, published licence terms that reference a community licence, and workflow definitions versionable in Git. Moving from the n8n cloud to self-hosted is documented as manual only, and credentials cannot be exported from the cloud. I found no public information on a migration path back into the cloud or on documented system requirements for self-hosting. 1 2 14 15 1
The Integration Engineer
The engine self-hosts via Docker, on-premise and air-gapped if needed, with the source on GitHub and a community licence named in the enterprise terms; workflow definitions export from the cloud dashboard and import from file on a self-hosted instance, and Git versioning is on the Business plan. The captured migration path is manual and cloud-to-self-hosted only, the support article states credentials cannot be exported from the cloud and must be re-entered, and we found no public information on a stated exit process handing back execution history. 1 2 14 15 1
The Operations Analyst
Deploy with Docker on your own servers, air-gapped if needed, with the source code on GitHub, workflow export from the cloud dashboard and file import into self-hosted, plus Git version control of definitions — real ownership of the engine. The captured migration path is manual and one-direction only, credentials cannot be exported from the cloud, and we found no public information on documented system requirements or a route back from self-hosted to cloud. 1 2 14 15 1
The Head of IT
A self-hosted edition deployed with Docker, air-gapped installation, the source code on GitHub, Git versioning of definitions and a documented cloud-to-self-hosted export give me a real exit, though the published licence terms describe a non-transferable, revocable licence limited to the term and renewals. The migration is manual and works in one direction, credentials are explicitly not exportable from the cloud, and we found no public information on cloud regions, self-hosted system requirements or a documented path back from self-hosted to cloud. 1 14 15 1
The Data Protection Officer
A self-hosted, Docker-deployable edition with the source code on GitHub and an air-gapped option is the ownership position I want, and workflow definitions sit in Git with version control. The exit path is thinner: migration from cloud to self-hosted is manual with no automated route, credentials cannot be exported from the cloud at all, and we found no public information on handing back execution history or on documented system requirements for self-hosting. 1 2 14 15 1
The Skeptic
A source-available engine with 200k+ community members, deployable with Docker and even air-gapped, with workflow definitions exportable from the cloud, importable into self-hosted, and versionable in Git on higher tiers — the automation can genuinely leave the platform. The cloud-to-self-hosted migration is manual and one-directional ("there is no automated way to migrate from n8n Cloud to self-hosted"), credentials "cannot be exported from Cloud due to security reasons", and we found no public information on a documented path back from self-hosted to cloud or on the cloud offering's hosting region. 1 2 15 1
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Who the contracting entity is, where workflows execute and where execution logs with their payload copies are stored, and who the subprocessors are — including the AI model providers behind any AI steps. Independently sourced by the sovereignty pipeline. A self-hosted edition counts only for the data that actually stays on the customer's servers.
0 — Non-EU vendor and contracting entity, execution location unstated, and subprocessors unnamed.
3 — An EU region offered as an option while the contracting entity is non-EU, or the subprocessor list is absent, or AI steps send data to model providers of unstated location.
5 — EU execution and log storage as standard and an EU contracting entity, but parts of the chain — AI steps, support access, telemetry — are non-EU without an explained safeguard.
8 — EU execution on named infrastructure, EU contracting entity, subprocessor list published with locations including AI providers, a DPA covering execution payloads, and a self-hosted option that sends no workflow data to the vendor.
10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, AI steps runnable on European or self-hosted models, certification published, and a self-hosted edition that works without any call home.
The Process Owner
Cloud workflows are "hosted by n8n" with no region named, and I found no public information on the contracting entity's jurisdiction, on where execution logs and their payload copies are stored, or on any subprocessor list — including where the Groq, Mistral or OpenRouter model calls behind AI steps run. What keeps workflow data on our own servers is the self-hosted, air-gapped edition with a documented telemetry opt-out, and offline models can be swapped in without rebuilding workflows. 1 2 3 6 1
The Integration Engineer
The vendor is listed as n8n GmbH of Berlin, and a self-hosted, air-gapped install with a documented telemetry opt-out can keep workflow data on the customer's own servers, with offline model swap for AI steps. But the independently sourced attributes leave contracting entity, data residency and subprocessors unknown, and we found no public information on where the managed cloud executes and stores logs or on any subprocessor list including the AI model providers (Groq, Mistral, OpenRouter) behind the AI steps. 1 3 1 6
The Operations Analyst
Beyond a Berlin address in the vendor provenance, we found no public information on where cloud workflows execute or where their logs are stored, no subprocessor list, and the AI providers in the published templates — Groq, Mistral, OpenRouter — are of unstated location, while self-hosted sends telemetry unless the customer opts out. The privacy policy's positives — IP anonymisation and no training of ML models on personal data — do not close those gaps. 1 3 6
The Head of IT
We found no public information on the contracting entity's jurisdiction, on where cloud workflows and their execution logs are stored, or on subprocessors — including the locations of the AI model providers behind the AI steps, where templates add Groq, Mistral or OpenRouter credentials. Self-hosting with an air-gapped option and a documented telemetry opt-out covers only the data that actually stays on our own servers. 3 6 1
The Data Protection Officer
The contracting entity is n8n GmbH in Berlin, but beyond that the chain goes dark: we found no public information on where cloud workflows execute, where execution logs with their payload copies are stored, or on any subprocessor list, including the AI model providers behind AI steps. The captured templates route content to OpenAI, Groq, Mistral or OpenRouter at unstated locations, and a self-hosted install still sends usage data including user identifiers unless the customer opts out. 3 14 6
The Skeptic
The sovereignty pipeline found no verifiable information on the contracting entity's jurisdiction, ownership or data residency, and the captured pages name no execution location and publish no subprocessor list. AI steps take credentials for Groq, Mistral, OpenRouter and OpenAI with no statement of where those model providers process the data, and we found no public information on a data-processing agreement covering execution payloads. Self-hosting with telemetry opt-out and air-gap support does keep the workflow data itself on the customer's servers, which is the one solid point in an otherwise undocumented chain. 1 3 6
Pricing transparency
panel disagrees
Show reasoningHide reasoning
How this is scored
Whether a buyer can compute the monthly cost of their own processes from public pages alone: what the billing unit is (task, operation, execution, run, user or flow) and what counts as one, the allowance per tier, overage prices, and the cost of premium connectors, self-hosting, environments and AI steps.
0 — No public prices at all; every tier is a sales conversation.
3 — A starting price exists, but the billing unit is undefined or what counts as one task or execution is unstated — the invoice is unknowable.
5 — Tier prices public with the billing unit defined and the monthly allowance given, but at least one commonly needed piece (overage, premium connectors, extra environments, self-hosted licence, AI steps) is unpriced.
8 — Every tier priced publicly with its unit, allowance and limits, overage priced per unit, premium connector and add-on prices listed, self-hosted licensing stated, minimum term and VAT treatment given.
10 — Complete price computability: the monthly cost derivable for a given number of workflows, runs and steps per run, with a published calculator or worked examples, every add-on and overage on a public page, and the effect of loops and retries on the count explained.
The Process Owner
The captured pricing pages list what each plan includes — concurrent executions, insights days, assistant credits, unlimited users and workflows and every integration — and a free trial without credit card, but no price figures for any tier. Monthly executions appear as the counted unit through the execution-count reset article, and procurement is sales-assisted with payment by invoice. I found no public information on tier prices, overage pricing or the cost of a self-hosted licence. 2 10 2
The Integration Engineer
The captured pricing pages show plan contents — unlimited users and workflows, all integrations on all plans, monthly Assistant credits, concurrency and execution limits — but no tier prices, no monthly execution allowance and no overage prices, so the invoice is not computable from the captures; only a one-time courtesy execution reset on Trial, Starter and Pro-1 hints that executions are the billed unit. We found no public information on self-hosted licence pricing, minimum term or VAT treatment. 2 10 14 2
The Operations Analyst
Allowances and limits are public — unlimited users and workflows on all plans, concurrency of 5 to 200+, assistant credits per month — and a support article confirms the monthly execution count is the meter that can be reset once as a courtesy. But no price figure for any tier appears on the captured pricing pages, and we found no public information on what a run with loops or retries adds to the count, so the monthly invoice is not computable from the public pages. 2 10 2
The Head of IT
The public plan pages give per-tier allowances and limits — concurrent executions, saved executions and storage, log retention, monthly Assistant credits — with unlimited users and workflows on every plan, and support can reset a month's execution count, which points to executions as the billing unit. We found no public information on the tier price figures, overage charges, the self-hosted licence price, AI step costs or VAT treatment and minimum term, so I cannot compute the monthly cost of my own processes. 2 10 2
The Data Protection Officer
The captured pricing pages describe what each plan includes — shared projects, concurrency, insights retention, assistant credits — but we found no prices for any tier, no monthly execution allowance, and no overage, self-hosted licence or AI-step pricing. The only billing-unit signal is a support article offering to reset a month's execution count, so a buyer cannot compute their own monthly cost from public pages. 2 10 2
The Skeptic
The plan pages publish the allowances — concurrent executions, saved executions, storage, log retention, assistant credits, "unlimited users & workflows" — but we found no public information on any monetary figure: no tier prices, no overage price, no self-hosted licence fee. The metered unit is evidently executions ("reset your current month's execution count"), yet we found no public information on what counts as one execution or how loops, sub-workflows and retries affect the count, so a buyer cannot compute a monthly cost from these pages. Procurement is sales-assisted with pay-by-invoice on the enterprise side. 2 10 2
European sovereignty — proven facts
0 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | Not determined | — | uncited Report an error |
Questions about n8n
Is n8n European?
Yes. whats-best.ai classifies n8n as EU-Made.
Where does n8n store data?
Not stated on the vendor’s pages as of 13 Oct 2026.
Does n8n have a free plan?
Not stated on the vendor’s pages as of 13 Oct 2026.
What are the best alternatives to n8n?
As of 15 Oct 2026, the panel rates Tray.ai (3/5), Camunda (2.5/5) and Frends (2.5/5) highest among the other 16 Workflow Management products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is Camunda (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: n8n alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 1 Oct 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 30 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 6 pricing facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 4 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 4 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 support facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (15)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage n8n.io Checked 13 Oct 2026 +1 earlier capture: 1 Oct 2026 Details →
- 2 Pricing page n8n.io Checked 13 Oct 2026 +1 earlier capture: 1 Oct 2026 Details →
- 3 Privacy policy n8n.io Checked 13 Oct 2026 Details →
- 4 Legal notice n8n.io Checked 13 Oct 2026 Details →
- 5 Legal hub with terms of service n8n.io Checked 13 Oct 2026 Details →
- 6 Process design, forms & approvals — found from sitemap n8n.io Checked 13 Oct 2026 +1 earlier capture: 1 Oct 2026 Details →
- 7 Process design, forms & approvals — found from sitemap n8n.io Checked 13 Oct 2026 Details →
- 8 Connectors, API & on-premise reach — found from sitemap n8n.io Checked 13 Oct 2026 +1 earlier capture: 1 Oct 2026 Details →
- 9 Connectors, API & on-premise reach — found from sitemap n8n.io Checked 13 Oct 2026 +1 earlier capture: 1 Oct 2026 Details →
- 10 Execution, error handling & monitoring — found from sitemap support.n8n.io Checked 13 Oct 2026 Details →
- 11 Execution, error handling & monitoring — found from sitemap n8n.io Checked 13 Oct 2026 +1 earlier capture: 1 Oct 2026 Details →
- 12 Governance, credentials & audit trail — found from sitemap n8n.io Checked 13 Oct 2026 +1 earlier capture: 1 Oct 2026 Details →
- 13 Governance, credentials & audit trail — found from sitemap n8n.io Checked 13 Oct 2026 Details →
- 14 Hosting options & portability — found from sitemap n8n.io Checked 13 Oct 2026 Details →
- 15 Hosting options & portability — found from sitemap support.n8n.io Checked 13 Oct 2026 +1 earlier capture: 1 Oct 2026 Details →