Make.com vs n8n for Developers: Code, Self-Hosting and Licensing

Most Make.com vs n8n comparisons are written for buyers. They line up interfaces and prices and stop. That comparison has its place, and I have written it — n8n vs Make.com works through which platform is cheaper for the shape of workflow you are actually building, which is the question most people arrive with.

This is the other half. If you are the person who will maintain the thing at two in the morning, three questions matter far more than the canvas: where does each platform's ceiling sit when the visual layer runs out, what does self-hosting actually commit you to, and what does the licence permit. The third one is where most competing articles are simply wrong.

Everything below was checked against vendor documentation on 13 August 2026.

The Code node is the whole ceiling argument

Make gives you a solid library of built-in functions: text, dates, numbers, array operations, JSON parsing. That covers most transformations. The remainder — parsing an awkward date format, fuzzy-matching two lists, reshaping a deeply nested structure that no built-in function anticipates — needs a workaround. Usually that means several chained modules, or an HTTP call out to something you wrote yourself, sometimes a small Python FastAPI backend whose only job is to be the escape hatch Make does not have.

n8n has the same built-in functions plus Code nodes running JavaScript or native Python. There is no ceiling. When the visual layer cannot express the transformation, you write the transformation.

That is the single largest practical difference for developer work, and it is genuinely one-sided. But it comes with an obligation, discussed in the FAQ below: an escape hatch that becomes the main road costs you more than it saves.

What n8n 2.0 changed, and why it matters if you self-host

n8n 2.0 shipped in December 2025 and is best understood as a hardening release rather than a feature release. If you are running an instance, or advising someone who is, several of the documented breaking changes will land on you directly.

Task runners are on by default, and that has knock-on effects. All Code node executions now run on task runners. A consequence people hit immediately: $evaluateExpression() no longer works inside the Code node, because secure mode disables evaluating strings as code. Expressions in ordinary node fields are unaffected. There is an insecure-mode environment variable to restore it, and n8n's own documentation frames that as a temporary workaround rather than a setting to live with.

Python is now native rather than Pyodide. The Pyodide-based Python Code node is gone, replaced by a task-runner implementation. Python Code nodes only work with task runners in external mode, and the native node does not support the built-in variables or dot-access notation the old one had. If you have Python in a workflow, that is a rewrite rather than an upgrade.

MySQL and MariaDB are no longer supported as storage backends. Postgres or SQLite only. The MySQL node itself is unaffected — this is about where n8n keeps its own data. The legacy SQLite driver is also gone; the pooling driver is now the default and the only one, and n8n's benchmarks put it at up to ten times faster.

Environment variables are blocked in the Code node by default, configuration files must have 0600 permissions, ExecuteCommand and LocalFileTrigger are disabled by default, OAuth callback URLs now require authentication, and file nodes are restricted to ~/.n8n-files unless you widen the path. Every one of these is a sensible default and every one will break something that used to work.

In-memory binary data mode is gone. Filesystem, database or S3 only. On a busy instance that is a disk-space planning question you should answer before it answers itself.

Smaller things that trip people up: the Start node has been removed, the Activate and Deactivate toggles are now Publish and Unpublish, n8n --tunnel is gone, and the release channels have been renamed from latest and next to stable and beta. n8n's advice, which is correct, is to pin a specific version rather than track a tag. The changelog is worth reading before any upgrade rather than after.

Make, being SaaS, hands you none of this and also gives you no say in it.

The licence, which most comparisons get wrong

n8n is frequently described as open source. It is not, and the distinction has commercial consequences.

The licence file in the repository is the Sustainable Use License, version 1.0. It grants a royalty-free worldwide licence to use, copy, distribute and prepare derivative works, and then limits it: you may use or modify the software only for your own internal business purposes or for non-commercial or personal use, and you may distribute it to others only free of charge for non-commercial purposes. Source files with .ee. in the filename are excluded from that licence entirely and require an Enterprise licence.

Read plainly, running n8n to automate your own business is fine. Running instances for clients as a paid hosted product is not something the licence contemplates, and if that is your business model it is a conversation with n8n rather than a decision you make on your own. Agencies planning white-label automation hosting should establish this before it becomes a commercial commitment, not after.

Make has no equivalent question because there is nothing to host.

What Community Edition actually withholds

n8n's own edition comparison is refreshingly direct: the Community edition includes almost the complete feature set, free indefinitely, and then lists what it does not include. Custom variables. Environments. External secrets. External binary storage. Log streaming — although ordinary logging is included. Multi-main mode — although queue mode is included, which is the one most people assume is paywalled and is not. Projects. SSO via SAML and LDAP. Sharing of workflows and credentials, meaning only the instance owner and the creator can access them. And version control using Git.

There is also a registered Community edition, still free, that you unlock by giving n8n an email address. It adds folders, debug-in-editor with data pinning, and custom execution data. If you self-host and have not registered, you are leaving three useful things on the table for no reason.

Two of those omissions matter more than the rest for a developer team. Credential and workflow sharing being absent means a free self-hosted instance is effectively single-owner, which is fine for a solo operator and awkward for a team of three. And Git version control being a paid feature undercuts the usual argument that self-hosted n8n gives you source control for free.

Version control, honestly

You can export any n8n workflow as JSON, commit it and diff it. That works, and it is more than Make offers, where there is no export you would want to treat as source.

But the diffs are noisy, reviewing one properly still means opening the canvas, and the native Git integration that would make this pleasant sits on the Business plan alongside environments. So the accurate version of the claim is: n8n lets you version workflows by hand for free, and version them properly if you pay. Make does not really let you version them at all. If code review and rollback are non-negotiable for a long-lived system, that is still the most convincing argument for n8n in this whole comparison, but it is not the free win it is often presented as.

