Workflow automation in 2026: revisit n8n, Node-RED and Activepieces before you wire another business process to a webhook

Most teams first meet workflow automation as a shortcut: draw a few boxes, point a webhook at a SaaS, and declare the process automated. Somebody connects the ERP to the CRM, adds a Slack message on failure, and moves on. Months later a credential rotates, a vendor changes a payload shape, two workflows write the same order twice, and on-call learns that the automation had no owner, no timeout and no audit trail.

The tool was not the only problem in that story. What was missing was a clear boundary between a visual workflow and real application code, a place for secrets that is not a shared spreadsheet, and a habit of treating the automation host as a production system. This post compares three open-source workflow tools that Indian teams most often shortlist when they want to self-host in 2026: n8n, Node-RED and Activepieces. It also says when none of them is the right answer, and when a durable execution engine, a job queue or a few lines of code is the better fit.

Workflow tools sit on top of the rest of your platform, so a few earlier posts are useful background. Durable execution in 2026 covers the engines you should reach for when a process must survive crashes with explicit retries and sagas. Data pipeline orchestration in 2026 is the cousin of this post for batch and analytics work. Background jobs on PostgreSQL in 2026 matters when the job is “run this function later” rather than “wire five SaaS apps together”. Message queues and API gateways in 2026 are the pipes that webhooks and workers usually sit behind. Vault and OpenBao and Keycloak and its alternatives cover the secrets and identity layers that every serious automation host will eventually need, and idempotency keys is the reminder that a retried webhook without an idempotency story will charge a customer twice.

We end with a small drill that ran Node-RED 5.0.9 and n8n 2.45.6 on loopback only, looked at credential files and default authentication, and a plain list of what we did not run.

A scenario to keep us honest

Imagine a company in Jalandhar that builds software for the sports goods trade in Punjab: order intake for cricket and hockey manufacturers, packing list and export document preparation for shipments to Europe and the Middle East, raw material purchase tracking for leather and composite suppliers, and a dealer portal for retailers across North India. The company is invented for this post. It has about 45 engineers, a platform team of three, and one person who owns “integrations” on top of their regular backend work.

The setup today:

• One production Kubernetes cluster in a cloud region in Mumbai, with a smaller staging cluster built from the same charts.
• About 25 services, mostly Node.js and a few Java services for the older ERP connector, with an NGINX ingress and no service mesh yet.
• PostgreSQL for orders and dealers, Redis for sessions and a few caches, and a managed object store for packing lists and export PDFs.
• A growing pile of Zapier and Make.com scenarios owned by operations, plus three Node.js cron jobs that nobody wants to touch, and one fragile webhook receiver that posts into the ERP.
• Prometheus, Grafana and Loki for the services; almost no metrics for the SaaS automations.

Four things push the team to revisit workflow automation. First, a large European retailer asked, in a supplier questionnaire, where order and shipment events are processed, who can change those flows, and how credentials are stored. Second, a Zapier scenario silently stopped updating dealer stock after an API token expired, and the warehouse only noticed when a truck arrived for stock that was not there. Third, the fragile ERP webhook charged a dealer twice during a retry storm on a festival-sale weekend. Fourth, two engineers have proposed self-hosting so that flows, credentials and audit logs stay inside the company’s own network: one prefers n8n (a friend’s company runs it), one prefers Node-RED (they already use it on a few shop-floor Raspberry Pi boards), and a third has been reading about Activepieces because of its MIT core and agent features.

We will come back to Jalandhar in the worked plan.

The short version

• n8n is a fair-code workflow automation platform with a large node catalogue, a visual editor, queue mode with Redis, and a clear split between a free Community edition and paid Business and Enterprise features. The current stable release is 2.45.6 (29 October 2026). The Sustainable Use License is not OSI open source. The security advisory history is long and active. Version 3.0 is in early access and drops npm installs in favour of Docker.
• Node-RED is a flow-based programming tool under the Apache License 2.0, hosted by the OpenJS Foundation. It is excellent for event-driven and edge flows, light on dependencies, and dangerous if you leave the editor open without adminAuth. The current release is 5.0.9 (21 October 2026). It is not trying to be an iPaaS.
• Activepieces is a TypeScript automation platform with an MIT core, a commercial enterprise folder, Postgres plus Redis plus S3 in production, BullMQ workers, and first-class agent and MCP features. The current release is 0.92.3-hotfix.2 (28 October 2026). Sandboxing and network mode are configurable and default to open on a single-tenant install.
• Prefer code, a job queue or a durable execution engine when the process is core business logic, needs strong exactly-once behaviour, or must be reviewed like application code. Prefer a workflow tool when the work is integration glue across many systems, owned by a small platform or operations group, and changed often.

