Open-source alternatives to Make: self-hosted options

Which open-source Make alternative fits your Make scenarios

If you are renewing Make, reacting to a pricing or licensing change, or under a data residency requirement that your current vendor cannot meet, the short answer is that n8n, Activepieces and Node-RED each fit different kinds of scenario. n8n is the closest match for multi-step, API-heavy scenarios that branch, transform data and call many services. Activepieces suits teams that want a similar hosted-style builder with a large piece library and a permissive core license. Node-RED fits event-driven and device-oriented flows, such as reacting to messages or sensor data, more than typical SaaS-to-SaaS record sync. Start by sorting your scenarios into those types rather than choosing one platform for all of them.

The reason to look at alternatives is usually lock-in and control, not features alone. Make lets you export a scenario as a blueprint .json file that contains the modules, module settings and mapped values, which gives you a rebuild inventory. However, connections are not included in the export, so every app credential must be recreated on the new platform, and scenarios that depend on many connections will take the most effort to restore. Also confirm the license terms of each candidate before you commit. n8n's main codebase is under the Sustainable Use License, and files with .ee in their name need an n8n Enterprise License. Activepieces is MIT licensed except for content under packages/ee/ and packages/server/api/src/app/ee, which has a separate commercial license. Ask your legal team to review the exact terms for your intended internal or commercial use.

Before you pick a platform, export every scenario you run, list the connections each one needs, and mark which ones your internal security team must re-approve. Then run one representative scenario from each type on a candidate platform in a test environment and compare how the visual canvas handles routers, error routes and data mapping. Your rebuild plan should record who owns each credential, which scenarios are business critical and which license edition you need. If a scenario depends on a connector that is missing or unclear on the candidate platform, confirm its status with that vendor or in your own environment before you plan the migration around it.

Three open-source editors that can host Make-style automations

Make scenarios map most directly onto visual, node-based editors that can run on your own infrastructure. n8n, Activepieces and Node-RED differ in license terms, editor style and the kind of automation each handles best, so the choice should follow your team's skills and your licensing constraints. Windmill is a code-first alternative for teams that prefer scripts to a canvas.

n8n: broad connectors, licensing to check

n8n is a visual workflow editor with a large connector library and a node-based canvas that is the closest in spirit to Make scenarios. Its main codebase is under the Sustainable Use License, which permits internal business use and non-commercial use, so check whether your use fits those terms. Without a license key, n8n runs as the Community edition. Adding a Business or Enterprise license key enables those editions, and files with .ee in their names require a valid Enterprise License. Confirm which features your scenarios need before you choose an edition.

Activepieces: MIT core, separate commercial code

Activepieces is a visual automation builder whose core is MIT licensed, which suits teams that want to modify and redistribute the core freely. Content under packages/ee/ and the server ee folder carries a separate commercial license, so any feature you rely on from those folders needs a commercial agreement. The main trade-off is that you must map which Make modules you use to pieces that exist in the open-source core and which sit in commercial folders. Ask the vendor to confirm the license status of each feature in your plan.

Node-RED: flow-based and event-driven

Node-RED is a low-code, flow-based tool for event-driven applications, released under the Apache-2.0 license and hosted by the OpenJS Foundation. It fits Make scenarios that react to device messages, MQTT topics, webhooks or industrial data more than scenarios built on SaaS app connectors. Its editor is a flow canvas that many operations teams already know, but its library of SaaS connectors is smaller than n8n's or Make's. Check that every app connector your scenarios need exists as a maintained node before you commit.

Windmill: code-first for script-driven teams

Windmill is a code-first option for teams that want scripts and version-controlled logic rather than a visual builder. Source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, but prebuilt Community Edition images include proprietary code that is free for internal use, and managed services or reselling need a commercial license. Plan for developers to write and review each automation, and confirm which image you will deploy before you rely on those terms.

How Make's main capabilities map to each open-source option

This table maps the Make capabilities teams rely on to n8n, Activepieces and Node-RED, with coverage notes for each. Read the coverage column as a starting point: most rows need a hands-on check of the specific connectors and modules your scenarios use before you assume parity.

