Dify and n8n are not really rivals — they ship different things. Dify is a platform for building the LLM application itself: a chat app, an agent, a RAG-backed assistant. n8n is general workflow automation, where a model call is one node beside hundreds of connectors, schedules and webhooks. If the deliverable is the AI product, start with Dify. If the deliverable is a business process that occasionally asks a model a question, start with n8n. Searched the other way round — n8n vs Dify — the answer is the same, because the choice is about what you are building.
The part that actually trips people up is the money. Dify bills per AI response, n8n bills per workflow execution, and your model provider bills per token. Those three units do not convert into one another, which is why most side-by-side price tables for this pair are misleading before the first row.
Two version facts first, because a lot of indexed writing about this pair is out of date. n8n is on its 2.x line: the latest release is n8n@2.39.9, published September 21, 2026. Dify has no 2.x release line at all — the current major line is 1.x, latest release 1.17.1 from September 10, 2026. Both repositories are live and unarchived (Dify and n8n latest-release pages, re-checked September 21, 2026; n8n ships often, so expect the patch number to have moved again).
Who should pick which
| Your situation | Pick | Why |
|---|---|---|
| The thing you ship is a chat app, an agent or a RAG-backed assistant | Dify | The prompt workbench, the knowledge base and the published app are the product rather than something you assemble from nodes |
| The AI step sits inside a longer process — CRM, email, spreadsheets, webhooks, schedules | n8n | Model nodes live on the same canvas as the connectors, so the model is not the centre of gravity |
| Non-admins build apps but must not touch provider keys | Dify | Only the workspace owner and admins can manage providers, and any key added works across the whole workspace and bills to the adder's own provider account |
| You need separate environments and git version control | n8n, from the Business tier | "Different environments" and "Version control using Git" first appear in the Business plan's own feature list on n8n's pricing page; Starter and Pro do not list them |
| You want to run it yourself with no vendor account | Either, with a licence read first | Dify Community is a modified Apache 2.0 with a no-multi-tenant clause; n8n Community is fair-code, internal-business or non-commercial use only |
| You already pay for one and want to consolidate onto the other | Neither, cheaply | Neither project documents an importer for the other's format, so budget a rebuild rather than a transfer and choose on fit |
Two structural differences behind that table are worth stating outright. Permissions: Dify's provider configuration is an admin-only, workspace-wide act — its docs say plainly that only the owner and admins can manage providers and that a key you add "bills to your own account with that provider" — which is either exactly the governance you want or exactly the bottleneck you do not. n8n organises sharing around projects instead, and its pricing page meters those by tier: one shared project on Starter, three on Pro, six on Business, unlimited on Enterprise. Execution model: an n8n run is a single workflow execution no matter how many model calls happen inside it, while a Dify app charges once per model call, so the same logic lands on the two meters very differently.
Published plans and prices
Dify Cloud is priced per workspace. The annual strings below are literally what the pricing page renders; the page also carries a "Bill Annually Save 17%" toggle.
| Dify plan | Price | Message credits | Members / apps | Knowledge |
|---|---|---|---|---|
| Sandbox | Free | 200 (one-off, not monthly) | 1 member, 5 apps | 50 documents, 50MB, 30-day logs |
| Professional | $59 per workspace/month, or $590 per workspace/year | 5,000 per month | 3 members, 50 apps | 500 documents, 5GB, unlimited logs |
| Team | $159 per workspace/month, or $1,590 per workspace/year | 10,000 per month | 50 members, 200 apps | 1,000 documents, 20GB, unlimited logs |
| Community (self-hosted) | Free | None — you pay your own model bill | Single workspace | Your own infrastructure |
| Enterprise | Custom, contact sales | Not published | Not published | Not published |
Read from dify.ai/pricing and dify.ai/pricing/dify-cloud on September 19, 2026. The comparison table also shows a "5,000 API Rate Limit/month" on Sandbox against no such limit on the paid tiers. Dify Premium, the AWS Marketplace machine image, is a separate SKU; no price is quoted for it here, because no figure for it was confirmed against a first-party Dify page during this check.
n8n Cloud is priced per plan, and the quota is executions rather than model calls. Currency caveat: n8n.io/pricing rendered in euros for this check on September 19, 2026, and whether buyers elsewhere are shown another currency was not verified — confirm in checkout.
| n8n plan | Price, billed annually | Executions / month | Concurrent | AI (Gateway) credits |
|---|---|---|---|---|
| Starter | €20/mo | 2,500 | 5 | 2,300 per month |
| Pro | €50/mo | 10,000 | 20 | Up to 13,700 per month |
| Business | €667/mo | 40,000 | Not stated on the plan card | Not stated on the plan card |
| Enterprise | Custom, contact sales | Custom | 200+ | Not stated on the plan card |
| Community (self-hosted) | Free | Not sold as a quota — the execution allowances above are attached to the Cloud plans | Your own hardware | Gateway credits are unavailable on self-hosted |
Users and workflows are unlimited on all listed paid tiers, and a self-hosted option appears from Business upward. The free trial is advertised as Pro-level features with 1,000 executions and 5 concurrent executions.
Three different things are called a credit
This is the section the aggregator pages skip, and it decides your budget.
| Unit | What one unit is | What it ignores |
|---|---|---|
| Dify message credit / AI credit | "A single model call (one input and one output), and it counts as one response no matter how many tokens it uses" | Token volume entirely — a 200-token reply and a 200,000-token one are both one response, though larger models cost more credits |
| n8n execution | "A single run of your entire workflow. It doesn't matter how many steps are in the workflow or how much data it processes" | Node count, data volume, and how many model calls happen inside the run |
| Provider token | Input and output tokens at a per-million rate | Nothing — this is the meter that actually tracks how much work the model did |
Dify uses two names for the same unit: the pricing page says "message credits" and the current docs say "AI credits". Dify's own documentation defers to the pricing page for how many credits each model costs per response, and that per-model table could not be extracted verbatim for this page — so no per-model credit figures are printed here.
n8n's quota is narrower than it looks, in your favour. Its executions documentation states that "only production executions count towards this quota", and excludes manual runs from the editor, sub-workflow runs called by Execute Sub-workflow (only the parent counts), error-workflow runs, polls that return no data, and malformed or rejected webhook requests. It also warns the other way: a Schedule Trigger counts one execution every time it fires regardless of outcome, and a Webhook Trigger counts one for every inbound request that activates it, including an empty body.
One more thing an honest comparison cannot duck: n8n now sells model access itself. Gateway credits are "available from n8n 2.36.0", limited to n8n Cloud Starter and Pro, "unavailable on n8n Cloud Enterprise or self-hosted n8n", billed "per request at the rates listed on the service pricing page", and top-up credits "expire 12 months after purchase". That is the same job a gateway does, sold inside the product. The doc points at a service pricing page inside the n8n Cloud app, which served no readable rate card to a signed-out fetch on September 21, 2026, so no credits-per-dollar figure and no cost comparison against it is published here. What is checkable is scope: Gateway credits do not reach self-hosted or Cloud Enterprise, and the same doc notes that services outside the catalogue "still work in n8n the usual way: create a credential with your own API key". Dify's equivalent is weaker and it says so itself — a key and AI credits "can coexist", with a Usage Priority switch deciding which is drawn from first.
Pointing either one at your own model endpoint
Both take a third-party OpenAI-compatible endpoint, both also take an Anthropic-compatible one, and in neither case is the boundary "can I set a base URL" — the field lives in the credential and plugin schemas that ship in each project's source, and neither pricing page shows a plan gate on it. The boundary is which protocol the endpoint is expected to answer and which capability flags start switched off.
| Question | n8n | Dify |
|---|---|---|
| Where the endpoint goes | Credentials → OpenAI, a Base URL field defaulting to https://api.openai.com/v1; or Credentials → Anthropic, defaulting to the origin https://api.anthropic.com with no /v1 | Install the first-party OpenAI-API-compatible plugin, then Model Provider → Add Model, with a required API Base URL field |
| Model discovery | The dropdown calls GET {base}/models; when the base URL is not api.openai.com the chat-only id filter is dropped, so whatever that endpoint's /models returns is offered, chat model or not | None. The plugin is customizable-model only, so every model is typed in by hand, one row each |
| Protocol | A Use Responses API toggle on the OpenAI Chat Model node — see the unresolved default below | An api_type switch, default: chat_completions, with responses as the alternative |
| Tool calling | Works through the AI Agent node with a chat model attached | Off by default. function_calling_type defaults to no_call, so a gateway that works in chat silently fails in an Agent node until you set it |
| Endpoint that cannot be repointed | The OpenRouter credential pins its URL as type: 'hidden' | Each custom model is bound to its own key: deleting the only key deletes the model |
| Plan gate on BYOK itself | None found — the Base URL field is declared in the credential schema in n8n's source, and the pricing page lists no tier condition on it | None found for adding a provider; spreading requests across several keys with Load Balancing is badged Professional and Team in the Cloud docs |
Source files, fetched September 19, 2026: OpenAiApi.credentials.ts, AnthropicApi.credentials.ts, OpenRouterApi.credentials.ts and Dify's openai_api_compatible.yaml. Worth knowing: n8n's official OpenAI credentials page still documents only the API key and organisation ID and never mentions the Base URL field, and a community pull request to add it (n8n-docs#5146) was closed unmerged. The single most important field for this route is undocumented, which is why the source file is cited instead.
One default that is genuinely unresolved
n8n's two official sources disagree about which endpoint a freshly added OpenAI Chat Model node calls. The node source on master declares responsesApiEnabled with default: true, shown at node version 1.3 and above, and 1.3 is the newest entry in that node's version list — which reads as the Responses API being on. The node documentation says the opposite: "Otherwise, the OpenAI Chat Model node will default to using the Chat Completions API." Both were fetched on September 19, 2026 and both cannot be true for a node added today. This page does not pick a winner. Open the node, look at the toggle, and know that the setting decides whether requests hit /responses or /chat/completions — against an endpoint that serves only one of the two, it is the difference between working and a 404 on every call. Kunavo implements both paths, so either position is survivable here, but check it rather than assume.
Two boundaries a custom endpoint does not cross in n8n. The built-in Responses tools — Web Search, File Search and Code Interpreter — are OpenAI-hosted features, and the documentation adds that they are "only supported when using the OpenAI Chat Model node in combination with the AI Agent node". And a base URL set at the node level (rather than on the credential) is checked against the credential's domain restrictions before it is used — the node source calls assertOpenAiCredentialAllowsUrl on it, which throws when the URL falls outside those domains.
On the Dify side, the defaults are the story. Beyond function_calling_type: no_call, a hand-added model starts with structured_output_support: not_supported and vision_support: no_support, and each is a manual toggle you set to match what the endpoint really does. stream_include_usage defaults to enabled for a good reason: if the endpoint does not return usage in the final stream chunk, Dify falls back to a local estimate that counts only the first prompt message and undercounts multi-message prompts. The same file carries explicit escape hatches for gateways — an option to omit the top-level user field because "some OpenAI-compatible gateways reject it", a token_param_name switch, and a strict-versus-extended compatibility mode — which is decent evidence that the gateway route is a maintained case rather than a hack.
For Anthropic-style access, Dify's first-party Anthropic plugin is predefined-model and customizable-model, with an optional anthropic_api_url field, so you can point its bundled Claude list at another endpoint. Mind the ids if you do: Dify's bundled folder mixes undated ids such as claude-opus-5, claude-sonnet-5, claude-opus-4-8, claude-opus-4-7, claude-opus-4-6 and claude-sonnet-4-6 with dated ones such as claude-sonnet-4-5-20250929. The undated ones in that first group are Kunavo catalogue slugs; the dated forms are not, and not every id in Dify's folder maps to something currently on sale. Call GET /v1/models with your key and pick from what comes back — that list already omits anything not serving. Kunavo's base URLs follow the two conventions exactly: https://api.kunavo.com/v1 for the OpenAI-style field, and the bare origin https://api.kunavo.com for the Anthropic-style one (see the base URL doc for why adding /v1 there produces a 404).
One caveat specific to n8n's Anthropic credential, from reading Kunavo's own code rather than from a test: that credential authenticates with x-api-key and tests itself with GET {base}/v1/models, while Kunavo's /v1/models route reads only Authorization: Bearer — x-api-key is accepted on /v1/messages. So the credential test and the model dropdown are expected to fail there even though inference should work. The credential's optional custom-header pair can carry an Authorization header as a workaround. Neither the failure nor the workaround was runtime-tested for this page. The plain OpenAI-compatible route avoids the question entirely, and is the one the quickstart documents.
What a gateway key cannot cover in Dify
Dify's workspace has five default model slots — its model-providers doc lists them — and they are the real scope test for any model provider. A Kunavo key fills one of the five; the other four do not resolve to anything Kunavo runs.
| Dify default slot | What it does | Kunavo today |
|---|---|---|
| System Reasoning Model | The default for general LLM tasks | Covered — this is what the chat catalogue is for |
| Embedding Model | Indexes and retrieves knowledge base content | Not served. There is no embedding model in the catalogue, so this step runs locally or against an outside provider |
| Rerank Model | Reorders retrieval results by relevance | Not served. Dify's rerank type posts to {base}/rerank and Kunavo has no such route |
| Speech-to-Text Model | Turns audio into text | Not served. No speech-to-text model is listed in the catalogue |
| Text-to-Speech Model | Turns text into audio | Not served. No text-to-speech model is enabled in the catalogue today, so this slot also points somewhere else |
Say that out loud before you plan a migration: a Dify knowledge base or RAG pipeline still needs an embedding model, and usually a rerank model, from somewhere else. A gateway key covers the reasoning slot, not the whole workspace. The RAG implementation guide covers how that split is usually arranged.
A worked cost estimate
This is illustrative token arithmetic, not a measured task cost and not a bill ceiling. Assume a triage workflow that runs 2,000 times a month in production, and that each run makes two model calls — one to classify, one to draft — each sending 4,000 input tokens and returning 400 output tokens. That is 4,000 model calls, 16 million input tokens and 1.6 million output tokens. Rates are live Kunavo catalogue prices per million tokens.
| Model | Input / output per 1M | Estimated token cost for the month |
|---|---|---|
| Claude Haiku 4.5 | $0.40 / $2.00 | $9.60 |
| Gemini 3.8 Flash | $0.525 / $2.625 | $12.60 |
| GPT-5.6 Terra | $0.70 / $4.20 | $17.92 |
| Claude Sonnet 4.6 | $1.20 / $6.00 | $28.80 |
| Claude Opus 5 | $2.00 / $10.00 | $48.00 |
Now put the platform meters beside it. That same workload is 2,000 production executions on n8n — inside Starter's 2,500 — because the two model calls are inside one run. On Dify it is 4,000 AI responses, because Dify counts each model call, so it would exceed Sandbox's 200 one-off credits immediately and sit within Professional's 5,000 monthly credits. The model choice alone moves the token line from $9.60 to $48.00 for the same 4,000 calls, which is usually a larger lever than the plan tier. Cheapest listed rate and lowest cost to finish the job are still different questions: a cheaper model that needs a retry can cost more than a dearer one that does not.
Kunavo's catalogue amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalogue cost and upstream cost times the applicable markup. Cache charges and external tools sit outside this example. The minimum top-up is $10 in prepaid credit — a funding minimum, not a task fee or a subscription. See billing details, and AI cost optimization for how to measure your own workload instead of trusting an estimate like this one.
Running both, and what it costs to change your mind
The most common real answer to "Dify or n8n" is both, in different layers: Dify builds and hosts the AI app, n8n triggers it and wires the result into the rest of the business. Nothing about either product forbids that, and it keeps each tool on the job it is designed for. The cost is two meters and two sets of credentials, so check both before you treat it as the cheap option.
What it is not is a migration path. Neither project documents an importer for the other's format, so plan on rebuilding the logic rather than moving it. That is the strongest reason to choose on fit rather than on price: the plan bill is reversible next month, the rebuild is not. If you are choosing a model route rather than a platform, the OpenAI-compatible API guide covers the endpoint both of these tools expect, and the LLM gateway guide covers what a gateway does and does not buy you.
Neither client has been runtime-tested against Kunavo. Everything above is read from current source and current official documentation, and Kunavo publishes no setup guide for either tool — the configuration is the standard OpenAI-compatible one. Keep a working route available while you try it, run one bounded task, then read the charge your account actually recorded. Create a Kunavo account when you are ready to fund a key, or browse the integrations index for the clients that do have a documented setup.
FAQ
Is Dify better than n8n?
Neither is better in general, because they ship different things. Dify is an LLM application platform: its repository describes itself as a place to build agentic workflows and RAG pipelines with model and tool support in one collaborative workspace, and the deliverable is the AI app. n8n is general workflow automation where a model call is one node type beside connectors, webhooks, schedules and databases, and the deliverable is a process. Pick Dify when the AI product is the point. Pick n8n when the AI step sits inside a longer business process. Asked the other way round, n8n versus Dify, the answer is identical — the choice is about what you are shipping, not about which tool is stronger.
Can Dify and n8n work together?
Yes, and that is a common arrangement rather than a workaround. Dify documents that every app you publish doubles as a REST API you call from your own backend with an API key, and n8n has an HTTP Request node, so a Dify app can be the reasoning step inside an n8n workflow while n8n handles the triggers, the connectors and the retries. Budget both meters if you do this: Dify counts an AI response for each model call its app makes, and n8n counts one production execution for the whole workflow run that called it. Neither project documents an importer for the other's format, so a Dify app and an n8n workflow stay two artefacts rather than one migrated between tools.
Which is cheaper, Dify or n8n?
You cannot answer that from the plan prices, because the two plans meter different things and neither meters the thing that usually costs the most. Dify Cloud is priced per workspace and counts message credits, where one AI response is one model call regardless of how many tokens it uses. n8n Cloud is priced per plan and counts production executions, where one execution is one whole workflow run regardless of how many steps or model calls are inside it. The model tokens are a third bill on top of both unless you stay inside the included credits. Self-hosting either one removes the subscription and leaves infrastructure plus the model bill, subject to each project's licence limits.
Is Dify or n8n better for RAG?
Dify, by design. It ships a knowledge base as a first-class object with per-plan document and storage limits, and its workspace has dedicated default-model slots for embedding and rerank alongside the reasoning model. n8n can build a retrieval pipeline out of vector store and embedding nodes, but you assemble and maintain it. Note the model-side consequence either way: retrieval needs an embedding model and usually a rerank model, and Kunavo serves neither today, so that part of a Dify or n8n RAG stack runs locally or against an outside provider whichever platform you choose.
Can I use my own API key in Dify and n8n?
Both expose the field, and neither pricing page shows a plan gate on it. In n8n the OpenAI credential has an editable Base URL that defaults to https://api.openai.com/v1, and the Anthropic credential has one that defaults to the origin https://api.anthropic.com with no /v1; the OpenRouter credential pins its URL as a hidden field and cannot be repointed. In Dify you install the first-party OpenAI-API-compatible plugin and add each model by hand, or point the first-party Anthropic plugin at a custom API URL. Dify also lets a key and its own AI credits coexist, with a Usage Priority switch on the provider card deciding which is drawn from first.
Is Dify open source? Is n8n open source?
Both answers need a qualifier, and GitHub's repository API reports NOASSERTION for both licences. Quoting the two LICENSE files at github.com/langgenius/dify and github.com/n8n-io/n8n: Dify uses a modified Apache License 2.0: commercial use is allowed, but operating a multi-tenant environment from the source needs written authorisation, where one tenant means one workspace, and you may not remove or modify the logo and copyright information in the frontend. n8n is fair-code, not open source in the OSI sense: the Sustainable Use License v1.0 permits use or modification only for your own internal business purposes or for non-commercial or personal use, files with .ee. in the filename or .ee in the dirname require a paid n8n Enterprise License, and branches other than master are explicitly not licensed.
Checked September 19 and re-checked September 21, 2026: both GitHub repositories and their latest releases via the GitHub API; both licence files; dify.ai/pricing, dify.ai/pricing/dify-cloud and n8n.io/pricing; the Dify model-providers doc; the n8n executions, Gateway credits and OpenAI Chat Model docs; and the raw source of n8n's OpenAI and Anthropic credentials, its OpenAI Chat Model node, and Dify's OpenAI-compatible and Anthropic plugin manifests. Neither product was installed and neither was pointed at Kunavo, so no behaviour here is a test result. Kunavo token rates come from the live catalogue and every dollar figure is illustrative arithmetic.