How to Move From Flowise to n8n Now That Flowise Is Archived

Flowise is archived, and the last Docker image I pulled, 3.1.4, exited with code 1 before it served a single request. So for a new build the Flowise vs n8n choice is not close. If you already run Flowise flows, this post shows what moving them to n8n looks like, node by node, what has no clean equivalent, and the case for staying where you are.

This post covers the pair. For the three way view with Dify, read the hub post, Flowise vs Dify vs n8n. For the other two pairs, see Dify vs n8n and Dify vs Flowise. I won't repeat their comparisons here.

Flowise vs n8n in October 2026

The sunset notice set three dates: code freeze on July 29, repository archival on August 10, and end of life on August 31. GitHub's own banner shows the repository archived on August 13, so I use that date in the timeline below.

In fairness, Flowise gave you a visual canvas built for LLM apps, with Agentflow, a Human Input node and an embeddable widget.

The Flowise image that did not boot

I haven't rebuilt a production Flowise flow for this post; the node map below comes from the docs, and the boot test and the n8n footprint are my own runs. On Oct 23 2026 I ran a fresh docker pull flowiseai/flowise:3.1.4 (digest sha256:3922767afb52a5777759fd8b28a3c9eee864daea96018a791f2429eae2a76571, image created 2026-07-29) on an arm64 Mac, with Docker 29.4.0 on Colima. The container exited with code 1 inside seconds. The log carried three errors, and per the issue only the last one is fatal, according to commenters.

• Package path (non fatal per the thread). Package subpath './utils/uuid' is not defined by "exports" in @langchain/core, thrown from @langchain/langgraph-checkpoint while loading the ReActAgentChat node.
• Missing module (non fatal per the thread). Cannot find module '@smithy/eventstream-codec', raised from the AWSBedrock node.
• Session store (fatal per the thread). TypeError: this.db.exec is not a function.

Two limits on this test. It was one run on arm64 only, I did not test x86, and I did not isolate which of the three errors ended the process. But it isn't only my machine: GitHub issue 6688 was opened on 2026-07-30 with the same three errors on a fresh volume, three other commenters hit the same crash, one of them on Windows with WSL2, and it is still open. One commenter says the TypeError is the fatal one and the other two are non fatal packaging errors, and traces it to connect-sqlite3 0.9.17 changing its constructor. Another commenter adds that the dependency is unpinned, so any image built after that release crashes. The final image I pulled did not boot, I can't speak for Flowise in general, and with the repository read only, nobody will fix it upstream.

Staying on the frozen code, and what it costs

You can stay on Flowise, and some teams should. The notice says the Apache 2.0 code stays on GitHub and encourages teams to fork. The price is that every fix is now yours: dependency drift, security patches, and the boot failure above. One more thing to check in a fork: the packages/server/src/enterprise folder sits under a commercial licence.

For anything customer facing or anything you'll extend, I would move, in five steps.

Step 1: List every flow and what it calls

Keep the Flowise instance running and don't upgrade it while you migrate. While it runs, the Chatflows and Chat Message API endpoints let you pull flow definitions and chat history with a script. For each chatflow and agentflow, write one row: how it is triggered (widget, API, or something else), which model it calls, its tools, its memory, its vector store, and whether a human approves anything. I found no Flowise importer mentioned anywhere in the n8n docs index, so plan to rebuild by hand.

Step 2: Map each Flowise piece to an n8n node

Where I couldn't find an equivalent on docs.n8n.io this week, the table says so.

n8n also has an Agents feature, in Preview, that people reach through chat, channels and schedules. I'd keep production flows on the AI Agent node until it leaves Preview.

Step 3: Rebuild tools, memory and the vector store first

Build the parts with state before the chat layer. Two traps in the docs. The Simple Vector Store keeps embeddings in the app's memory, is not persistent, and n8n recommends it for development only. And Simple Memory doesn't work in a production workflow when n8n runs in queue mode, its mode where separate workers run executions.

If your vectors already live in Qdrant, Pinecone or Weaviate, the data stays put. Point the matching n8n node at the same index and keep the same embedding model, or you have to embed everything again. I wouldn't change the embedding model and the platform in the same week, so a quality drop has only one suspect. The vector database comparison covers the store choice, and the n8n RAG workflow guide covers ingestion. Wrap each Flowise tool as its own sub workflow and expose it with the Call n8n Workflow Tool; the sub workflow guide shows how, and the MCP post covers exposing workflows to Claude.