Debugging and execution inspection

Make's execution history shows exactly what data passed through each module on each run, which is a good tracing interface. It degrades with size. Twenty-plus modules on a canvas gets visually cluttered, there is no way to group or collapse sections, and finding the module where a value went wrong means clicking through logs one at a time.

n8n's execution view shows full input and output for each node in a side panel, which is faster for tracing a transformation three steps deep. Registered Community edition adds debug-in-editor, where you copy and pin execution data so you can develop against a frozen input instead of hammering a live API. Production runs ignore pinned data, so it is a development convenience rather than a trap.

Make wins on one point here: its mapping panel, where you click a field and see every value available from every upstream module with the full path shown, is more discoverable than n8n's expression editor, which assumes you know the syntax for reaching a nested value.

Custom integrations

Both platforms have an HTTP Request module for any API without a native connector, and the mechanics are equivalent — Make.com HTTP Module Tutorial covers that side in detail.

n8n goes further with community nodes: you build and publish custom nodes in TypeScript, and they behave like native ones, appearing in the node selector with typed fields and authentication handled through the credential system. For an API you integrate repeatedly — a specific CRM, an industry tool, a client's internal service — that is meaningfully better than configuring a raw HTTP request every time.

Make has no equivalent. You can save an HTTP module configuration as a template, which is not the same thing.

Error handling

Make has three error handlers: Ignore, Break and Rollback, documented in Make's Help Centre, alongside exponential backoff for retries. Break with automatic retry covers temporary API outages well, and Make.com Error Handling walks through the patterns that hold up in production.

n8n is more granular. You configure error behaviour per node, and an Error Trigger workflow can catch failures across every workflow on the instance. That centralised pattern is more maintainable than configuring error handling separately in each workflow, and it is the right architecture for anything you intend to run for years. The cost is more setup before it does anything.

When I reach for each

Make, for client automation where the client's own team will maintain it. The interface is the one I can hand over, there is no infrastructure to explain, and the native connector library covers most business tools. This is why most of my client-facing GoHighLevel and CRM work sits there.

Make, again, for prototypes. Faster to wire up, trivially easy to share access with a stakeholder.

n8n, self-hosted, for anything needing Code nodes, custom TypeScript nodes, or volume high enough that per-module billing stops making sense. Read the licence first if clients are involved.

n8n, for systems intended to run for years. The extensibility means you rarely hit a wall, and the error architecture is the one that survives contact with production.

The No-Code Tool Comparison Matrix puts both alongside other options, and the Make.com Pricing Calculator is there if the decision comes down to cost.

If you want to talk through a specific build, book a free 30-minute call. Bring the use case and the constraints.

Frequently Asked Questions

Should I just write everything in n8n Code nodes?

No. The Code node is an escape hatch and it is at its best when it stays one. A workflow that is six Code nodes joined by arrows has all the maintenance cost of a script with none of the tooling — no tests, no linting, no dependency management — and a canvas that no longer tells anyone what the automation does. At that point you are better off writing an actual service and calling it. Use code where the visual layer genuinely cannot express the transformation, not because typing is faster than clicking.

What will break when I upgrade a self-hosted instance to n8n 2.0?

Realistically: any Python Code node, because Pyodide is gone and native Python needs task runners in external mode; anything calling $evaluateExpression() inside a Code node; anything reading environment variables from a Code node; anything using ExecuteCommand or LocalFileTrigger; and your database if you were on MySQL or MariaDB, which are no longer supported storage backends. Read the breaking-changes page in full before upgrading, migrate the database first, and pin a version rather than tracking a tag.

Can I resell hosted n8n to clients?

Not under the Sustainable Use Licence as written. It permits use for your own internal business purposes or for non-commercial and personal use, and permits distribution only free of charge for non-commercial purposes. Building automations for clients on an instance you own for your own business is a different thing from selling them hosting as a product, and if your plan is the latter you need to establish that with n8n directly. Treating "open source" as a synonym for "do what you like" is the most expensive mistake available in this comparison.

Where should API keys and secrets live?

In the platform's credential store, not in a node parameter and never in a Code node. Both platforms encrypt credentials and keep them out of execution logs; a key pasted into an HTTP header field can end up visible in a shared scenario or an exported workflow. On self-hosted n8n, set the encryption key explicitly rather than accepting whatever the container generated, or you will discover the problem the first time you restore a backup onto a fresh instance. External secret stores are a paid feature, so on Community edition the built-in store is what you have.

What breaks first as a self-hosted instance grows?

The execution database. Every run stores its input and output by default and it grows faster than anything else on the box, so set execution pruning early rather than diagnosing a full disk later. After that it is usually memory during large batch runs, which is a queue-mode and worker question rather than something you solve by adding RAM indefinitely. Queue mode is included in the Community edition; multi-main is not, so horizontal scaling of the main process is where the free tier stops.

Is it reasonable to run both?

Yes, and it is what I do, but split by ownership rather than by feature. Anything a client's team will open and edit goes on Make, because handing a non-developer a self-hosted instance is handing them an infrastructure problem they cannot diagnose. Anything I own and maintain runs on n8n. Splitting one workflow across both platforms is a different proposition and rarely worth the debugging cost.

If you would rather have this built than build it, I take on Make and n8n development work through Fiverr and Upwork. n8n Self-Hosted Setup is the walkthrough if you would rather do it yourself.