n8n vs Make

Pricing

Make prices by operation. An operation is one module firing inside a scenario — a trigger run, an HTTP call, a Set Variable, a router branch evaluation. The Core plan begins around $9 a month for 10,000 operations, Pro around $16 a month. Multi-step scenarios consume operations linearly with the number of modules that fire, so a ten-module scenario running once burns ten operations.

n8n prices by workflow execution on cloud, regardless of how many nodes run. The Starter plan begins around $20 a month for 2,500 executions, the Pro plan around $50 a month for 10,000. A workflow with twenty nodes and a workflow with two both consume one execution credit. This is the biggest line-item difference: for long workflows n8n is dramatically cheaper per run; for short ones, Make's larger included-volume on the Core plan often wins.

Self-hosted n8n removes the meter entirely. A small VPS at $5–10 a month carries several thousand executions a day before queue mode, workers, and external Postgres are needed. Make has no self-host edition, so the cost floor is whatever cloud plan covers the operations volume.

Features

Make's strength is the canvas. Scenarios are drawn as a flowchart with modules connected by visible data paths, and the editor is the most polished in the category — modules animate as they run, errors light up on the exact bubble that failed, and the data inspector on each connection lets you scrub through historical runs. Routers split a scenario into branches that fire independently, iterators fan out arrays, aggregators collect results back, and the visual model holds up at thirty or forty modules better than any other cloud tool.

n8n's strength is composition. The editor exposes branching, merging, looping over arrays, sub-workflows that call other workflows, and a Code node that accepts JavaScript or Python with full access to upstream data. IF, Switch, and Merge nodes give you the control flow Make builds with Routers, and the Execute Workflow node lets one workflow call another with typed inputs and outputs — a pattern Make scenarios cannot express cleanly.

Integrations

Make ships around 1,800 native apps. The catalog leans into mainstream business SaaS — Slack, Google Workspace, Microsoft 365, HubSpot, Salesforce, Shopify, Notion, Airtable — and most modules expose far more endpoints per app than Zapier-style 'one trigger, one action' integrations do. The HTTP module covers anything outside the catalog, and the Custom Apps SDK lets a developer publish a private connector without a public listing.

n8n ships around 400 native nodes plus a thousand-plus community nodes from the npm-installable contrib package. Community nodes fill the long tail of databases, queues, observability tools, and niche APIs that Make does not prioritise. The HTTP Request node sits at the same level as Make's, but n8n's Code node lets you import npm packages and call them inline, which removes the need for a custom connector in most cases where Make would force one.

Self-hosting

Self-hosting is the cleanest structural difference. n8n ships a Docker image, a Compose stack, and a Helm chart. SQLite covers small installs; Postgres is recommended for production; Redis enables queue mode so multiple worker containers pull jobs in parallel. The license is the Sustainable Use License — free for internal use and modification, with restrictions on running a competing hosted n8n service — invisible for the cases most teams care about.

Make has no self-hosted edition. There is no community release, no on-prem enterprise package, and no public roadmap commitment to add one. Every scenario run goes through Make's cloud, which is fine for the majority of workloads and a hard stop for teams that need data residency in a specific jurisdiction or an air-gapped environment.

A self-hosted n8n on a single VPS handles workloads most small teams will ever produce. Queue mode with a Postgres primary, a Redis broker, and two or three worker containers carries tens of thousands of daily executions on modest hardware, and the JSON workflow format lives cleanly in version control. The trade is owning backups, upgrades, and the on-call.

AI

n8n includes an AI Agent node, LangChain wrappers, a chat memory node, and direct integrations with the major vector stores (Pinecone, Qdrant, Supabase pgvector, Weaviate). You can build a retrieval-augmented chat flow, a tool-using agent, or a multi-step LLM chain on the same canvas you use for SaaS glue, and the model nodes accept OpenAI, Anthropic, Google, Mistral, and self-hosted providers through Ollama. Sub-workflows can be exposed to the agent as callable tools, which turns building an agent loop into a wiring job rather than an orchestration code job.

Make has shipped AI Agents, an OpenAI module, an Anthropic module, and a growing set of generative AI helpers (text, image, transcription). For a scenario that calls a model in one or two modules — summarise an email, classify a ticket, draft a reply — the experience is fast and the result feeds the rest of the scenario cleanly. For a tool-using agent that loops until it succeeds, a RAG flow with a private vector store, or a chain that branches on classifier output, the building blocks are thinner and the visual model is less suited to the recursion an agent loop implies.

A useful filter: when the AI step is the workflow, n8n is the better home; when the AI step is one module inside a larger SaaS scenario, Make is faster to ship.

Migration

Neither product imports the other's format. Migration is a manual rebuild. The pattern most teams follow: document the source flow, recreate it on the target, run both in parallel for a week or two, then disable the source once the new version has logged a few hundred successful runs.

Make to n8n is the more common direction. Triggers map cleanly because the underlying SaaS APIs are identical; Routers become IF or Switch nodes; Iterators become Split In Batches or Loop Over Items; Aggregators become Merge or Code nodes. A typical eight- to twelve-module scenario rebuilds in thirty to sixty minutes the first time. n8n to Make is rarer: workflows that lean on the Code node with npm imports, sub-workflows with typed inputs, or AI Agent loops do not translate cleanly to Make's linear-with-routers model, and the rebuild usually fragments one workflow into two or three scenarios stitched by a webhook.

Who should choose n8n

n8n is the right call for teams with at least one engineer, workflows that touch internal systems alongside SaaS, and a preference for the option to self-host. The execution-priced cloud is materially cheaper than Make on long workflows, the Code node closes the gap on any missing integration, and the AI nodes are far enough ahead that AI-heavy automations are practical without a second platform. It is also the right call when data residency, vendor independence, or version-controlled workflow definitions matter — self-hosting in your own jurisdiction, JSON workflows checked into git, and a fair-code license that lets you fork are properties Make structurally cannot offer.

Who should choose Make

Make is the right call for teams who want the cleanest visual canvas in the category, run mostly business-SaaS automation, and would rather not think about infrastructure. The included-operations volume on the Core plan is generous for small workflows, the scenario editor is the easiest place in the cloud tier to debug a branching flow, and the operations meter is friendlier than per-task pricing on multi-step automations. It is also the right call when the team is operations-led rather than engineering-led: there is no Dockerfile, no Postgres to back up, no Redis to monitor.