Where things stand on 29 October 2026

n8n. The latest stable release is n8n@2.45.6, published on GitHub on 29 October 2026 at 2:00 PM IST, and it is what npm serves as latest. It is a small patch (queue mode time-saved handling and a sidebar fix). The 1.x maintenance line is at 1.123.90 (2:30 PM IST the same day) and is tagged rc on npm; that build includes a signed token requirement for accepting invitations. The 2.46.2 build is a beta under the next tag (2:19 PM IST). n8n@3.0.0 was published as a prerelease on 27 October 2026 at 2:17 PM IST, with 3.0.1 following on 28 October at 1:36 PM IST. The 3.0 notes call it early access: self-hosted installs are expected to run through the official Docker image, npm and npx installs are no longer supported, unverified community packages are off by default, and several AI and sub-workflow behaviours change. n8n first appeared on npm in April 2019; 1.0.0 landed in June 2023 and 2.0.0 on 8 December 2025.

Node-RED. The latest release is 5.0.9, published on 21 October 2026 at 3:59 PM IST. It fixes a crash on a comms auth packet when adminAuth is not set. The 4.x maintenance line is at 4.1.17 from the same day. Node-RED 5.0.0, the milestone release, came on 9 June 2026 at 2:36 PM IST: it needs Node.js 22.9 or later (24 is recommended) and is the biggest editor UX change in years. The project was open-sourced in September 2013, was a founding project of the JS Foundation in October 2016, and sits today as an At-Large project of the OpenJS Foundation. npm first published 0.1.0 on 27 September 2013.

Activepieces. The latest GitHub release is 0.92.3-hotfix.2, published on 28 October 2026 at 3:20 AM IST. It fixes an unauthenticated, webhook-triggerable crash of the whole API process caused by an illegal header name in the Return Response piece (ENG-1099). Hotfix.1 on 23 October moved the Docker image to Node.js 24.22.1 for the October 2026 Node security releases. The regular 0.92.3 line is from 12 October 2026. Older release lines also received hotfixes on 29 October. The first public GitHub release was 0.1.3 on 14 January 2023. There is no npm package named activepieces that runs the platform; the supported path is the Docker image.

The first question: is a workflow tool the right shape?

Before you compare licences and dashboards, decide what kind of work you are automating.

• If the work is “when this HTTP call arrives, call three other APIs, transform a JSON body and notify Slack”, a workflow tool is a good fit.
• If the work is “run this TypeScript function with retries, a dead-letter queue and a schedule”, a background job library on PostgreSQL or Redis is usually simpler and easier to test.
• If the work is “orchestrate a long business transaction across services with sagas, timers and human approval”, a durable execution engine is the shape that will still make sense in two years.
• If the work is “nightly transform of the warehouse dump into the analytics warehouse”, you want a data pipeline orchestrator, not an iPaaS.

Jalandhar’s pain is mostly the first kind today, with a dangerous overlap into the second and third. The ERP webhook that charged a dealer twice is an idempotency and job-queue problem wearing a workflow costume. Keep that distinction in mind as you read the rest.

What each tool is

n8n

n8n is a Node.js workflow automation platform. You build workflows as graphs of nodes (triggers, actions, transforms) in a browser editor. Executions can run in the main process or, in queue mode, be handed to worker processes through Redis and Bull. Credentials are encrypted with an instance key. The product is split into a Community edition you can self-host under the Sustainable Use License, a Registered Community tier that unlocks a few editor features after an email signup, and paid Business and Enterprise tiers for sharing, SSO, environments, external secrets and multi-main setups.

A minimal idea of the queue mode layout, from the project’s own docs:

EXECUTIONS_MODE=queue
# main: webhooks and triggers, pushes execution id to Redis (Bull)
# worker: fetches workflow from DB, runs it, writes results
N8N_ENCRYPTION_KEY=shared-across-main-and-workers
DB_TYPE=postgresdb   # SQLite is not supported for queue mode

From version 2.0 the Code node is expected to run inside a task runner, not inside the main process. Internal mode (a child process with the same user id) still exists but is deprecated towards 3.0. External mode runs the official runners image beside n8n and is what you want if the Code node can see untrusted input.

Node-RED

