n8n vs Dify vs Langflow vs Flowise: the licence names the moat

At a glance

All four give you a drag-and-drop canvas, all four self-host, and three of the four are commonly called open source. Only one of them actually is, in the sense your procurement team means.

Read Flowise's obituary first, because it is the thesis

Flowise did not run out of users. It had passed 55,000 GitHub stars, it had a cloud product, and it had shipped a 3.x line. It stopped because the maintainers concluded the shape of the product had been overtaken. Their timeline is worth reading as a sequence: code freeze on 29 July 2026, repository archived on 13 August, core team presence ending on 31 August. The Apache 2.0 code stays visible indefinitely, npm packages and Docker images are marked deprecated, and users are told to fork it if they want it maintained.

The stated reason is not "we could not monetise" and not "a competitor won". It is that coding agents absorbed the job the canvas was doing. A visual builder's original pitch was that assembling a chain by hand was tedious and error-prone, and dragging boxes was faster than writing the glue. In 2026 the glue is generated on request, in your own repository, in a language you already deploy — and the moment that becomes true, the canvas's remaining value has to come from somewhere other than authoring convenience.

So the question for the other three stops being "which canvas is nicer" and becomes: what is underneath your canvas that a coding agent cannot produce this afternoon? Each of the three has a genuine answer, and it is a different answer in each case.

n8n: the licence forbids the one thing you might want to do with it

n8n calls itself fair-code, not open source, and the distinction is load-bearing. Its Sustainable Use License 1.0 grants a broad copyright licence and then narrows it in one paragraph: 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 or provide it to others "only if you do so free of charge for non-commercial purposes". Separately, any source file with .ee. in its name or .ee in its directory path is excluded from that licence entirely and requires an n8n Enterprise licence.

Read plainly, that is permissive for the largest use case and prohibitive for the second largest. Running n8n to automate your own company's work is squarely allowed. Standing up n8n as the automation layer inside the product you sell, or operating it for clients as an agency, is the case the clause exists to stop. Teams routinely discover this after the pilot, which is the worst possible moment.

What the clause is protecting is worth naming, because it is the most concrete moat in this comparison: roughly 1,500 integrations. That library is years of connector maintenance against APIs that change without notice, and it is precisely the asset a coding agent does not hand you in an afternoon. The canvas is the shop window; the connectors are the inventory. n8n's licence defends the inventory.

Dify: commercial use is fine, multi-tenancy is not

Dify ships under a modified Apache 2.0 with two additional conditions, and they are unusually specific. First, absent written authorisation you may not use the source to operate a multi-tenant environment — and Dify defines a tenant precisely, as one workspace. Second, you may not remove or modify the logo or copyright information in the Dify console or applications, where "frontend" means everything under web/ in source or the web image under Docker; the condition explicitly does not apply to uses that do not involve the frontend.

That pair of clauses is a business model rendered as licence text. Dify is happy to be the backend of your application and says so; it is not happy to be the thing you resell as a workspace product, because that is Dify's own product. The frontend carve-out is the tell — if you use Dify headless, behind your own UI, the branding condition evaporates and only the multi-tenancy clause binds.

The asset being defended here is the app platform: workspaces with roles, a retrieval pipeline you did not have to assemble, model management, and a published app plus API that non-engineers can be handed. That is a real thing to own and it is not what a coding agent produces from a prompt. It is also the part you would have to rebuild if you left, which is the second question this comparison turns on.

Langflow: no clause at all, and a different kind of dependency

Langflow is plain MIT. There is no multi-tenancy carve-out, no internal-use restriction, no branding condition and no enterprise directory held back. If your constraint is legal, Langflow is the answer and the rest of this section is optional.

Its risk lives elsewhere, in two places. The first is ownership: Langflow was acquired by DataStax in April 2024, and IBM completed its acquisition of DataStax on 1 November 2025, so the project's roadmap now sits inside a watsonx portfolio. MIT means a fork is always available, which is a genuine floor — but a floor is not a roadmap, and the direction of an enterprise-portfolio project is set by an enterprise portfolio's needs.

The second is that Langflow's canvas is a front end for Python components over LangChain and LangGraph. That is its best feature and its honest weakness. Best, because the exit path is a file: you can take the flow out as code and run it as an ordinary service, so the canvas is a place to prototype rather than a place your logic is trapped. Weakness, because you have inherited a framework's abstractions and upgrade cadence along with the drag-and-drop, and the thing you carry out is Python you could have written — which is exactly what Flowise's maintainers said had stopped being hard.

The exit path is the axis nobody compares on

Every one of these tools stores your work as its own artefact, and the artefacts have wildly different half-lives. An n8n workflow is JSON that only n8n's engine executes, and it references connectors that only exist inside n8n — which is why the exit is a re-implementation rather than a migration. A Dify app keeps its API contract and its knowledge base if you leave, but the workspace and role model was the product, and rebuilding it is the work. A Langflow flow exports to Python that runs anywhere. A Flowise deployment is now a fork you own outright, which is a worse position than an active project and a much better one than a proprietary product being sunset.

Set the two axes side by side and the selection rule falls out. The licence tells you what you may do with the code while you are using it; the artefact tells you what you keep when you stop. A tool can be generous on one and brutal on the other — Langflow is generous on both, n8n is restrictive on both, and Dify sits in the middle by design.

When to pick which

Further reading

On this wiki:

• Agent frameworks — what a framework does and does not give you.
• Durable execution — the engine layer n8n's canvas sits on top of.
• Exiting a managed agent runtime — the same exit-cost question, one layer up.
• Agent connector platforms — the integration library as a product category.
• Build vs buy — where a licence clause belongs in the decision.

Project sources:

• n8n Sustainable Use License
• Dify Open Source License
• Langflow MIT licence
• The Future of Flowise