Make capability	n8n	Activepieces	Node-RED
Visual scenario canvas	Node-based canvas for building workflows; confirm node behavior matches your Make modules	Visual flow builder with steps and branches; confirm step types cover your scenarios	Flow-based editor in the browser; well suited to event-driven flows but less oriented to SaaS app steps
Scheduled and webhook triggers	Schedule and webhook trigger nodes available; confirm payload handling for your sources	Schedule and webhook triggers available; confirm retry and payload behavior in your version	Inject and HTTP input nodes cover schedules and webhooks; timing logic is built by hand
Routers and filters	IF and Switch nodes handle branching and filtering	Branch and conditional steps handle routing; confirm nesting limits you depend on	Switch and change nodes handle routing; complex logic can become hard to read in large flows
Iterators and aggregators	Split-in-batches and aggregate behavior; confirm it matches Make's array handling	Loop steps are available; confirm aggregation patterns with your data shapes	Split and join nodes handle sequences; aggregation requires explicit message handling
Error handling and retries	Error workflows and retry options per node; confirm retry settings for each connector	Retry and error handling settings exist; confirm behavior for each step type	Catch nodes and status messages; retries are usually built with custom flow logic
Data mapping	Expression editor with access to prior node output; confirm syntax differences from Make mappings	Mapping through dynamic values in steps; confirm it covers your nested data	Message objects and function nodes; mapping is done in code or change nodes
Scenario versioning	Workflows can be exported as JSON and kept in Git; confirm version history features for your edition	Flow versions are supported; confirm rollback behavior in your deployment	Flows are stored as JSON and usually versioned in Git; no built-in version history view
Team roles and access	Role controls depend on edition; confirm which roles and SSO options your license includes	Team and role features depend on edition; confirm what the open-source build provides	No built-in multi-user roles; access is usually handled by the surrounding platform
Built-in connectors	Large catalog of app nodes; confirm every Make app module you use has an equivalent or HTTP fallback	Growing piece library; confirm coverage for your specific apps before planning	Strong for IoT, MQTT and industrial protocols; SaaS connectors are limited and often community-maintained

Using Make blueprint exports to plan the rebuild

Treat each Make blueprint as an inventory of the scenario, not as a file you can load into another editor. Make lets you export a scenario as a blueprint .json file that contains the scenario's modules, module settings and mapped values. Connections are not included, so every credential the scenario depends on must be recreated in the target platform after you rebuild it. Before any build work starts, export every scenario you plan to move, store the files in version control, and create one planning sheet per scenario that lists its trigger, each module in order, the fields mapped into each module, and the connection each module needs. The connection column is the one most teams underestimate, because a single app connection often serves several scenarios and needs an owner who can re-authorize it in the new environment.

Translating the structure takes more judgment than copying settings. Make's routers split a flow into parallel branches, so map each branch to an explicit conditional path in n8n, Activepieces or Node-RED and record the condition logic exactly as the blueprint states it. Iterators and aggregators process arrays item by item and then recombine results, so confirm in each target editor how items are passed between nodes and whether the output shape matches what downstream steps expect. Error routes deserve their own review: in the blueprint, note which modules have error handlers, what they do (retry, ignore, or send a notification), and whether the scenario depends on partial completion. Test each rebuilt path with sample data that exercises the error and empty-array cases, because those are where rebuilt flows most often diverge from the original.

Use the blueprint as a planning aid, and confirm the details with a test run in your environment. Field names, module names and mapping syntax differ between Make and each open-source editor, so expect to rewrite mappings by hand even where the logic is identical. Check the Make help center's blueprints guide for the current export and import behavior, since the scope of what is exported may change. Identify scenarios that call custom or community modules, because those have no direct equivalent in the target and need a replacement connector or a small custom step. Finally, decide with the business owner which scenarios are retired rather than rebuilt, and record that decision, so the migration inventory shows what was intentionally dropped.

What Make subscriptions and self-hosting each cost over several years

This table compares the recurring and one-time cost components of staying on Make against self-hosting n8n, Activepieces or Node-RED. No vendor prices were supplied, so use the drivers in each row to read your own Make invoice and to check quotes line by line. The main takeaway is that self-hosting shifts spend from a per-operation subscription to infrastructure, labor and licensing, and the one-time rebuild is where most of the early effort sits.