Node-RED is a flow-based programming tool built on Node.js. You wire nodes in a browser editor and deploy them to a lightweight runtime. Flows are JSON. The core palette covers HTTP, MQTT, TCP, UDP, WebSocket, file, watch, function, switch, change, split, join and similar building blocks. The community publishes thousands more nodes. It started at IBM Emerging Technology in early 2013 as a way to map MQTT topics, was open-sourced in September 2013, and is now an OpenJS Foundation At-Large project under the Apache License 2.0.

A minimal settings.js that binds only to loopback and turns the editor login on looks like this:

module.exports = {
  uiHost: "127.0.0.1",
  uiPort: 1880,
  credentialSecret: process.env.NR_CRED_SECRET,
  adminAuth: {
    type: "credentials",
    users: [{ username: "ops", password: "<bcrypt hash>", permissions: "*" }]
  }
};

Without adminAuth, anyone who can reach the editor can read and deploy flows. That is the documented default, not a bug. Without credentialSecret, Node-RED invents a key, stores it in the user directory, and warns you on every start.

Activepieces

Activepieces is a TypeScript monorepo. The open core (MIT) covers the app, worker, engine, sandbox package, pieces and shared types. The packages/ee tree and the matching server ee folder are under a commercial licence and need an Activepieces Enterprise licence for production use. In production you run an app container and one or more worker containers, with Postgres for state, Redis for BullMQ, and S3 for files. Workers pull jobs, run each flow inside a sandboxed engine, and report results. Checkpoints are written at the start of a run, every fifteen seconds and at the end; on resume, finished steps are skipped and the in-flight step runs again (at-least-once).

A minimal idea of the production split, from the project’s own docs:

AP_CONTAINER_TYPE=APP          # or WORKER, or WORKER_AND_APP
AP_DB_TYPE=POSTGRES
AP_ENCRYPTION_KEY=<32 hex chars>
AP_JWT_SECRET=<32 hex chars>
AP_EXECUTION_MODE=SANDBOX_CODE_ONLY   # Cloud default; UNSANDBOXED is the shipped default
AP_NETWORK_MODE=STRICT                # UNRESTRICTED is the shipped default

Activepieces also ships Agents, an MCP server, an AI Router and “build with chat” flows. Those features matter for Jalandhar only after the basics (auth, secrets, sandbox, backups) are in place.

Side by side

Licence and governance

• n8n. Sustainable Use License v1.0 for the open tree, plus a separate n8n Enterprise License for files and directories marked .ee. The Sustainable Use License allows internal business use and non-commercial use, and free-of-charge non-commercial distribution. It is not an OSI-approved open-source licence, and it is not Apache-2.0 or MIT. Branches other than main are not licensed. The company behind it is n8n GmbH. Community, Registered Community, Business and Enterprise editions are how features are gated; the pricing page is the stated source of truth.
• Node-RED. Apache License 2.0. Hosted by the OpenJS Foundation as an At-Large project. Governance is foundation-style, with a long public history from IBM Emerging Technology through the JS Foundation to OpenJS. FlowFuse, Inc. sells an enterprise platform around Node-RED; the core project remains Apache-2.0.
• Activepieces. Dual licence. MIT Expat for the core. Commercial Activepieces Enterprise License for packages/ee and packages/server/api/src/app/ee. Self-hosted use of enterprise features needs a paid licence. The company is Activepieces Inc. Embedded PGLite “Hobby” installs cannot activate Enterprise.

If your legal team only accepts OSI licences for anything that touches customer data, Node-RED is the easy yes, Activepieces core is a yes with a clear ee boundary to watch, and n8n needs an explicit conversation about the Sustainable Use License and about which edition you are actually running.

Architecture

• n8n. Single process by default (editor, webhooks and executions together) with SQLite. Queue mode adds Redis, one or more workers, optional webhook processors, and expects Postgres. Multi-main (several main processes behind a load balancer, leader election) is Enterprise-only. Task runners isolate Code node execution. Binary data in queue mode should go to S3, not the filesystem.
• Node-RED. Single Node.js process. Flows and credentials as files in a user directory (or a project). Context can be memory or a configured store. No built-in worker pool, no built-in Redis queue. Horizontal scale is “run more instances with a shared plan for what each instance owns”, not a first-class queue mode. That simplicity is the point for edge and IoT; it is a limit for a central iPaaS.
• Activepieces. App plus workers is the intended production shape. Postgres, Redis and S3 are required once you leave the embedded database. Workers are meant to be for the job; the recommended concurrency is one flow per worker process, with the shipped default of five called transitional. The engine is a compiled JavaScript file run inside the sandbox.

