Make or n8n: which fits your situation
If your Make credit bill keeps growing, a data residency rule rules out a US or EU hosted zone, or your scenarios must reach systems inside a private network, the question is whether you want a managed service or a runtime you operate yourself. Make fits teams that accept its managed model, are comfortable with a US or EU zone, and have no appetite for running infrastructure. Self-hosted n8n fits teams that need the runtime inside their own network, want custom JavaScript or Python code and AI nodes in the same workflows, and prefer a cost that tracks hosting rather than execution volume. Make's credit model is worth comparing directly with n8n's, since n8n counts one execution per whole workflow run regardless of step count, according to its pricing page, while Make bills by operations.
Three decisions should drive the choice. The first is licensing acceptance. n8n's main codebase is under the Sustainable Use License, which permits internal business use but not hosting it for third parties or distributing it commercially, and files with .ee in their names need a valid n8n Enterprise License. Legal and procurement should read the n8n LICENSE file against your intended use before a pilot starts. The second is operating effort. A self-hosted n8n instance needs an owner for upgrades, backups, the encryption key and monitoring, and features such as SSO and LDAP, Git environments and log streaming sit on the Business and Enterprise plans, so confirm which edition you need. The third is how many scenarios need rebuilding. Make blueprints carry modules and mapped values but not connections, so every credential must be recreated, and the effort scales with the number of scenarios and their branching.
A useful test is to export your scenarios, count the ones that touch on-premises systems or regulated data, and estimate how many depend on Make-only modules. If most of your volume is cloud SaaS with a US or EU zone acceptable, staying on Make may remain the lower-effort option. If a large share needs the internal network or custom code, the migration case for self-hosted n8n is stronger. Ask any vendor or partner for a written scope that lists the scenarios, connections, edition and support model, because those four items determine both the one-time rebuild cost and the recurring hosting and support cost.
Which option fits which scenario
This table maps common buyer situations to the platform that usually fits better, along with the condition that makes it so. Read each row as a starting point: confirm the condition against your own volumes, network and team before deciding. The main takeaway is that Make suits teams that want a managed visual service in a US or EU zone, while n8n suits teams that need the runtime in their own network or want code and AI steps under their control.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Credit consumption grows with high-volume scenarios | Self-hosted n8n | Your scenarios run many steps per record and Make credit use rises with each operation. n8n counts an execution as one run of a whole workflow, so confirm your execution count and hosting cost before comparing. |
| Workflows must run inside a private or air-gapped network | Self-hosted n8n | Make runs as a hosted service with no self-hosted edition, so the runtime cannot sit inside your network. n8n can be installed in your own infrastructure, subject to your team's ability to operate it. |
| You need a choice between US and EU hosting | Make | Make offers US and EU zones chosen at account creation. Choose Make if a managed zone meets your residency rules; choose n8n if you need the data location to be your own data center. |
| You need custom code or AI steps | Self-hosted n8n | n8n combines its visual canvas with custom JavaScript or Python code. Confirm that your code steps and AI integrations fit n8n's Sustainable Use License and your internal use case. |
| Your team has no platform operators | Make | Self-hosting adds patching, backups, upgrades and monitoring to someone's job. Choose Make if no one can own that work; if you self-host, plan who owns the runtime after go-live. |
| Your use is internal business automation | Self-hosted n8n | The Sustainable Use License permits internal business use. Confirm with counsel if you plan to offer workflows to customers or distribute the software. |
| You need high availability or multiple main instances | Make | Multi-main setup in n8n is limited to Enterprise self-hosted deployments. Choose Make or confirm your n8n edition and architecture if you need resilience at this level. |
Where your data runs and who controls it
Make runs in US or EU zones that DeployOpen cannot move into your network, while self-hosted n8n puts the runtime, credentials and logs under your control. The cards below cover the decisions that follow from that difference, from encryption keys and identity to the evidence your own team must produce.
Choosing a Make zone or your own network
Make is a hosted service with US and EU zones, so scenario data, execution history and connection credentials are processed in Make's infrastructure. Self-hosted n8n places the runtime in your cloud account, data center or air-gapped network, and the data stays where your team deploys it. Before deciding, confirm with Make which zone applies to your account and which sub-processors handle data, and map which systems the scenarios must reach.
Shared encryption key in queue mode
In n8n queue mode, the main instance hands executions to workers and webhook processors through Redis, and those processes read credentials from PostgreSQL. Every worker and webhook processor therefore needs the main instance's encryption key, so the key becomes a shared secret across all of them. Store it in your secrets manager, restrict which hosts can read it, and plan how you rotate it, because a key change affects every process at once.
SAML single sign-on for Okta and Azure AD
SAML single sign-on in n8n is included in the Business and Enterprise plans, and n8n publishes step-by-step setup guides for Okta Workforce Identity and Azure AD. Confirm that your identity provider's certificate rotation, group mapping and deprovisioning process covers n8n accounts. Community edition installs do not get this option, so plan identity controls before choosing an edition.
Licensing that governs internal use
n8n's main codebase is under the Sustainable Use License, which allows use for your own internal business purposes and non-commercial use, while files with .ee in their name need a valid Enterprise License. Ask legal to confirm that your intended use, including any service you offer to customers, fits those terms. Make's hosted service is governed by its own terms of service, so compare the two agreements on data processing and subprocessors.
Compliance evidence your team must produce
Moving from a Make zone to your own network moves responsibility for logging, access reviews, backup testing, change records and encryption key handling to your organization. DeployOpen can plan the controls, configure them and prepare the evidence. Independent auditors and certification bodies issue any attestation or certification, so confirm early which assessment your regulator or customers require and what that auditor will sample.
Logs and audit trails to confirm
Execution history and audit information live where the runtime lives, so the question is which records you can retain and export. In n8n, log streaming is listed among Business and Enterprise plan features, and audit logs are limited to Enterprise. Ask Make which execution logs it keeps, for how long, and how you can export them, then compare that with the logs your own stack would forward to your SIEM.
What n8n's Sustainable Use License allows
n8n is source-available under the Sustainable Use License, not an OSI-approved open-source license. The license lets you use and modify the code for your own internal business purposes or for non-commercial or personal use. It allows distribution only free of charge and only for non-commercial purposes. For a Make replacement, the practical reading is that running n8n inside your own organization to automate your own processes fits the grant, while offering n8n-powered automation to customers as a product, managed service or resold tool does not without a separate arrangement. Before you commit, write down each intended use (internal operations, client-facing services, partner delivery, embedded workflows) and check it against the license text in the n8n LICENSE file.
Files with .ee in their name or directory sit outside the Sustainable Use License and need a valid n8n Enterprise License. Your build or deployment process should not pull in those paths without a license in place, so ask your platform team to confirm which directories are in the image and source tree you deploy. Editions are separated by license key rather than by separate software. The Community edition runs without a key, while adding a Business or Enterprise license key enables those editions. Confirm with n8n which features each key unlocks, since the features that matter most to Make buyers, such as SSO, environments with Git and log streaming, are tied to the paid plans on the n8n pricing page.
Ask n8n or your legal counsel to confirm your specific use before rollout, particularly if you plan to resell, white-label, embed n8n in a product or operate it for other companies. Get the answer in writing and keep it with your architecture records, because the license terms and the edition rules are the baseline for your later cost comparison and migration plan. This review is a decision for your organization and its advisers. DeployOpen can help document the deployment and the license-relevant components in your environment, but it does not give legal advice on licensing.
Risks to weigh before committing
Moving from Make to self-hosted n8n shifts licensing, edition choices and day-to-day operations onto your team. The five risks below are the decisions that most often surprise buyers, and each one has a check you can run before you sign anything.
Licensing fit for internal use
n8n's main codebase is under the Sustainable Use License, which allows use for your own internal business purposes or non-commercial use. It does not allow you to run n8n as a service for customers or redistribute it for commercial gain. If your automations serve external clients or partners through a hosted offering, have counsel confirm that the use falls within the license before you rebuild scenarios. Make's terms cover a different relationship, so compare the two agreements as written.
Feature gating between editions
The free Community edition runs without a license key, but SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. Multi-main high availability is limited to Enterprise self-hosted deployments. Before choosing an edition, list which Make features your team relies on, such as SSO, audit history or version control, and confirm which n8n tier provides each one. Files with .ee in their name require an Enterprise License and are not covered by the Sustainable Use License.
Operating queue mode
When volume grows, n8n queue mode splits the main instance from a pool of workers that rely on Redis to pass executions and PostgreSQL to store workflow data. Someone must provision, back up, monitor and tune both services. Every worker and webhook processor also needs the main instance's encryption key so it can read stored credentials, which makes key handling a security task. Ask your platform team who owns these components and how key rotation would work.
Credential migration
Make's blueprint export includes scenario modules, settings and mapped values, but connections are not included and must be recreated after import. The same applies to Make's own export of scenarios. Plan a credential inventory for every app connection, record which account owns each one, and decide who re-authorizes each connection in n8n. Test each rebuilt workflow with live credentials in a staging instance before you switch traffic, since mapped values alone will not restore access.
Staff for upgrades and patches
A self-hosted n8n instance needs a named owner for version upgrades, security patches, database maintenance and restore tests. Make removes that work from your team because the vendor runs the service. Estimate the recurring hours your team can commit, and ask whether an implementation partner's retainer would cover upgrades and testing. Review the n8n release notes before each upgrade so breaking changes in nodes or credentials do not surprise your workflows.
How a move from Make to n8n runs
The sequence turns Make scenarios into self-hosted n8n workflows that run in your own network, with each scenario inventoried, rebuilt, tested beside the original and cut over only after its checks pass. Connections and credentials are recreated as a deliberate security task rather than carried over.
Export every scenario as a blueprint
Export each scenario from Make as a blueprint .json file. Make's blueprints hold the scenario's modules, module settings and mapped values, so they give you the structure of each flow. Store the files in version control or an access-controlled location, because they describe your integrations in detail. Confirm the export count matches the scenario list in your Make organization, including scenarios owned by people who have left. This step is done when every active and paused scenario has a blueprint on file.
Inventory and classify each scenario
Read each blueprint and record the trigger type, the modules used, the approximate run volume, the systems it touches and who owns it. Group scenarios by module type, such as webhooks, scheduled polling, database writes, AI steps and code steps, because each group needs a different rebuild effort. Mark scenarios that handle regulated or personal data for extra review. This step is done when a single inventory sheet lists every scenario with an owner, a risk tier and a target n8n workflow name.
Map modules, routers, iterators and aggregators to n8n nodes
For each scenario, map Make modules to n8n nodes, using a built-in node or an HTTP Request node where no native node exists. Translate Make routers into IF or Switch nodes, iterators into splitting or loop logic and aggregators into merge or aggregation steps, and check how each handles empty arrays and errors. Note where n8n's execution model counts a whole workflow run as one execution, which changes how you reason about volume. Confirm mapped field references point to the correct upstream node. This step is done when each scenario has a written node map that a second person has reviewed.
Recreate connections and credentials securely
Blueprints do not include connections, so every app connection must be created again in n8n. Use n8n credentials with the smallest scope the integration needs, and prefer service accounts over personal logins where the target system allows it. Document who holds each credential and where it is stored. If you run n8n in queue mode, the encryption key must be shared with every worker and webhook processor so they can read stored credentials, so manage that key as a secret. This step is done when every connection in the inventory is live in n8n, tested once and recorded in the credential register.
Build and test in parallel with Make
Build each n8n workflow with inactive or test triggers while the Make scenario keeps running in production. Feed the same sample records to both versions and compare outputs, field by field, including error paths and empty inputs. Record every difference and decide whether it is a defect or an intended change. Review the logs and execution history in n8n to confirm failures surface where the team expects them. This step is done when outputs match for the agreed test set and each known difference has a recorded decision.
Cut over webhooks and schedules
Move the production traffic for each scenario in a controlled order, starting with the lowest-risk group from the inventory. Repoint webhook URLs in source systems to the n8n endpoint, switch scheduled triggers on in n8n and switch the matching Make scenario off at the same point to avoid duplicate processing. Watch error rates and downstream records during the first runs. Keep the Make scenario and its blueprint available for a rollback window agreed by the business owner. This step is done when each cut-over has a named owner, a logged time and no unexplained duplicates or gaps in downstream data.
Decommission Make scenarios and confirm the audit trail
Once a scenario has run cleanly on n8n through the agreed rollback window, deactivate it in Make and remove stored connections that are no longer needed. Archive the final blueprint, the node map and the test evidence with the change record. Revoke Make API tokens and any app permissions granted only for the migration. Confirm that monitoring, alerting and backups now cover the self-hosted n8n instance and its database. This step is done when Make holds no active scenarios for the migrated set and the evidence pack is filed.
Questions buyers ask before switching from Make
How much effort does rebuilding Make scenarios in n8n take?
The effort depends mainly on how many scenarios exist, how many use routers, iterators and aggregators, and how much custom logic sits in each one. Make exports each scenario as a blueprint .json file that holds the modules, module settings and mapped values, so the team can read the structure before rebuilding anything. Connections are not included in that file and must be recreated after import, so credential work is a cost that applies to every scenario. Simple linear scenarios usually move quickly. Scenarios with error handling, data mapping across many steps or AI steps take longer to test. Ask your partner for an inventory of scenarios grouped by complexity before agreeing on a scope.
Can our own team migrate from Make to n8n without outside help?
Many teams can move simple scenarios in house, especially if someone already knows n8n's visual canvas and can write JavaScript or Python in its code nodes. Outside help usually makes sense when the scenario count is high, when workflows touch regulated data, or when the team has no capacity to test in parallel with production. Self-hosting also adds operating work: installing, upgrading, backing up the database and managing the encryption key. Be honest about that capacity before deciding. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing first.
What does a Make to n8n move require from our platform and security teams?
The move needs a named platform owner who decides hosting, upgrades and access. Security should review where credentials are stored and how they are protected. n8n stores credentials in its database and encrypts them with a key, so the key must be managed as a secret and, in queue mode, shared with every worker and webhook processor node. Plan for:
- A platform owner for hosting, upgrades and backups
- A security review of network paths, secret storage and admin access
- A credential plan that recreates each Make connection under controlled ownership
- A test environment where rebuilt scenarios run against non-production data before cutover
How long does a move from Make to self-hosted n8n take?
No duration is fixed for this move, because the timeline depends on the scenario inventory, the number of connected applications, the level of testing required and how many scenarios can run in parallel with Make. Scenarios that run on schedules or touch finance, customer or regulated data often need the longest validation. A practical approach is to migrate in waves, starting with low-risk scenarios, then running old and new versions side by side until results match. Ask any provider for a written timeline tied to a scope document, and check which assumptions about scenario count and integrations it depends on.
Does n8n's license allow our business to use it?
n8n's main codebase is licensed under the Sustainable Use License, which allows use or modification for your own internal business purposes or for non-commercial or personal use. It is source-available, not OSI open source, and distribution is allowed only free of charge for non-commercial purposes. Files with .ee in their name or directory are not covered and require a valid n8n Enterprise License. Internal business use is the case the license describes, but offering n8n as a service to customers would need separate review. Have your legal team read the LICENSE.md file and confirm the terms against your intended use before deployment.
Does Make's EU zone already meet our data residency requirement?
Make lets you choose a US or EU zone when a scenario or organization is created, and that choice is fixed. Whether the EU zone meets your requirement depends on your legal and contractual obligations, not on the zone alone. Self-hosting n8n in your own EU infrastructure moves control of the data, the processing location and the access paths to your organization. Confirm with Make which subprocessors and log locations apply to your account, and confirm with your legal and compliance teams which controls you need. DeployOpen prepares systems and evidence for compliance assessments, but does not issue audit reports or certifications; independent auditors do that work.
Which n8n edition do we need for SSO and high availability?
The free Community edition runs without a license key and covers the core workflow engine, but SSO and LDAP, environments with Git and log streaming are included only in the Business and Enterprise plans, according to n8n's pricing page. SAML single sign-on is available on those paid plans, and multi-main setup for high availability is restricted to Enterprise self-hosted deployments. If identity integration or high availability is a requirement, confirm the edition in writing before the design is set. Ask for current pricing directly from n8n, because edition terms can change.
A decision path for teams that want to switch
Start with the license, because it decides whether n8n fits before any technical work begins. n8n's main codebase sits under the Sustainable Use License, which covers internal business use and non-commercial use, and files with .ee in their name need a valid n8n Enterprise License. Have legal confirm that your planned use, including any customer-facing or resold automation, falls inside those terms, and confirm which edition you need: the free Community edition or a paid key for Business or Enterprise. If your policy requires an OSI-approved license, treat n8n as a candidate to evaluate rather than a default, and put Activepieces (MIT licensed outside its enterprise paths) and Windmill (AGPLv3 and Apache-2.0 for code compiled without the enterprise flag, with proprietary code in prebuilt images) on the same shortlist. Check the n8n license file against your legal team's reading.
Next, inventory your scenarios and credit use. Export the scenario list from Make and sort it by operations per month, number of AI or code steps, and whether it depends on connections that only a few people can recreate. Each Make blueprint carries modules, settings and mapped values but not connections, so budget time for re-authorizing every app. Then check network reach: list every system a scenario touches and mark which ones are on premises, in a restricted segment or behind a firewall. A self-hosted n8n instance inside your network can reach them directly, but you must confirm that webhook endpoints, outbound access to SaaS APIs and credential storage meet your security baseline. If you plan queue mode with workers, note that the encryption key must be shared with every worker and webhook processor, and that multi-main high availability is limited to Enterprise self-hosted deployments.
Finally, pick one pilot scenario that is representative but low risk: a business-critical flow with branching, a few apps and no regulated data in its first version. Rebuild it on your chosen platform, run it in parallel with Make for a fixed period, and compare failures, retries and the operator hours spent. Record the costs that stay after the pilot, such as hosting, upgrades, backups and monitoring, and the one-time costs, such as rebuilding and testing. For deeper reading, the sibling pages on migrating from Make to Activepieces are not the right link here, so use the Make to Activepieces and Make cost comparison pages in this series to model the trade-offs before you ask for a written scope.
How DeployOpen helps evaluate and migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Make vs n8n, we start with a written scope that maps your existing Make scenarios to n8n, then build and hand over a self-hosted instance that your team can operate.
How we scope
- Inventory every Make scenario, its triggers, modules, routers and schedules before any rebuild is priced
- Confirm which connections, credentials and AI steps must be recreated in your own network
- Agree in writing whether n8n runs under Community, Business or Enterprise, based on the features you need
How we build
- Deploy n8n in your own cloud account, data center or air-gapped network, with the encryption key handled under your control
- Rebuild priority scenarios as n8n workflows, mapping data mapping, branching and error handling to native nodes and code steps
- Test each rebuilt workflow against the original Make run output before cutover
How we hand over
- Deliver a written record of each workflow, its credentials owner, its trigger and its failure handling
- Document the n8n license terms and the edition in use, so your legal and procurement teams can review them
- Train your operators on updates, backups, queue mode workers and day-to-day troubleshooting
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review n8n release notes with your team before each upgrade and test affected workflows first
- Keep scenario inventories and runbooks current as your automations grow or change