Cost component	Who is paid, and for what	One-time or recurring, and what drives it
Make subscription	Make, for the plan tier and usage your scenarios consume	Recurring. Driven by plan tier, operations or task volume, premium app or feature use, and how many scenarios run on schedules. Check your invoice for these drivers.
Infrastructure hosting	Your cloud provider or data center, for compute, PostgreSQL, storage, backups and networking	Recurring. Driven by worker count, execution volume, high availability design and retention of execution logs. Ask for sizing assumptions in writing.
Licensing (n8n Business or Enterprise)	n8n, only if you need features from its paid editions under a license key	Recurring if needed. The Community edition runs without a key under the Sustainable Use License. Confirm which features your scenarios depend on before budgeting.
Activepieces commercial terms	Activepieces, only if you deploy code under its separate commercial license (packages/ee and related ee paths)	Recurring if needed. Confirm whether the MIT-licensed core covers your connectors and features, and get the terms in writing.
Migration rebuild	Implementation partner or internal engineers, to recreate scenarios from blueprint JSON and reconnect every app	One-time. Driven by scenario count and complexity, number of connections to recreate, and custom logic. Blueprints do not carry connections, so reconnecting is always counted.
Testing and cutover	Internal QA or a partner, to compare outputs, error handling and timing against Make runs	One-time, with some ongoing regression testing. Driven by how many scenarios touch regulated or customer data.
Backup, upgrades and support	Internal platform team or a partner on retainer, for patching, version upgrades, backup restores and incident response	Recurring. Driven by upgrade frequency, change control requirements and the response expectations written into your contract.
Internal skills	Your staff, for building, reviewing and operating flows in the new editor	Recurring and one-time training. Driven by team size, how many builders exist, and how much flow logic lives in code nodes.

What you give up when leaving Make and the usual workarounds

Moving scenarios off Make is rarely a one-to-one swap. The gaps below cluster around connectors, error handling, hosted operation, permissions and credentials, and each one has a known workaround. None of the open-source platforms in this guide matches Make feature for feature, so confirm each gap against your own scenarios before you commit.

Connector coverage for niche apps

Make's catalog includes many vendor-specific apps that your open-source editor may not ship with. Before planning, list every app and module used across your scenarios and check whether n8n, Activepieces or Node-RED offers a native node for each one. Where none exists, a generic HTTP request node against the vendor's REST API is the usual fallback, and it moves the authentication and pagination logic onto your team. Confirm each niche connector early, because it often decides the timeline.

Different error handling and mapping syntax

Make's error routes, break and resume behavior, and its mapping syntax do not carry over directly. Each editor expresses retries, error branches and expressions differently, so a scenario that depends on a specific error route needs to be redesigned rather than copied. Document how each failure path behaves today, then write equivalent tests with sample payloads that exercise those paths in the new platform.

Loss of hosted operation and scheduling

Make runs your scenarios on its own infrastructure and handles scheduling, uptime and execution history for you. Self-hosting moves those duties to your team, including the scheduler, worker capacity, database backups and restarts after failures. Ask who will own on-call response for failed runs, and set up alerting on execution errors before the first production scenario moves.

Team and permission model differences

Make's organization, team and role structure does not map one-to-one onto the role model in n8n, Activepieces, Node-RED or Windmill. Some features that matter for separation of duties may sit in paid editions or require configuration you have not used before. Map each Make role to a target role, then verify who can view, edit, run and export each workflow in the new platform.

Recreating every connection by hand

Make's blueprint export contains modules, module settings and mapped values, but connections are not included and must be recreated after import. Every credential, OAuth grant and API key needs to be created again in the target platform, and the new connections should use service accounts with least privilege where the vendor allows it. Keep an inventory of connection owners so that a departing employee does not break production flows.

Parallel run before cutover

The most common workaround for behavioral gaps is a parallel run period, where the old Make scenario and the new workflow process the same inputs and their outputs are compared. Use a staging copy of the target system or a read-only sink to avoid duplicate writes. Agree on acceptance criteria, such as matching record counts and error rates, before the parallel run starts, and keep Make active until those criteria are met.

Which open-source option suits your Make situation

When the main driver is where scenario data is processed and stored, the question is whether the platform can run entirely inside your own cloud account, data center or network. n8n, Activepieces, Node-RED and Windmill can all be deployed on infrastructure you control, which keeps workflow executions and their payloads within your boundary. Node-RED is a practical fit for event-driven flows close to operational systems, while n8n and Activepieces better match business integrations that call SaaS APIs.