Execution model and queue / scaling mode

• n8n. Regular mode runs executions in-process. Queue mode (EXECUTIONS_MODE=queue) uses Bull on Redis: the main accepts the trigger, the worker runs the workflow. Worker concurrency defaults to 10. Manual executions in queue mode move onto workers in 3.0. Workflow timeout and webhook response size are configurable; the relay size default is 64 MiB.
• Node-RED. Event-driven, in-process. Each message flows through the wires. HTTP in nodes are the webhook surface. There is no shared execution queue across instances. For Jalandhar’s central order flows that is a reason to hesitate; for shop-floor Raspberry Pi boards it is exactly why Node-RED is already there.
• Activepieces. Everything is queue-backed through BullMQ. Webhooks and recurring jobs land on Redis; workers poll. Flow timeout defaults to 600 seconds. Synchronous webhooks are capped at about 30 seconds and 25 MB. Crash recovery is at-least-once with step checkpoints every 15 seconds; Redis durability is your problem as the operator.

Persistence

• n8n. SQLite by default; Postgres for anything serious and for queue mode. Executions, credentials, workflows and settings live in the database. Binary data has moved toward a storage directory (the old binaryData path is renamed in the 3.0 line) and external object storage for scale.
• Node-RED. flows.json and flows_cred.json on disk by default. Projects mode can put them in a Git repository. Context is separate. There is no execution history database unless you add one through nodes or an external system.
• Activepieces. Postgres is the system of record. PGLite is the embedded option for hobby installs (SQLite3 is deprecated and migrated). Run logs and step state support the durable-execution behaviour. Files go to S3 in production.

Credentials and secrets handling

• n8n. Credentials are encrypted with an instance encryption key (auto-generated into ~/.n8n/config on first start, or set with N8N_ENCRYPTION_KEY). The key must be shared by every main and worker. Key rotation uses a two-layer model and is available on all self-hosted editions; take a database backup first. External secrets managers and environment-based config are paid-edition features. Credential sharing between users is also gated.
• Node-RED. Credentials for nodes are stored in flows_cred.json, encrypted with credentialSecret from settings.js. If you do not set credentialSecret, Node-RED generates a key, writes it into .config.runtime.json as _credentialSecret, and prints a warning. Lose that key and you cannot recover the credentials file. Setting credentialSecret migrates the file on the next deploy. The editor and HTTP admin API are wide open until you configure adminAuth.
• Activepieces. Connections are encrypted with AP_ENCRYPTION_KEY (32 hex characters). JWTs are signed with AP_JWT_SECRET. Both are required for a serious install. Secret managers appear on the Enterprise feature list. The queue UI (Bull Board at /api/ui) must not be left on without a username and password; an older advisory made that painful for anyone who did.

Security history

Cite the primary sources, not blog roundups.

• n8n. As of this research the n8n-io/n8n repository has 237 published GitHub security advisories: 22 critical, 102 high, 111 medium, 2 low. They run from April 2025 through October 2026, with heavy months in June (27), July (30), August (26), September (49) and October (27) of 2026. Notable entries: CVE-2026-21858 (GHSA-v4pr-fm98-w9pg), CVSS 3.1 score 10.0, published 7 January 2026, unauthenticated file access through form-based workflow webhook handling, fixed in 1.121.0; CVE-2025-68613 (GHSA-v98v-ff95-f3cp), CVSS 9.9, published 19 December 2025, authenticated expression injection leading to RCE, fixed in 1.122.0; CVE-2025-68668, CVSS 9.9, Pyodide Python Code node sandbox bypass on 1.x, addressed by the native task runner becoming default in 2.0.0; CVE-2026-21877, CVSS 9.9, RCE through arbitrary file write, fixed in 1.121.3; GHSA-9p7v-45m2-wxgj, published 28 October 2026, CVSS 4.0 score 8.7, Function / Function Item / LangChain Code nodes able to run in the main process, now deprecated and blocked by default in recent 2.x and 3.0.1 builds. Twelve advisories landed on 28 October 2026 alone. A long advisory list is not by itself a reason to reject a project, but it is a reason to budget for upgrades, to keep public webhook and form endpoints behind a gateway, and to treat the Code node as hostile input.
• Node-RED. The node-red/node-red repository shows two published advisories, both from 2021 and fixed in 1.2.8: CVE-2021-21298 (path traversal via the Projects API) and CVE-2021-21297 (prototype pollution via the admin API). NVD also records CVE-2019-15607 (stored XSS in versions through 0.20.7). The sharper recent risk is not the core project: it is vendors shipping Node-RED without authentication. CVE-2025-24522 (KUNBUS Revolution Pi OS, CVSS 4.0 score 9.3), CVE-2026-58115 (Siemens SIMATIC IoT2050 Advanced before V4.3.4.1, CVSS 4.0 score 10.0) and CVE-2026-77052 (boneIO Black exposing /nodered/ through Caddy, score 8.7, fixed in 1.6.0) are reminders that an open editor on a reachable interface is a free remote deploy.
• Activepieces. Nine published repository advisories. Critical: GHSA-m992-8rcw-vmrx (9 August 2026, CVSS 4.0 score 9.2), Bull Board queue UI exposed without authentication in 0.80.0 through 0.84.0 when AP_QUEUE_UI_ENABLED was true, fixed in 0.84.1. High examples: CVE-2026-73081 (command injection through the Code step name while the worker build ran as root in the default image, fixed in 0.80.0), CVE-2026-48499 (cross-tenant Code piece cache), CVE-2026-53536 (cross-tenant file download), CVE-2026-53535 (git-sync path traversal), CVE-2026-73082 (SSRF in MCP validation). CVE-2026-73083 (V8 isolate bypass that could expose AP_ENCRYPTION_KEY and AP_JWT_SECRET) and CVE-2026-73084 (reflected XSS in an OAuth redirect) round out the set. The 0.92.3-hotfix.2 release on 28 October 2026 fixed an unauthenticated crash reachable through a webhook.

