How to Move From Flowise to Dify: Dify vs Flowise After the Archive

In Dify vs Flowise, only Dify is still shipping: its default branch took 833 commits in the 30 days to Oct 23 2026. Flowise was archived on Aug 13 2026 after its last release, 3.1.4, on Jul 29. The final Docker image I pulled on Oct 23 exited within seconds, and GitHub lists six Flowise security advisories with no patched version. A Flowise team should plan a move. Dify is the nearest match for chatflow and retrieval apps, going by its docs, since I did not run it. I found no converter, so the move is a rebuild.

Dify vs Flowise: one repository is still being committed to

The sunset page set a code freeze on Jul 29 2026, archival on Aug 10 and end of life on Aug 31. The Apache 2.0 code stays on GitHub for forks. GitHub shows the archive date as Aug 13. The Flowise vs Dify vs n8n comparison covers n8n too. This post stays on the pair.

Source: the GitHub releases and commits APIs for langgenius/dify and FlowiseAI/Flowise, read on Oct 23 2026.

How I counted: gh api --paginate repos/<owner>/<repo>/releases on both repositories, keeping releases published between Oct 23 2025 and Oct 23 2026, drafts excluded and release candidates included. The mean gap averages the days between consecutive releases, first to last. The commit count is the commits API on each default branch since Sep 23 2026.

One caution on Dify. Its last tag is Sep 10, 43 days ago, longer than any earlier gap in the window (the longest ran 37 days, May 19 to Jun 25 2026). The default branch kept moving, so I do not read it as a stall, but I cannot tell you why no tag has shipped. Open the releases page before you pin a version.

Six Flowise advisories have no patched version

GitHub published 50 security advisories on the Flowise repository from Jul 29 2026 onward, 30 of them in one batch that day. Forty four list a patched version: 30 name 3.1.3 and 14 name 3.1.4. Six, published Sep 10, list none: two critical and four high, affecting versions up to 3.1.4. They are on the advisories page, which I read through the GitHub API on Oct 23. They cover SSO account takeover (two critical), a cross workspace credential flaw, a queue dashboard without role checks, and missing authorization on chat history and upsert routes. My reading is that most touch multi user features, so a single user install is less exposed, though the chat history route is reachable with a low privilege API key. The repository is read only, so a patch has to come from your own fork. Dify has 13 advisories published in the same 12 months, none critical: six high, five medium, two low. Twelve list a patched version, and one, a client side XSS in the web chat app, lists none.

The last Flowise image I pulled did not start

On Oct 23 2026 I pulled flowiseai/flowise:3.1.4 fresh (digest sha256:3922767afb52, image created Jul 29 2026) and ran it on an arm64 Mac, Docker 29.4.0 on Colima. The container exited with code 1 within seconds. The log shows a LangChain package path error (ERR_PACKAGE_PATH_NOT_EXPORTED for ./utils/uuid), Cannot find module '@smithy/eventstream-codec', and TypeError: this.db.exec is not a function.

That is one run on one architecture. Issue 6688, open since Jul 30, reports the same errors, so it is not only my machine. A Windows 11 commenter on Docker Desktop confirms it. Two commenters trace the fatal error to an unpinned dependency, connect-sqlite3 0.9.17, which would hit any image built after it was published, and say pinning 0.9.16 fixes a rebuild. One of them, dblagbro, adds that the first two errors are not fatal and that every official image ships flowise@3.1.2 whatever its tag, which would leave the 3.1.3 and 3.1.4 security fixes out of the images. I did not verify any of that. dblagbro also runs a community fork, flow-wiser, which says it removed the commercially licensed enterprise files and carries the fixes. It is not affiliated with Flowise and I have not run it.

Staying on Flowise means forking or trusting a community fork, pinning versions that run, and owning every LangChain and security update yourself. I would only do that for a single internal app whose dependencies I could read myself.

I did not run Dify, so there is no boot comparison. My Docker VM has 4 GiB shared with other containers, below the 8 GiB Dify's docs ask for a Mac VM.

Licence, hosting and price side by side

Sources: the Dify licence, Dify Docker Compose docs, dify.ai/pricing, the Flowise licence and Flowise getting started.

Step 1: Inventory what each Flowise flow does

Do this before you open Dify. The goal is a one page spec per flow. First decide where Dify will run. I would pick Cloud for a small team that wants no servers, and self hosting when data must stay in your network; self hosting means the Compose stack above.