Deployment options: n8n documents installs with Docker Compose and major cloud providers, so confirm the topology your residency rules allow.
Database placement: Windmill documents external PostgreSQL options such as AWS RDS, GCP Cloud SQL and Azure, which helps when the database must stay in a specific region.
Connector egress: Identify which target APIs your scenarios call, since the data still leaves your boundary when a workflow reaches a SaaS endpoint.
Make's residency: Confirm with Make which regions its hosted service offers and whether that meets your requirement.
Secrets storage: Check where each platform stores connection credentials and who can read them.

Before choosing, verify that the platform's deployment model and each required connector run in your target environment, and document where every execution log and credential is held.

How moving off Make works, step by step

The sequence turns a set of Make scenarios into a tested, self-hosted set of workflows, with each scenario moved, verified and retired on its own schedule. It keeps business logic and data intact while credentials and connections are rebuilt under your control.

Inventory scenarios from blueprint exports
Export each Make scenario as a blueprint .json file from the scenario's options, then list every scenario with its owner, trigger, modules, schedule and the systems it touches. Your team owns this inventory because only the people who run the scenarios know which ones business processes depend on. Flag scenarios that are inactive, duplicated or unused, since these can be retired instead of rebuilt. The step is done when every active scenario has a blueprint file and a one-line purpose recorded in a shared register.
Export data and document mappings
Read each blueprint to capture module settings, field mappings, filters, error handlers and data store references, since these carry the logic you must reproduce. Blueprints do not include connections, so write down which app account each module uses and who holds its credentials. Export any Make data stores or lookup tables as separate records, because they are not part of the scenario file. The step is complete when each scenario has a mapping document that a second engineer can follow without access to Make.
Choose the target editor and deployment
Select n8n, Activepieces or Node-RED for each workload based on the connectors you need, the visual builder your team prefers and the license terms that apply to your use. Confirm the license edition and any enterprise features with the vendor before you commit, because license files and editions differ between projects. Decide where the platform runs, such as your cloud account, a data center or an air-gapped network, and who will operate it. The output is a short decision record per scenario group naming the editor, hosting model and owner.
Recreate connections and credentials
Create each app connection in the new platform using service accounts or least-privilege API keys where the target system supports them, rather than copying personal logins from Make. Store secrets in your approved secrets manager or the platform's credential store, and record owner and rotation rules for each one. Your security team should review scopes against the mapping document. The step is done when every connection in the register has been tested with a read-only call and its owner has signed off.
Rebuild and test one pilot scenario
Choose one low-risk, well-understood scenario and rebuild it in the target editor from the mapping document, not by importing the blueprint, because Make's file format does not map directly to other platforms. Run it against real data in a non-production environment and compare outputs, record counts and error handling with the Make run history. Document differences and fix the logic before moving on. The pilot is finished when outputs match for an agreed set of test cases and the team has a repeatable rebuild pattern.
Run both platforms in parallel
Keep the Make scenario active while the rebuilt version runs in shadow mode or on a sample of inputs, and compare results daily. Watch for duplicate writes to downstream systems, since two live scenarios can act on the same record. Confirm alerting and retry behavior on the new platform, because failures will no longer surface in Make's interface. The parallel period ends when the team agrees the outputs match over a sustained period that the owners of each process have approved.
Cut over scenario by scenario
Switch each scenario to the new platform in a planned window, turn off the Make version, and confirm that scheduled and webhook triggers now fire from the new host only. Update any external systems that call Make webhooks to point to the new endpoints. Your operations team owns the rollback plan for each cut. The cutover is complete when every scenario in the register has a confirmed owner, a live endpoint and a documented rollback path.
Decommission the Make subscription after retention
Keep blueprint exports, mapping documents, run logs and final outputs in your records system for a retention period set by your legal, compliance and finance teams. Confirm with Make how long your account data remains available after you cancel, and export anything you need before the account closes. Remove stored credentials from Make and revoke any API keys issued to it. The subscription ends when the retention obligations are documented and the account has been closed and verified as no longer in use.

Questions buyers ask before moving off Make

How much effort does moving off Make actually take?

Effort depends mostly on how many scenarios you run, how many modules each one uses, and how much custom logic sits in filters, routers, iterators and error handlers. A scenario with a few standard steps is a small rebuild. A scenario that calls private APIs, transforms nested JSON or runs on a schedule with retries takes longer to reproduce and test. Make's blueprint export gives you a complete inventory of modules and mapped values per scenario, so the first task is counting and grading scenarios by complexity. Ask any implementation partner for a written scope that lists each scenario, its owner and its acceptance test before agreeing on a timeline.