AI and agent features

No hype, just what the projects document.

• n8n. LangChain-based AI nodes, an AI Agent node (v1 modes removed in 3.0), Agent Builder and MCP support called out in the 3.0 early-access notes, plus OpenTelemetry GenAI attributes. Chat Hub is off by default in 3.0. Deprecated Function / LangChain Code paths are being blocked because they could run in the main process.
• Node-RED. No first-party AI agent or MCP nodes in the core palette. You can call any HTTP model API from a function or http request node, and the community publishes AI-related nodes, but the project itself is still a general flow runtime.
• Activepieces. Agents, agent tools and knowledge, agents as flow steps, an AI Router, “build with chat”, an MCP server, and bring-your-own AI provider keys are documented product surfaces. Piece “atomics” aimed at agents landed heavily around 0.92.0. Treat these as features that widen the attack surface (prompt injection into a flow that holds credentials) rather than as a reason to pick the platform on day one.

Operations and upgrades

• n8n. Docs say update at least once a month and read the release notes for breaking changes. Environments (paid) help you test an upgrade first. Moving to 3.0 is a project of its own because the install path changes to Docker-only for self-hosted. Encryption key rotation is documented and should be rehearsed on a copy of the database. Queue mode means you are also operating Redis and Postgres.
• Node-RED. npm update of the package, restart, and check that your palette nodes still load. Major lines (4.x, 5.x) need a Node.js bump. Keep credentialSecret and adminAuth in the settings you actually deploy, not only in a wiki page. Back up the user directory before you move versions.
• Activepieces. Docker image tags, including hotfix tags on older lines. Postgres and Redis backups are part of the upgrade. Watch AP_EXECUTION_MODE and AP_NETWORK_MODE when you promote an install that started as UNSANDBOXED and UNRESTRICTED. Enterprise features need a licence key and do not run on the embedded database.

Footprint

• n8n. A fresh npm install of 2.45.6 on Node 24 pulled on the order of 2,300 packages in our drill and occupied a few gigabytes on disk. Runtime needs Node 24 or later today. Queue mode adds Redis and preferably Postgres. Memory depends on concurrency and binary payloads; do not size from a vendor slide.
• Node-RED. A fresh npm install of 5.0.9 pulled 276 packages in about seven seconds in our drill. Runtime is a single Node process and is comfortable on small hosts and on Raspberry Pi class hardware. Node 22.9 or later (24 recommended) for the 5.x line.
• Activepieces. Production means app container, worker container(s), Postgres, Redis and S3. That is a larger ops surface than Node-RED and similar in kind to a queued n8n install. The hobby path with PGLite is smaller and is not the path for Enterprise features.

A worked plan for Jalandhar

Here is a practical sequence the invented Jalandhar team can follow. It is not a sales pitch for any one tool.

1. Write down the flows that actually hurt. Order intake from the dealer portal into the ERP, packing-list PDF generation, export-document packing for the European retailer, stock updates that Zapier dropped, and the webhook that double-charged a dealer. Give each flow an owner and a success metric (for example “stock update lag under five minutes”).