Step 4: Move the chat widget and the API endpoint

Chat Trigger offers Hosted Chat or Embedded Chat, three authentication modes (none, Basic Auth, or n8n User Auth), and an allowed origin (CORS) option on the hosted page. For a website widget I would use Embedded Chat and install the @n8n/chat package. For a machine caller I would build a Webhook plus Respond to Webhook that returns the JSON shape your front end already expects, and set the Webhook node's Respond option to Using 'Respond to Webhook' node, or the response node is ignored.

Billing works differently from Flowise here. The Chat Trigger docs warn that every message executes your workflow, and their own example is that ten messages use ten executions. On the pricing page Starter includes 2,500 executions a month, and 2,500 divided by 10 messages is 250 conversations. Pro includes 10,000, so 1,000 conversations at the same length. Self hosted Community lists no execution allowance.

Source: n8n pricing page, Oct 23 2026. Last column is my arithmetic: executions divided by 10.

Step 5: Add approvals and observability, then cut over

On approvals, n8n lets you require a person to approve or deny a specific tool call, through Slack, Telegram or the n8n Chat interface. It is narrower than Flowise's Human Input node, which can pause a flow and take typed feedback, so such a flow needs a different design. The glossary entry on human in the loop explains the pattern.

On observability, set N8N_METRICS=true to expose a Prometheus /metrics endpoint, and keep it off the public internet, as the docs warn. OpenTelemetry tracing is Preview from n8n 2.19.0, and Log Streaming is listed under Enterprise on the pricing page. Prometheus, OpenTelemetry and LangSmith tracing are documented for self hosted instances, so Cloud buyers get execution history and the debug view instead.

The LangChain in n8n page covers sending traces to LangSmith. Flowise's monitoring page says its own metrics are high level and points to its Analytic integrations for node by node traces, so check what you would lose before you switch.

Cut over by picking about 20 real questions from your exported chat history, sending each to both systems, and comparing the answers and tool calls before you change any traffic. Then switch the widget or webhook URL and keep Flowise up for a week. If you'd rather have the migration built, tested and monitored for you, that is what I do: see how I build AI agents.

What the move costs to run

I measured n8n 2.43.4 (the image already on my machine, a little behind the 2.44.6 release) on arm64 with a 4 GiB VM. /healthz answered 200 in 4.6 seconds after docker run, and the container used 495.1 MiB and 0.84% CPU after 30 seconds idle, on the default SQLite with no workflows. For scope, n8n's Docker Compose guide asks for at least 4 GB of RAM and 2 vCPUs, because that setup includes a sandbox that runs AI generated code in Docker in Docker. Docker listed the n8n image at 1.79 GB, while the Flowise 3.1.4 image reported 9.14 GB on the same machine. Different products and versions, so read that as scale only.

On licensing, n8n's Sustainable Use License allows internal business use and bars selling n8n as a hosted service. Read it before you build a client product on it.

Two chores the docs skip. I found no way to transfer Flowise's stored credentials, so re-enter every API key as an n8n credential, and rotate any key that sat in an exported file. And check your running Flowise version at /api/v1/version, the endpoint the issue thread uses, before you decide which image you really have.

Frequently asked questions

Is Flowise still maintained in 2026?

No. The repository is archived and read only, and the sunset notice set end of life for August 31 2026. The code stays under Apache 2.0, so you can fork it, but upstream fixes have stopped. I'd treat any remaining Flowise instance as something you maintain yourself.

Can I migrate Flowise flows to n8n automatically?

I found no Flowise importer in the n8n docs, so assume a manual rebuild. Chatflows map to a Chat Trigger plus an AI Agent node, tools become tool sub nodes, and vector stores and memory have matching nodes. Plan for new prompts, tool schemas and response shapes.

Is n8n free for client work?

The Community Edition is free to self host, but its Sustainable Use License limits you to internal business use and bars selling n8n as a hosted service. Read the licence text before you build a client product on it.

Does n8n support human approval for AI tool calls?

Yes. You can require a person to approve or deny a specific tool before the AI Agent runs it, and the request can go through Slack, Telegram or the n8n Chat interface. Typed feedback needs another design.

What is the closest alternative if I want to keep a visual agent canvas?

Dify keeps a visual builder and is still shipping releases. I compare the two in Dify vs Flowise, and n8n against Dify in Dify vs n8n. For a general n8n agent architecture, my n8n AI agent guide is the place to start.