Can our team migrate from Make without outside help?

Yes, if you have engineers who can run Docker Compose, manage secrets and read API documentation for each connected service. Internal teams usually handle simple scenarios well and struggle with the operational work: backups, upgrades, TLS, monitoring and on-call response for a platform that now runs in your network. Consider which skills are missing today, who will own the platform after launch, and whether you need training or a fixed-scope engagement to cover the gap. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and offers ongoing support as a retainer.

How long should a parallel run last before we switch off Make?

There is no standard duration, so set the exit criteria before you start. Run each rebuilt scenario alongside its Make original until outputs match on real data for every business cycle that matters, such as month-end or a weekly batch. Scenarios with financial, clinical or customer-facing effects usually need a longer comparison and documented sign-off. Confirm the exact comparison method, error alerting and rollback steps with your risk owner, and record them in the migration plan.

Which open-source option is cheapest to host?

Compare hosting cost by components, not by license fee, because the open-source platforms in this comparison are all free to download. Your cost comes from compute for the application and workers, a PostgreSQL database, storage, backups, networking, monitoring and the engineering time to run it. n8n documents Docker Compose and major cloud providers as hosting paths, and Windmill documents Docker Compose, Kubernetes Helm charts and external PostgreSQL services such as AWS RDS, GCP Cloud SQL and Azure. Node-RED is lightweight to run. Ask each vendor or partner for a hosting sizing based on your execution volume, and model it against your current Make plan.

Can we import a Make blueprint directly into n8n or Activepieces?

No. Make's blueprint JSON export contains modules, module settings and mapped values, which makes it a useful design document, but it does not carry over as a runnable workflow in another editor. Connections are not included in the export and must be recreated after import in Make, and the same applies when you rebuild elsewhere. Plan each scenario as a rebuild: map each Make module to the closest node or piece in the target platform, note gaps, and recreate credentials in the new platform's vault. Test each connector before you switch traffic over.

What license terms apply to self-hosted n8n or Activepieces?

Read the license for the exact edition you deploy. n8n's main codebase is under the Sustainable Use License, which permits use for internal business purposes or non-commercial or personal use. Files with .ee in their name require a valid n8n Enterprise License, and n8n's hosting documentation says that without a license key it runs as the free Community edition, while a Business or Enterprise key enables those editions. Activepieces is MIT (Expat) licensed, except content under packages/ee/ and packages/server/api/src/app/ee, which is under a separate commercial license. Ask your legal team to confirm whether your use, including any service you offer to customers, fits these terms.

What does the migration need from our internal team?

Plan for four roles: a platform owner who runs the environment, builders who recreate scenarios, reviewers who own business outcomes for each workflow, and a security contact who approves credentials, network paths and access. Builders need access to every connected system and its API credentials, which should be issued under least privilege. Reviewers must be available during the parallel run to confirm outputs. Confirm these time commitments with your managers before work starts, because the parallel run and cutover often stall when the people who know each workflow are not available.

How DeployOpen scopes, migrates and supports a Make replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Make replacement, that means turning your scenario inventory into a written scope, rebuilding the flows on the platform you choose, and handing over a system your team can run.

How we scope

Inventory every Make scenario, its triggers, modules, schedules and error handling before any build starts.
Export each scenario's blueprint JSON to capture modules, settings and mapped values, then record which connections must be recreated.
Agree the scope, deliverables and timeline in writing, since most engagements are fixed-scope.

How we build

Rebuild each scenario on the chosen platform, whether n8n, Activepieces or Node-RED, and document where behavior differs from Make.
Recreate app connections with credentials stored in your secrets management, not copied from Make, since blueprints exclude them.
Test each rebuilt flow against sample data and known outputs, and run the old and new scenarios side by side during cutover.

How we hand over

Deliver hosting, configuration and runbook documentation covering installation, upgrades, backups and access control.
Walk your operations and automation owners through each flow, its dependencies and its alerting so they can maintain it.
Document license terms for the edition you deploy, including any features that require a commercial license.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Plan upgrades, backup restores and connector maintenance as recurring operational work with a named owner.
Ask for a written quote based on your scenario count, connector list and hosting model before committing to scope.

Open-source alternatives to Make: replacing scenarios with self-hosted automation