1. Export every flow definition. The Flowise Chatflows API lists each flow with its flowData JSON and a type of CHATFLOW or MULTIAGENT, using a bearer API key. Save that as your record of every node and setting. The type enum has no separate Agentflow value, so check on a running instance that your agentflows are listed. If yours will not boot, back up its data volume first.
2. Write down the parts. The model and credentials, the document store or vector store, the tools, and whether it keeps conversation memory.
3. Record how it is reached. Flowise exposes a Prediction API and an embed widget, and each caller needs a new target later.
4. Save real questions with the answers you accept. They become your test set in step 4.
5. Mirror what runs today. The notice marks npm packages and Docker images deprecated, so keep a copy of the version that works.

Step 2: Map each Flowise piece to a Dify feature

Dify's docs split apps into Workflow and Chatflow. A Chatflow adds a conversation layer, starts from a user message and must end in an Answer node. A Workflow runs once from input to output and can also start from a Trigger.

Dify names come from docs.dify.ai, Flowise names from docs.flowiseai.com.

Step 3: Rebuild the knowledge base and tools in Dify

Build the knowledge base first, because the Knowledge Retrieval node needs one to exist. Add a model provider that offers an embedding model under Integrations before you upload anything. Then open Knowledge, create a knowledge base from local files, Notion or a website, and set how documents are split into chunks, the index method and the retrieval settings, all in the Knowledge docs. If you are also choosing a new vector store, my vector database comparison and agentic RAG guide cover the retrieval side.

Dify can connect an existing vector store as an external knowledge base, but your service must implement its External Knowledge API, so for most teams ingesting the documents again is quicker. Then rebuild tools and models under Integrations. Count your apps from step 1 against the plan: Sandbox allows 5 apps and 50 knowledge documents, Professional 50 apps and 500.

Step 4: Publish and cut over

1. Publish the app. Dify creates a web app and an API endpoint from the latest configuration, as the publish overview explains. The docs warn that publishing replaces your live app with the current configuration, so test on the canvas first.
2. Replay your saved questions through the web app and compare against the answers you accepted in step 1.
3. Replace the embed. Use the chat bubble script or the iframe for the website widget.
4. Create an API key inside the app and point each caller at it. On Dify Cloud the base URL is https://api.dify.ai/v1 and requests carry the key as a Bearer token. The API guide says to call it from your backend only, never from frontend code.
5. Run both until the answers match, then stop Flowise.

Once an app works, use Export DSL for a backup. The export leaves out third party API keys and the knowledge base content, so keep those separately.

If Dify is not the right fit

Among flowise alternatives, Dify is closest in shape: a visual builder with a knowledge base and a published API. The sunset notice gives the reason Flowise stopped: rigid low code workflows hit a limit as developers move to coding agents. That applies to Dify too, so use it for apps that stay simple. If your Flowise flows were mostly automation around one model call, n8n often fits better. Flowise vs n8n covers that move, and Dify vs n8n helps you choose between the two platforms still shipping. The three way comparison puts all of them in one table. For agents written as code, start with how to build an AI agent.

If you want a hand with a Flowise to Dify rebuild, see how I build AI agents or send me your flow list.

Frequently asked questions

Is Dify better than Flowise?

For new work, yes, mainly because only one is maintained. Dify shipped 25 releases in the 12 months to Oct 23 2026. Flowise was archived on Aug 13 2026 and has six security advisories with no patched version. I did not run Dify, so this rests on its docs and repository, not a feature test.

Can I import a Flowise chatflow into Dify?

I found no way to. Dify imports its own DSL, a YAML file, and I found no Flowise converter in the Dify docs or in a web search. Rebuild each flow by hand in a Chatflow or Workflow, and ingest the documents into a Dify knowledge base again.

Is Dify free to self host?

The Community edition is free, and the pricing page lists it as a single workspace. The licence is a modified Apache 2.0 that bars running a multi tenant service, where one tenant is one workspace, without written permission. The docs ask for 2 CPU cores and 4 GiB RAM.

What is the best Flowise alternative?

It depends on the app. Dify is closest for chatflows with a knowledge base, n8n for flows that are mostly automation around a model call, and code frameworks for agents with custom logic. See Flowise vs n8n and Dify vs n8n.