2. Split glue from core. Anything that is “call these APIs in order” can stay a candidate for a workflow tool. Anything that is “compute price, reserve stock, write the ledger” belongs in application code with tests. The double-charge webhook is a job-queue and idempotency problem; fix that with the ideas in the idempotency keys and background jobs posts before you redraw it as pretty nodes.

3. Put secrets somewhere real. Choose Vault or OpenBao, or at least a sealed secrets workflow, before the first production credential is pasted into a new tool. See Vault and OpenBao.

4. Decide the hosting shape. One small Kubernetes namespace for the automation host, private to the company network, with an ingress that only the API gateway can reach. No public editor. No public /webhook URL without authentication at the gateway. See API gateways in 2026.

5. Shortlist with licence and edition in the room. Legal and procurement sit with engineering for one hour. If OSI-only is a hard rule, n8n’s Sustainable Use License needs an explicit exception or a no. If Enterprise SSO and audit logs are required this year, budget for n8n Enterprise or Activepieces Enterprise rather than hoping the community edition grows them.

6. Run a two-week spike on staging. Pick one flow (dealer stock update). Implement it in the shortlisted tool. Turn on authentication, set encryption keys from a secret store, export a backup, rotate a credential, and break the downstream API on purpose to see the retry behaviour. Keep Node-RED on the shop-floor Pis; do not force it to be the central iPaaS unless the spike says so.

7. Choose, then freeze the install method. For n8n today that means planning for Docker toward 3.0 even if the spike used npm on 2.45.x. For Activepieces that means Postgres, Redis and S3 from day one if you care about Enterprise later. For Node-RED that means settings.js under config management with adminAuth and credentialSecret set.

8. Wire identity. Hook the editor and admin APIs to the company IdP. The Keycloak alternatives post is the background reading. Disable local admin passwords where the product allows.

9. Migrate one Zapier scenario at a time. Start with the one that failed silently. Add a dead-letter path and an alert into the existing Prometheus stack. Only then switch DNS or webhook URLs.

10. Review monthly. Read the project’s security advisories once a month. Apply updates within a defined window. Re-read the list of flows and delete the ones nobody owns.

For Jalandhar’s central cloud flows, the honest ranking after this research is: Activepieces or n8n for the iPaaS-shaped work, with the licence conversation deciding between them; Node-RED kept for shop-floor and MQTT-heavy edge; and a PostgreSQL job library for the ERP write path that must not charge twice.

When each is better

• n8n is better when you want the largest catalogue of ready nodes, a mature queue mode, and you are willing to live with the Sustainable Use License and a paid edition for SSO, sharing and multi-main. It is also the path of least resistance if your team already thinks in “Zapier but self-hosted” terms and can commit to monthly upgrades.
• Node-RED is better when the runtime must be small, the licence must be Apache-2.0, the flows are event-driven (MQTT, industrial protocols, edge devices), and a single process with a file-based flow is a feature rather than a limitation. It is the right tool for the Jalandhar shop-floor boards. It is usually the wrong tool as the only company-wide iPaaS.
• Activepieces is better when you want an MIT core, a clear commercial boundary for enterprise features, Postgres-backed durable runs, and first-class worker isolation options (including the V8 isolate mode their cloud uses). It is also the more natural home if agents and MCP are on the twelve-month roadmap and you are ready to sandbox them.

When not to adopt a workflow tool

• When the process is core domain logic that belongs in version-controlled application code with unit tests and code review.
• When you need strongly-specified durable execution, timers, sagas and human-in-the-loop as first-class primitives. Use a durable execution engine instead.
• When every “workflow” is really “enqueue a job and retry”. Use a background job library.
• When the data path is batch analytics. Use a data pipeline orchestrator.
• When nobody will own upgrades, credential rotation and advisory response. An unmaintained automation host is worse than the Zapier bill you were trying to escape.
• When the only requirement is a public webhook that writes to one database table. An API gateway route plus a small service is enough.

A short history

