Which fits your Zaps: Zapier or self-hosted Node-RED?
Zapier fits best when SaaS connector breadth and hosted operation matter most. If your Zaps mostly connect popular cloud applications, and your team would rather not run any servers, Zapier's app catalog and managed runtime are the lower-effort path. Node-RED fits a different job. It is a flow-based tool built for event-driven work, such as reacting to sensor messages, MQTT topics, internal APIs and database changes, and it runs inside your own network under an Apache-2.0 license. The review usually starts with a task bill or a data location question, but the answer depends on which of your Zaps move data between systems that are already internal.
Node-RED's editor is not secured by default, and the Node-RED documentation says that anyone who can reach the editor's IP address can deploy changes. Before you put it on a network segment, confirm that HTTPS, editor authentication through Passport and HTTP node authentication are configured as the Securing Node-RED guide describes. Plan who owns those settings, the flow files and the runtime upgrades. Those responsibilities move to your team once you self-host, and they are the part of the decision most often underestimated.
Three questions should settle the choice. First, list every SaaS application your Zaps touch and check whether Node-RED has a maintained node for it, because the community library is large but uneven in quality and coverage. Second, name the people who will build and maintain flows, and confirm they are comfortable with JavaScript and JSON-based flows or can train for it. Third, assign an owner for editor security and runtime updates. If the gaps in connectors are small and your team can own the runtime, Node-RED is a strong fit. If not, a tool with a larger SaaS catalog may be the better match.
Which scenarios favor Zapier and which favor Node-RED
This table maps common automation scenarios to the platform that usually fits better, and names the condition that decides it. Read each row against your own systems, staff and data rules, because the right answer often depends on one factor such as device reach or who maintains the flows. Most teams find that SaaS-to-SaaS work stays with Zapier, while internal and device-level flows favor Node-RED.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| SaaS-to-SaaS automation between cloud apps | Zapier | Your apps have maintained Zapier connectors and you want no servers to run. Node-RED has no ready connector for many SaaS products, so each one needs an HTTP node or custom node. |
| Device or sensor event flows | Node-RED | Devices speak MQTT, Modbus or serial, and the runtime must sit on a host next to them. Zapier cannot reach devices behind a private network. |
| Internal database and private API sync | Node-RED | The source systems are only reachable from inside your network. Zapier is hosted, so it needs internet-reachable endpoints. |
| HTTP webhook handling | Node-RED | You need to receive, transform and route high volumes of webhooks inside your own network, where task billing does not apply. |
| Teams without operators | Zapier | No one can patch a Node.js runtime, manage TLS, backups and editor access. A hosted service shifts that work to the vendor. |
| Regulated data that must stay inside the network | Node-RED | Records must not leave your environment. Confirm that your own controls cover the runtime, credentials and logs, since self-hosting moves that responsibility to you. |
| Non-developer business users building flows | Zapier | Staff need guided app setup and a broad connector catalog. Node-RED flows are edited in a browser editor and usually need someone comfortable with JSON and JavaScript. |
Where Node-RED lacks ready SaaS connectors
Many Zapier app triggers and actions have no drop-in Node-RED equivalent. Zapier's catalog is built around SaaS vendors' public APIs, and Node-RED's library of more than 5,000 community-contributed nodes covers a different mix, weighted toward devices, protocols, databases and general HTTP. A Zap that reads a CRM contact or posts to a ticketing tool may have no matching node at all. Community nodes also vary in maintenance: some are updated with each Node-RED release and some were last touched years ago, and each one is a third-party package you must review, pin and test after upgrades. Before committing, open the Node-RED library, search each app by name, and record whether a node exists, when it was last updated and whether it covers the triggers and actions your Zap uses, not just the app name.
Where no node fits, plan for HTTP request nodes and function nodes. Most SaaS APIs can be called with an HTTP request node, but you then own pagination, token refresh, rate limits, retries and error payloads that Zapier handles for you. Expect to write custom JavaScript in function nodes for field mapping and signature checks, and store API keys in the Node-RED credentials store rather than in flow JSON. Treat this as engineering work with a test plan per connector, and confirm with each vendor which authentication method and webhook options its API supports. Start the inventory from Zapier's JSON export. A Team or Enterprise owner can export Zaps as JSON, and an account owner or super admin can export every user's Zaps from Settings, Security and data. Build a table with one row per app, per trigger and per action, then mark each row as native node, community node, HTTP request or custom code. The count of rows marked HTTP request or custom code is the effort you will carry after cut-over, and it should drive the decision more than the number of Zaps.
Who controls data, hosting and identity once Node-RED is self-hosted
Self-hosting Node-RED moves data location, network exposure and access control from the vendor to your team. The cards below cover where flows and credentials sit, how you install the runtime, how the editor is protected and what logging and access review you must own. Confirm the compliance mapping with your assessors before go-live.
Data location inside your network
Node-RED stores flows as JSON files on the host where the runtime runs, so flow definitions, node configuration and any credentials saved in flows stay where you put them. Nothing in the flow model sends data to a hosted control plane. Check where the flows directory sits, who can read it, whether it is backed up, and whether it lands on storage in the residency zone your policy requires.
Install options and their ownership
The getting started guide documents installs with npm, an install script on Raspberry Pi, Docker, BeagleBone boards, experimental Android through Termux, and cloud platforms including AWS and Microsoft Azure. Each option changes who patches the operating system, the Node.js runtime and the container base image. Choose the path your operations team can patch on a fixed schedule, and record which Node.js version each environment runs.
Editor exposure on the network
The editor is not secured by default. Anyone who can reach the host's IP address can deploy changes, which in practice means they can alter automations that touch your systems. Before exposing anything, restrict the port to management networks or a reverse proxy, and confirm that HTTPS terminates at a point you control. Test the exposure from outside the approved network, not only from inside it.
Authentication through Passport and HTTP nodes
The editor and admin API can use username and password or OAuth and OpenID authentication through Passport. HTTP In nodes can separately require basic authentication, which protects endpoints that your devices or APIs call. These are two different controls, and each must be set on its own. Ask who owns the identity provider integration, how accounts are removed when people leave, and whether shared admin credentials are allowed.
Logging and access review ownership
Node-RED's runtime logs and the flow history are not a complete audit trail on their own, so your team must decide what to collect and where it goes. Define log retention, forward editor and deployment events to your central logging platform, and schedule a periodic review of who holds editor access and which flows they changed. These duties sit with your organization, not with a vendor or with DeployOpen by default.
Compliance mapping to confirm
Self-hosting gives you the controls, but it does not produce an attestation for them. Map the items above to the frameworks your organization is assessed against, and confirm with your auditors which evidence they will accept, such as configuration exports, access lists and change records. Treat this card as the checklist for that conversation, and confirm each mapping before relying on it.
Who runs and secures Node-RED: in-house, managed or partner
A platform or integration team that already runs Linux hosts, containers and certificates can absorb Node-RED as one more service. The team owns the full lifecycle: it chooses the Node.js and Node-RED versions, tests flows against new releases, and keeps the editor behind HTTPS with authentication. Node-RED 5.0 requires Node.js 22.9.0 or later, with Node.js 24 recommended, and runs only on a 64-bit OS, so the team must plan upgrades of the host as well as the application.
- Patching: the team tracks Node.js and Node-RED releases, including point releases such as those listed on the Node-RED GitHub releases page, and schedules rebuilds of Docker images or npm installs.
- Editor access: the team configures Passport-based authentication for the editor and admin API, and basic authentication for HTTP nodes, and reviews who holds deploy rights.
- Flow backups: flows are stored as JSON, so the team exports and versions them in Git and restores them to a staging instance before production.
- On-call: alerts for runtime crashes, failed flows and disk pressure route to the existing rotation, with a named owner for each flow.
- Cost: staff time for upgrades and review is the main recurring cost, and the team should estimate it from its own change process.
Before committing, confirm that someone on the team can read Node-RED flows and JavaScript function nodes well enough to review them.
Many organizations run Node-RED with one person who also has other duties, often a systems administrator or an engineer who built the first flows. This works when the flow count is small and the failure impact is limited, but it concentrates risk in one person. Documented procedures and a second trained person matter more here than tooling.
- Patching: the operator needs a fixed change window, because Node.js and Node-RED updates can break nodes from the community library. Pin versions and test before each upgrade.
- Editor access: the operator sets HTTPS and a login before the editor is reachable from the network, since the editor is not secured by default and anyone who can reach its address can deploy changes.
- Flow backups: a scheduled export or Git commit of the flows directory, with a documented restore step that the operator has actually rehearsed.
- On-call: usually none beyond business hours. The organization should state in writing which flows can wait until the next working day.
- Cost: the operator's time is paid from existing salaries, so the cost is hidden, not absent.
Ask who covers leave and departures, and whether the flows can be understood by someone without the operator's knowledge.
An implementation partner can plan, install, secure, back up and document a Node-RED deployment inside the client's own cloud account, data center or air-gapped network, and then support it under a retainer. The client keeps ownership of the hosts, the flows and the data. The partner's role is defined by a written scope, so responsibilities for each function should be listed before work starts.
- Patching: the scope should state whether the partner tests and applies Node.js and Node-RED upgrades, or only prepares them for the client to approve.
- Editor access: the partner can configure HTTPS and the chosen authentication method, and document how accounts are granted and removed.
- Flow backups: the scope should name the backup target, retention, and how often restores are tested.
- On-call: a retainer may or may not include out-of-hours response, so the client should ask for the hours and escalation path in the quote.
- Commercial options: FlowFuse, Inc., founded in 2021 by Node-RED co-creator Nick O'Leary, develops Node-RED for enterprise and industrial use. Its offerings are a separate commercial product, and a partner or the client may evaluate it alongside self-managed Node-RED.
Ask for a written responsibility matrix that names who acts for each function listed above.
What Zapier task billing and self-hosted Node-RED cost differently
Zapier cost is a recurring subscription that scales with task volume, so the bill rises as more of your internal data moves through Zaps. Node-RED has no license fee, since it is released under the Apache-2.0 license, but the cost does not disappear. It moves to the infrastructure that runs the Node.js runtime, the engineering time to build and maintain flows, monitoring, backups, and the staff who patch and secure the editor. For a team that mostly moves data between internal systems, devices and HTTP APIs, the comparison is a predictable vendor invoice against a mix of infrastructure and people costs that you control but must own. Confirm the Zapier plan tier and task volume with your account owner before you model either side, because those two figures set the recurring line.
The main cost drivers on the Node-RED side are the number of flows, the number of environments (for example, development, test and production), how many devices or endpoints the flows touch, and how often flows change. Each additional environment adds a runtime to host and a deployment path to govern. Build effort depends on how many Zaps you must rewrite by hand, since Node-RED has no import path from Zapier's JSON export, and on how many Zap steps call SaaS apps that lack a ready Node-RED node. Ask any implementation partner for a written quote that lists the connectors in scope, the flow count by category, the environments to build, the hosting target, and the support hours and response expectations after go-live. Ask for these items separately so you can compare them against the Zapier subscription line by line.
Put the same scope in front of both options before you compare totals. Include the cost of the editor hardening described in Node-RED's security guidance, such as HTTPS, authentication and access control for the admin API, because an unsecured editor is a cost you carry if you skip it. Include a budget for upgrades: Node-RED 5.0 raised the minimum Node.js version and dropped support for older Raspberry Pi models, so an install on old hardware may need a rebuild. Ask a partner to estimate those items in writing and to name which ones recur each year. The result is a model where one-time build and migration costs are visible, recurring infrastructure and support costs are visible, and Zapier's subscription is compared on the same terms.
Cost components on each side, one-time and recurring
This table lists each cost component for a Zapier setup and a self-hosted Node-RED setup, marking whether it is one-time or recurring and what drives it up. Read it as a checklist for building a quote or internal business case, since Zapier's task tier and Node-RED's zero license fee are only part of the total.
| Cost component | Who is paid or who spends effort | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Zapier subscription | Zapier, billed by plan and task tier | Recurring | Task volume, number of Zaps, premium apps and plan tier needed for admin features |
| JSON export of Zaps | Zapier account owner or super admin | One-time (inventory), repeated before any move | Only Team and Enterprise plans can import or export JSON, so a lower plan may require an upgrade first |
| Node-RED license | No license fee; Apache-2.0 under the OpenJS Foundation | Not applicable | None for the core project; check any paid add-ons or commercial support you choose separately |
| Infrastructure to host Node-RED | Your cloud account, data center or on-prem hardware team | Recurring | Runtime count, high availability needs, supported 64-bit OS and Node.js version, and backup storage |
| Flow build and connector development | Internal developers or an implementation partner | One-time per flow, then recurring for changes | Count of Zapier workflows to rebuild, custom HTTP and device logic, and gaps where no ready node exists |
| Editor hardening and access control | Platform or security engineers | One-time setup, then recurring review | HTTPS, Passport-based login or OAuth/OpenID, and network restriction, since the editor is not secured by default |
| Testing and validation | QA and workflow owners | One-time per migrated flow, then per change | Number of flows, data sensitivity and whether tests run against staging systems |
| Patching and upgrades | Platform engineers | Recurring | Node.js and Node-RED release cadence, node package updates and testing of flows after each upgrade |
| Backup and monitoring | Operations team and monitoring tools | Recurring | Flow JSON and credential backup, log retention and alerting on failed flows |
| Staff or partner time | Internal staff or a fixed-scope implementation partner | One-time for build, recurring for run and support | Skills in Node.js and the flow editor, on-call coverage and whether support is internal or retained |
How a move from Zapier to Node-RED usually proceeds
The sequence moves Zap logic into Node-RED flows in a controlled order, so each Zap is accounted for, each credential is recreated under control, and the editor is secured before anything carries production traffic.
Export all Zaps as an inventory
Account owners or super admins export Zap workflows as JSON from Settings, Security and data, and the export arrives by email. This is available on Team and Enterprise plans only, so Free and Professional accounts need to plan another way to list their Zaps. The export is an inventory for rebuilding, not a file Node-RED can import, so keep it as a reference for triggers, actions, filters and field mappings. Done means every active and paused Zap is listed in a single spreadsheet with its owner, trigger app, action apps and business purpose.
Map each Zap to a node pattern
For each inventory line, decide whether Node-RED has a maintained node for the app, whether a generic HTTP request or webhook node covers it, or whether a custom function is needed. Many Zaps that move data between internal systems, devices and HTTP APIs map cleanly. Zaps that depend on a SaaS connector with no community node need a separate decision, such as an HTTP pattern against the vendor API or keeping that Zap on Zapier for now. Done means each Zap has a recorded target pattern and an owner who accepts any gap.
Confirm node availability and licensing
Check the Node-RED flow library for the nodes you selected, and read each node's own license and maintenance status, since the library is community-contributed. Confirm the Node-RED version your team will run, and confirm the Node.js version and operating system requirements in the release notes. Done means a written list of nodes, versions and any unsupported connectors, approved by the team that owns the integrations.
Rebuild flows and recreate credentials
Build each flow in the Node-RED editor, starting with the simplest Zaps. Credentials do not transfer from Zapier, so create each one again in Node-RED's credential store, using dedicated service accounts with the smallest permissions the flow needs. Store secrets outside flow JSON where your process allows. Done means each flow runs against a test endpoint and each credential has a documented owner, scope and rotation process.
Secure the editor before production use
Node-RED's editor is not secured by default, so anyone who can reach its address could deploy changes. Before any production flow is live, enable HTTPS, configure authentication for the editor and admin API through Passport, and set basic authentication on any HTTP nodes that accept requests. Restrict network access to the editor to administrators. Done means an unauthenticated request to the editor and admin API is refused and a test user without rights cannot deploy.
Run flows in parallel and compare results
Turn on the rebuilt flows alongside the live Zaps for a period agreed with the business owners, and compare outputs record by record. Check retries, error paths, timing and duplicate handling, because Zapier and Node-RED handle failures differently. Make sure each flow writes to a staging target before the production target is connected. Done means differences are logged, explained and fixed, and the business owner signs off on each flow.
Cut over and retire the Zaps
Switch each source to its Node-RED flow in an agreed order, disable the matching Zap rather than deleting it, and keep the JSON export as a record. Monitor the first runs closely and confirm that alerts reach the people who need them. Once the rollback window closes, delete the Zaps and revoke the Zapier connections. Done means every inventory line shows its new owner, its Node-RED flow, and its retirement date, and no Zap still sends data.
Questions buyers ask before switching from Zapier to Node-RED
How much effort does a switch from Zapier to Node-RED take?
The effort depends mostly on how many Zaps you run, how many of them depend on SaaS connectors that Node-RED does not ship with, and how much logic sits in multi-step branches. Node-RED is a flow editor on a Node.js runtime, so each Zap becomes a flow of nodes that you wire together and test. Zapier's JSON export is useful as an inventory of trigger, action and field mappings, but it does not import into Node-RED, so every flow is rebuilt by hand. Teams with a small set of internal, device or HTTP-based Zaps usually have the least work. Teams with many SaaS triggers need to find a community node or write an HTTP-based flow for each one, which adds time. Ask any implementation partner to inventory your Zaps first and sort them by connector type before agreeing on scope.
Can an internal team run Node-RED without outside help?
Yes, many internal teams run Node-RED on their own, provided they have someone comfortable with JavaScript, Linux services, reverse proxies and backups. Node-RED installs locally with npm, on a Raspberry Pi with an install script, with Docker, or on cloud platforms such as AWS and Microsoft Azure, according to its getting started guide. The harder part is ongoing operation: patching the Node.js runtime and Node-RED itself, managing flow backups, handling credentials, and monitoring uptime. Node-RED 5.0 requires Node.js 22.9.0 or later, with Node.js 24 recommended, so runtime upgrades are a standing task. If nobody on staff owns those duties, plan for a retainer that covers upgrades, backups and support rather than a one-off build.
How long does a Zapier to Node-RED rebuild take?
The timeline is set by the number and complexity of flows, not by the Node-RED install itself, which is quick. Drivers include the count of active Zaps, how many need custom HTTP calls or new nodes, how many require testing against live systems, and whether you need a change window for cutover. Parallel running is a common way to reduce risk: keep Zapier active for a Zap until its Node-RED equivalent has produced matching output. Confirm the schedule, deliverables and acceptance tests in writing before work starts. A fixed-scope agreement from DeployOpen follows the written scope and sets the timeline for that scope.
What does a Node-RED project need from our team?
A Node-RED project needs three things from your side: people who understand the flows, access to the systems they touch, and ownership of the credentials. Node.js and JavaScript skills help for function nodes and custom code, and someone should understand JSON, since flows are stored as JSON. Network access is needed from the Node-RED host to every internal API, database or device, which is often where the work takes longest. Credentials for SaaS and internal systems should be created and held by your team, not shared with an outside party, and rotated under your own process. Confirm these points early so the scope reflects who will hold the access after the project ends.
Does Node-RED import Zapier export files?
No, Zapier export files do not import into Node-RED. Zapier allows importing and exporting Zap workflows only as JSON files, and only on Team and Enterprise plans, according to Zapier's help center. That file describes Zapier's own structure, including its app actions and connection references, and Node-RED uses its own flow format and node types. Use the export as a list of what each Zap does, then rebuild each flow in the Node-RED editor. Connections also need to be recreated with credentials your team controls. Export files from admin accounts can contain Zaps from every user, so review access before sharing them with a partner.
How is the Node-RED editor secured?
The Node-RED editor is not secured by default, so anyone who can reach its IP address can deploy changes. Before exposing it to any network, you need to configure authentication. The securing documentation describes HTTPS, username and password or OAuth and OpenID authentication through Passport for the editor and admin API, and basic authentication for HTTP nodes. Keep the editor on an internal network or behind a reverse proxy with access controls, and back up flows and their credentials securely. Confirm with your security team how these settings fit your identity provider and logging standards, and include a review of them in the project scope.
What does Node-RED's Apache-2.0 license mean for internal use?
Node-RED is released under the Apache-2.0 license, which permits internal business use, modification and distribution under its terms, with no per-task or per-user fee for the software itself, according to its GitHub repository. Licensing should still be reviewed by your legal team for the nodes you add, since the Node-RED flow library contains over 5,000 community-contributed nodes, each with its own license. Check the license of every node before it enters production, and record the versions you deploy. Your remaining costs are the hosting, the people who build and run the flows, and any support contract you choose.
How DeployOpen helps evaluate and implement Node-RED
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Node-RED. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. Before any flow is moved, the first deliverable is usually an inventory of the existing Zaps, grouped by what they touch: internal databases, devices, HTTP APIs and SaaS apps. That inventory is what turns a vague plan into a list of decisions, and it shows where Node-RED's node library covers a workflow and where a connector has to be built, bought or dropped.
The connector gap assessment is the step that most affects effort. For each SaaS connection a Zap uses, the team checks whether a maintained Node-RED node exists, whether an HTTP request node can call the vendor's API with acceptable authentication, and who will own the token rotation and API version changes afterward. Node-RED's editor is not secured by default, so the same review covers editor hardening: enabling HTTPS, configuring username and password or OAuth and OpenID authentication through Passport, setting basic authentication on HTTP nodes where they are exposed, and restricting which networks can reach the editor and admin API. DeployOpen can run security testing against the deployed editor and flows, and the findings feed a remediation list that the client owns.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ask any implementation partner, including DeployOpen, to state in the written scope which controls it will configure and which evidence it will hand over, and confirm with your own assessor which of those artifacts they will accept. Before signing, confirm the Node-RED version and Node.js runtime requirements for your environment against the Node-RED 5.0 release post, and agree in writing who applies patch releases after handover.