• 2013. Node-RED begins at IBM Emerging Technology as an MQTT mapping tool; open-sourced in September; npm 0.1.0 on 27 September 2013.
• 2016. Node-RED becomes a founding project of the JS Foundation (October).
• 2019. Node.js Foundation and JS Foundation merge into the OpenJS Foundation; Node-RED continues there. n8n appears on npm (April) and the GitHub repository is created (June).
• 2021. FlowFuse is founded to commercialise enterprise Node-RED. Node-RED 2.0.0 ships in July.
• 2022. n8n moves to the Sustainable Use License (March) and adds the Enterprise License file (August). Activepieces repository created in December.
• 2023. Activepieces 0.1.3 is the first public GitHub release (14 January). n8n 1.0.0 lands in June. Node-RED sits as an OpenJS At-Large project.
• 2024. Node-RED 4.0.0 in June. Activepieces continues the MIT-plus-ee dual licence path.
• 2025. n8n 2.0.0 on 8 December, with native task runners becoming the default answer to Code node isolation. Heavy advisory activity on n8n begins to show up in public GHSA records into 2026.
• 2026. Node-RED 5.0.0 in June (Node 22.9+, editor milestone); 5.0.9 in October. Activepieces 0.92 line with agent atomics and sandbox work; hotfix.2 on 28 October for an unauthenticated crash. n8n 2.45.6 stable on 29 October; 3.0 early access on 27-28 October with Docker-only self-hosting.

Decision guide

• Need Apache-2.0 or MIT with no fair-code surprise? Prefer Node-RED or Activepieces core.
• Need the widest set of ready SaaS nodes and can accept Sustainable Use plus a paid tier? Prefer n8n.
• Need central queue-backed workers with Postgres? Prefer n8n queue mode or Activepieces; not stock Node-RED.
• Need edge / MQTT / shop floor? Prefer Node-RED.
• Need SSO, audit logs, projects and secret-manager integration this year? Budget Enterprise on n8n or Activepieces; do not pretend the free tier covers it.
• Need agents and MCP? Activepieces documents them as product surfaces; n8n is investing through LangChain nodes and 3.0 MCP notes; Node-RED leaves it to you.
• Need strong exactly-once business transactions? None of the three: use durable execution or carefully designed idempotent jobs.

Checklist

• Licence reviewed by legal, including edition boundaries and ee folders.
• Encryption keys (n8n N8N_ENCRYPTION_KEY, Node-RED credentialSecret, Activepieces AP_ENCRYPTION_KEY and AP_JWT_SECRET) generated, stored in a secret manager, and backed up.
• Editor and admin APIs not reachable from the public internet.
• Authentication on: adminAuth for Node-RED; owner setup and IdP/SSO plan for n8n and Activepieces.
• Public webhooks authenticated at the gateway, rate-limited, and idempotent on the write path.
• Queue mode dependencies (Postgres, Redis, S3 as required) in the same backup and alert regime as the app.
• Sandbox and network mode set deliberately (n8n task runners; Activepieces AP_EXECUTION_MODE and AP_NETWORK_MODE).
• Upgrade window defined; security advisories subscribed.
• Each production flow has an owner, a success metric and a documented rollback.
• Code nodes treated as untrusted input.

Common mistakes

• Leaving Node-RED’s editor open without adminAuth because “it is only on the VPC”.
• Running n8n or Activepieces for months without applying advisory fixes.
• Storing the n8n encryption key in a ticket or a shared chat, then losing it and every credential with it.
• Using SQLite for n8n queue mode or for any install you care about.
• Enabling Activepieces queue UI without a password (the GHSA-m992 class of mistake).
• Pointing a workflow at production ERP write APIs without an idempotency key.
• Letting operations build forty Zapier-like scenarios with no owner and no review.
• Choosing a workflow tool for a problem that is really durable execution or a job queue.
• Installing n8n with npm today without a plan for the 3.0 Docker-only self-hosted path.
• Assuming AI agent features are a reason to skip sandboxing.

The drill we ran

We ran a small drill on a shared Linux machine with no Docker, no system services, no sudo and nothing beyond the loopback interface.

• The box had Node.js 20, which is too old for Node-RED 5 and for n8n 2.45. We downloaded the official Node.js 24.22.2 linux-x64 tarball into the drill directory, verified the SHA256 against the nodejs.org SHASUMS file, and put it on PATH for the drill only.
• Node-RED 5.0.9 installed with npm –prefix into drill83/nr (276 packages, about seven seconds). n8n 2.45.6 installed the same way into drill83/n8n (2,353 packages, about one minute fourteen seconds).
• Node-RED was started with userDir inside the drill folder, uiHost 127.0.0.1 and uiPort 18083. On first start, without credentialSecret, it printed the standard warning that credentials would be encrypted with a system-generated key. GET /flows without any authentication returned 200, which confirms the documented default that the editor API is open until adminAuth is set.
• We deployed a small flow over the admin API: an HTTP POST /drill/order that returns 202, and an HTTP request node that carried a basic-auth credential (user erp-bot, password a drill-only string). The password did not appear in flows.json. It appeared only as ciphertext in flows_cred.json. The system key lived in .config.runtime.json as _credentialSecret. Offline decryption with that key recovered the credential object. POST /drill/order returned {“ok”:true} with status 202.
• We restarted with adminAuth (a bcrypt hash of a drill password for user ops) and credentialSecret set from the environment. GET /flows without a token returned 401. A correct password to /auth/token produced a bearer token that could read flows; a wrong password returned 403.
• A second userDir exercise used a flow that actually called loopback: an HTTP request node with the stored basic-auth credential called /drill/echo, which replied with the Authorization header. With the system key, and again after migrating to credentialSecret, the header was the expected Basic value. After a deploy under the chosen secret, wrong secret on the next start logged “Error loading credentials” and “Failed to decrypt credentials”, and the call returned an empty body. Restoring the right secret brought the header back.
• n8n 2.45.6 was started with N8N_USER_FOLDER inside the drill folder, N8N_LISTEN_ADDRESS=127.0.0.1 and N8N_PORT=18084. It auto-generated an encryption key into .n8n/config with mode 600, created a SQLite database, and listened on loopback. /healthz and /healthz/readiness returned {“status”:“ok”}. /rest/workflows without auth returned 401. The first-run owner setup succeeded once and returned 400 on a second attempt. A credential of type httpBasicAuth was stored; the database blob began with the OpenSSL-style U2FsdGVkX1/ prefix and a filesystem grep found no plaintext copy of the drill password. Startup printed deprecation notices that internal task runners are going away, that some defaults will tighten, and that “Running n8n outside a container is deprecated” toward future versions.
• Both processes were stopped. pgrep showed no remaining n8n or node-red processes, and ports 18083, 18084 and 5679 were free.

What we did not run: Activepieces (it needs Postgres, Redis and S3, or the vendor Docker image, none of which this drill allows), n8n queue mode, Redis, Postgres, external task runners, SSRF toggles, encryption key rotation, any workflow execution beyond owner and credential setup, any bind outside loopback, any upgrade to n8n 3.0, any real third-party SaaS call, and no benchmarks of any kind.

Unlearn, re-learn

• Unlearn “workflow automation means drawing boxes until the SaaS bill goes away”. Re-learn that every box still needs an owner, a secret, a timeout and a way to fail loudly.
• Unlearn “self-hosted is automatically safer”. Re-learn that an open Node-RED editor or an unpatched n8n webhook is a production incident waiting for a scanner.
• Unlearn “the free edition will grow into SSO and audit logs”. Re-learn to read the edition matrix before you promise those features to a customer questionnaire.
• Unlearn “licence is a detail for later”. Re-learn that Sustainable Use, MIT and Apache-2.0 are different promises, and that ee folders are not decorative.
• Unlearn “retries make webhooks reliable”. Re-learn idempotency, or you will charge a dealer twice on a festival weekend.
• Unlearn “AI agents inside the workflow tool are the strategy”. Re-learn that agents are another way to spend credentials, and sandbox them like untrusted code.
• Unlearn “we can install with npm forever”. Re-learn that n8n 3.0 early access already says self-hosted means Docker, and plan the install path on purpose.

Sources

• n8n: n8n repository, n8n@2.45.6 release, n8n@3.0.0 release, LICENSE.md (Sustainable Use License), LICENSE_EE.md, Community edition features, Queue mode, Task runners, Encryption key, SSRF protection, n8n security advisories, CVE-2026-21858 at NVD, CVE-2025-68613 at NVD, npm n8n package
• Node-RED: Node-RED repository, Node-RED 5.0.9 release, Node-RED 5.0.0 release, Securing Node-RED, About Node-RED, OpenJS Foundation projects, npm node-red package, CVE-2021-21297, CVE-2026-58115 at NVD, CVE-2026-77052 at NVD
• Activepieces: Activepieces repository, 0.92.3-hotfix.2 release, LICENSE (MIT core), Enterprise LICENSE, About licence, Architecture overview, Workers, Sandboxing, Durable execution, Crash recovery, Production setup, Network security, Environment variables, Activepieces security advisories, CVE-2026-73081 at NVD
• Related posts on Revisit.Tech: durable execution in 2026, data pipeline orchestration in 2026, background jobs on PostgreSQL in 2026, message queues, API gateways in 2026, Vault and OpenBao, Keycloak and its alternatives, idempotency keys, self-hosted CI in 2026