“Flowise is shutting down”这个标题最近在好几个开发者群里都引起了讨论。如果你第一反应是“我公司的知识库问答机器人是不是要完了”那我建议你先冷静三分钟。这个标题如果被当成事实传播很容易让人做出错误决策比如立刻停掉生产节点、全员转岗重构或者花大价钱买替代方案。但从目前能看到的信息来看事情的真相和“立即跑路”之间还有很大距离。这篇文章不会去复读那条标题而是想把“Flowise 可能关闭”这件事拆开看这个消息到底意味着什么如果托管服务关了你的应用有多危险如果开源项目停止维护你的数据和代码能不能迁移更重要的是不管 Flowise 未来如何你现在花半小时做的备份和预案能让你在接下来任何类似的“平台风波”中都不被动。这是每个使用低代码 LLM 平台的人都应该补上的工程意识。1. 先把消息本身说清楚托管服务关闭和开源项目停更是两回事先看一个关键区分Flowise Cloud官方托管服务和 Flowise 开源项目是两套独立存在的东西。托管服务是官方在服务器上替你运行的那套环境你只需要在网页上拖拽和部署。而开源项目是发布在 GitHub 上的代码仓库任何人都可以下载、部署到自己的服务器甚至二次开发。这两者的生命周期并不完全绑定。从我目前掌握的信息看Flowise 官方并没有发布正式的“全面关闭”公告GitHub 仓库也没有出现 archived归档或停止维护的标识。所以“Flowise is shutting down”这个说法更可能来自几个不同源头的混合官方可能调整托管服务的策略比如某些区域不再开放新注册团队重心转移到新版本或新商业化产品导致旧托管服务的支持缩水社区用户对项目活跃度下降的担忧被放大竞争对手或自媒体标题党的误读。如果你真的看到了某条公告请务必去确认原文而不是看二手转述。建议按下面四个渠道核实信息渠道怎么看说明GitHub 仓库查看 Releases、Issues、Commit 状态项目是否归档、最近是否有关键提交官网/文档站查看公告栏和服务状态页是否发布服务调整或下线说明npm 包查看flowise包的最后发布时间版本是否还在迭代官方社区群查看维护者发言是否有官方人员回应传闻这里有一个容易误解的地方即使托管服务真的关闭开源项目本身的代码仍然存在。你之前在拖拽界面上画出的 Chatflow本质上是一份描述流程如何连接的数据文件不是只有官方平台才能运行的“黑盒”。只要代码还在你就可以自己跑起来。这件事在后面的自托管章节会有完整方案。真正值得担心的其实是第二种更极端的情况开源项目停止维护。一旦出现这种情况意味着不会再有人修 bug、更新依赖、兼容新的模型 API。你的系统虽然还能跑但会像一艘停在港口的船零件逐渐老化。所以本文接下来的所有内容其实不是针对“Flowise 立刻死亡”的应急而是针对“你是否做好了应对第三方平台不可用的准备”这个通用问题。2. 先理解 Flowise 到底帮你做了什么才知道它关闭后你会失去什么Flowise 是一个开源的低代码/可视化平台用来构建大语言模型应用。你可以不用写太多代码通过拖拽把不同节点连接成一条“流水线”例如用户输入、大模型、提示词模板、知识库检索、记忆、工具调用等。它最典型的应用场景包括企业内部知识库问答、客服机器人、自动摘要、RAG 流水线以及带工具调用的 Agent。Flowise 之所以受欢迎是因为它把 LLM 应用开发的三个核心环节压缩成了可视化操作流程编排不需要理解 LangChain / LlamaIndex 的底层细节也能组装一条可运行的工作流快速交付从原型到可调用的 API往往只需要几个小时特别适合验证产品和给业务方演示低门槛协作非工程人员也能看懂流程图甚至参与 Prompt 调试。但你需要清醒地认识到低代码平台有“低成本起步”和“后续高风险锁定”的双重属性。你用 Flowise 搭建的应用实际上由几部分资产组成资产存储位置关闭后的影响Chatflow / Agentflow 流程定义数据库默认 SQLite高这是核心业务逻辑提示词、模型配置、节点参数数据库高需要迁移或重建API Key、服务密钥环境变量或数据库高需要重新管理和轮换上传的知识库文档本地文件或对象存储中原始文件还在向量数据库数据外部向量库如 Pinecone、Milvus 等中向量索引可重建生成的 API 接口Flowise 服务进程高外部应用依赖它很多团队在使用 Flowise 时最大的失误是把它的数据库当成“不用管的黑盒”。等到要迁移时才发现真正的核心资产是那张流程图背后的一堆 JSON 数据。所以不管消息真假第一步要做的不是卸载而是把数据资产完整盘出来。3. 第一步先备份不管关不关先保住自己的“图纸”在讨论迁移之前我建议你先完成一次完整备份。很多开发者说“我平时数据都存在 Flowise 数据库里”但实际上你自己机器的本地目录、环境变量和生产服务器上的 Docker 卷才是数据真正存在的地方。备份的粒度要覆盖到流程定义、配置文件和上传文件。Flowise 默认使用 SQLite 存储数据在自托管模式下数据目录通常位于用户目录下的.flowise文件夹或者你通过环境变量指定的数据路径。如果是通过 Docker 部署数据会存在于挂载的 Volume 中。在备份前先找到这个目录。# 1. 查看本地数据目录 ls -la ~/.flowise # 2. 查看你可能配置过的数据路径 find / -name *.db 2/dev/null | grep -i flowise找到数据目录后最稳妥的备份方式是先停止 Flowise 服务再整目录打包避免数据库文件被占用导致备份不完整。# 停止容器如果使用 Docker docker stop flowise # 打包数据目录 tar -czf flowise-backup-$(date %Y%m%d).tar.gz ~/.flowise # 重新启动容器 docker start flowise如果你不想停机也可以使用 SQLite 的在线备份功能。注意数据库文件名需要以你本机实际存在的文件名为准可以先在数据目录中查看。# 查看实际的数据库文件名 ls -la ~/.flowise # 使用 sqlite3 在线备份 sqlite3 ~/.flowise/flowise.db .backup flowise-backup-$(date %Y%m%d).db备份完成后建议把备份文件复制到另一台机器或对象存储而不是留在同一台服务器上。否则服务器故障时备份和数据会一起丢失。这一步听起来简单但很多团队真正出事时才发现备份和生产环境在同一个磁盘上根本没有起到保护作用。另外不要忘记备份环境变量。Flowise 并不会把所有的 API Key 都写进数据库有些配置以环境变量形式存在于启动脚本、Docker Compose 文件或运维平台中。如果只备份数据库而丢失了环境变量恢复后的服务可能无法访问原来的模型供应商。4. 自托管把 Flowise 的控制权拿回自己手里如果你担心的是官方托管服务停掉那么自托管是当前最直接的解决方案。Flowise 本身是开源项目你可以通过 npm 或 Docker 轻松部署到自己服务器。这里推荐 Docker 方式因为它对环境隔离更彻底也方便以后整体备份和迁移。下面这个 Docker Compose 示例是通用方法。版本镜像建议固定到你验证过的版本而不是最高版本的latest避免上游升级导致配置不兼容。# 文件路径docker-compose.yml version: 3.8 services: flowise: image: flowiseai/flowise:latest container_name: flowise restart: unless-stopped environment: # 服务端口 PORT: 3000 # 数据库类型支持 sqlite / mysql / postgresql DATABASE_TYPE: sqlite # SQLite 数据存储路径容器内路径需与 volume 一致 DATABASE_PATH: /root/.flowise # 如果启用 API 密钥可配置 FLOWISE_API_KEY # FLOWISE_API_KEY: your-secret-key ports: - 3000:3000 volumes: - flowise_data:/root/.flowise volumes: flowise_data:执行启动命令docker compose up -d启动后访问http://服务器IP:3000如果能出现 Flowise 的拖拽界面说明自托管成功。然后你可以把之前备份的数据目录映射到新容器或者通过界面的导入功能恢复流程。自托管还有一个容易被忽略的好处你可以锁定版本。官方托管服务一旦调整版本你的工作流可能突然不兼容。而自托管环境下只要当前运行正常你可以完全不升级继续运行几个月甚至几年。这相当于把“外部平台变更导致服务异常”的风险降到了最低。不过要注意自托管也有自己的维护成本。你需要负责服务器的安全补丁、磁盘监控、数据库备份和服务重启。对于小团队来说这是可以接受的成本对于没有运维资源的个人开发者可能需要评估一下是否值得。5. 如果项目真的停止维护有哪些迁移替代路线如果最坏的情况发生Flowise 开源项目停止维护你的应用仍然有几个可选的迁移方向。关键不是“换一个看起来差不多的平台”而是评估迁移成本。主流的低代码 LLM 平台有 Dify、LangFlow、n8n 等如果你更倾向直接控制代码也可以基于 LangChain、LlamaIndex 自行开发。各自特点如下方案类型适合场景迁移难度Dify开源低代码 LLM 平台知识库、Agent、工作流社区生态活跃中概念接近 FlowiseLangFlow开源可视化 LangChain 编排熟悉 LangChain 组件的团队中高组件映射需要理解n8n通用自动化工作流需要和跨系统业务系统集成的场景高LLM 原生能力不如前两者自研LangChain / LlamaIndex代码开发稳定期产品、需要深度定制高但可彻底摆脱平台依赖在迁移前你需要先把自己原来在 Flowise 里设计的流程“翻译”成目标方案能理解的结构。比如一个简单的知识库问答 Chatflow通常由这几部分组成用户输入节点知识库检索节点连接向量数据库上下文组装节点把检索结果拼进 PromptLLM 生成节点输出节点。在 Flowise 界面里这是几条连接线在代码方案里这就是一次 RAG 调用的完整逻辑。下面是一个使用 LangChain 复刻该流程的最小示例帮你理解“脱离平台后核心逻辑长什么样”。# 文件路径rag_example.py # 使用 LangChain 实现一个最小的 RAG 问答流程 from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain.chains import RetrievalQA # 1. 加载本地知识库文档 loader TextLoader(knowledge.txt) documents loader.load() # 2. 对文档做切分 splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) docs splitter.split_documents(documents) # 3. 向量化并写入本地向量库 embeddings OpenAIEmbeddings() vectorstore FAISS.from_documents(docs, embeddings) # 4. 构建检索问答链 llm ChatOpenAI(modelgpt-4o-mini, temperature0) qa RetrievalQA.from_chain_type(llmllm, retrievervectorstore.as_retriever()) # 5. 执行问答 result qa.run(Flowise 停止维护后我的知识库系统还能用吗) print(result)这个例子的价值在于它把 Flowise 里一个 Chatflow 的完整逻辑用代码表示了出来。迁移到代码意味着你不再依赖任何低代码平台但同时也意味着以后的功能改动都需要开发人员参与。如果你的团队里有开发资源这反而是长期最稳妥的路线。6. 关注 API 依赖你的对外服务到底是怎么连上 Flowise 的很多人在意 Flowise 界面会不会关闭却忽略了一个更致命的问题线上应用可能正在通过 Flowise 提供的 API 对外提供服务。比如你有一个微信客服机器人后端将用户消息转发给 Flowise 的预测接口再由它返回答案。一旦 Flowise 服务停掉你的客服机器人会立刻失效这比“界面打不开”严重得多。在 Flowise 中每一个 Chatflow 都可以通过POST /api/v1/prediction/{chatflowId}这样的接口对外提供预测能力。调用方式通常是在请求头中加入 API Key。下面的示例展示了一个典型的调用方式具体鉴权字段以你部署版本的官方文档为准。# 文件路径call_flowise.py import requests FLOWISE_BASE_URL http://localhost:3000 CHATFLOW_ID your-chatflow-id API_KEY your-api-key resp requests.post( f{FLOWISE_BASE_URL}/api/v1/prediction/{CHATFLOW_ID}, json{question: 你好请介绍一下你们的服务}, headers{Authorization: fBearer {API_KEY}}, timeout30, ) print(resp.status_code) print(resp.json())如果你的外部应用是这么在调 Flowise那你需要对它做“解耦”。思路是不管 Flowise 是否关闭都不要让业务代码直接强依赖某个平台特有的 API 路径。一个比较实际的做法是在 Flowise 前面加一层自己的 API 网关或者把调用封装在一个独立模块里。这样即使将来替换为其他低代码平台甚至换成自研代码业务层不用大改。更进一步如果 Flowise 停了这类代码可以直接替换为调用大模型的官方 SDK。以下是等价的直接调用方式# 文件路径call_llm_direct.py # 不再依赖 Flowise直接调用大模型 API from openai import OpenAI client OpenAI(api_keyyour-api-key) resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一个知识库问答助手。}, {role: user, content: 你好请介绍一下你们的服务}, ], temperature0, ) print(resp.choices[0].message.content)这段代码看起来比 Flowise 方式更“简陋”因为它没有知识库检索、没有记忆、没有工具调用。但它是你能掌控的最底层能力。迁移时你可以从这一层逐步加上向量检索、Prompt 模板和工具调用最终形成自己的服务。这样做的好处是以后任何低代码平台变化都不会再影响你的核心业务。7. 常见问题与排查思路在备份、自托管和迁移过程中你可能会遇到一些典型问题。下面整理了一份排查表。问题现象可能原因排查方式解决方案Docker 容器启动失败端口被占用或镜像拉取失败执行docker logs flowise查看日志更换端口、清理旧容器、重新拉取镜像页面打不开白屏前端静态资源加载异常或版本升级不兼容打开浏览器开发者工具查看 Network 面板清理浏览器缓存锁定镜像版本重新部署调用 Flowise API 返回 401API Key 未配置、请求头字段错误检查环境变量是否设置了 FLOWISE_API_KEY检查请求头名称在 Compose 文件中补配置按官方文档修正请求头恢复备份后流程缺失或报错数据库版本不一致或备份不完整对比备份文件大小检查日志中的模型名称恢复到与备份时一致的版本重新检查流程依赖的模型数据目录找不到使用 Docker 挂载卷后路径变化执行docker inspect flowise查看 Mounts 信息按容器内的实际路径查找数据或导出 Volume 内容向量库连接失败向量数据库地址或密钥未同步迁移检查外部向量库的运行状态和访问白名单在 Flowise 节点中更新向量库连接参数遇到问题时一个常见的排错顺序是先看服务日志再看网络连通性最后检查配置。不要一开始就怀疑“Flowise 是不是把数据删了”大多数问题出在版本和路径不匹配上。8. 最佳实践与工程建议经历过这次“Flowise 要关闭”的讨论我更建议团队把这套“防锁定”思路固化成日常工程规范而不是只做一次性应急。第一给 Flowise 定版本并固化镜像。生产环境不要追新每次升级前先在测试环境跑一遍。升级的重点不是“新功能多酷”而是“旧流程是否还兼容”。把版本号写进 Docker Compose 文件并且和业务代码一起纳入 Git 管理。第二数据资产定期备份。至少每周做一次完整备份并把备份文件放到独立存储。备份下来后还要定期做一次恢复演练。只有真正跑通过恢复流程备份才有意义。第三不要在 Flowise 里存“无法导出”的核心配置。比如 Prompt 模板、系统提示词、API Key 等重要信息建议用文档或代码仓库统一定义再配置到 Flowise 中。这样即使整个平台消失你仍然有一份可以复用的文字资产。第四为外部 API 增加超时、熔断和降级。如果你的应用通过 Flowise API 对外提供服务一定要在网络调用上设置合理的超时时间并预留降级方案。比如 Flowise 不可用时直接返回固定的兜底文案而不是让用户请求一直挂着。第五关注社区和官方动态但不要被标题带节奏。可以在仓库设置中关注 Release 推送定期查看 issues。只有当官方发布正式公告时才需要触发迁移预案。9. 下一步花 30 分钟做一次“压力测试”说回最初的问题。Flowise 是不是真的要关闭目前还没有官方实锤。但这件事确实是一个很好的提醒你在多大程度上能容忍“第三方平台突然不可用”如果你的回答是“不能容忍”那么现在就应该花 30 分钟做下面三件事找到 Flowise 的数据目录执行一次完整备份用 Docker 在本地或一台测试服务器上把 Flowise 跑起来验证自托管流程把你的核心 Chatflow 按“节点拆分”的方式在文档里梳理成可迁移的逻辑清单。做完这三件事无论 Flowise 的未来是继续更新、停止维护还是被收购后改变方向你都有应对的底牌。真正的工程安全感不来自某一个平台永远活着而来自你随时能把业务从平台上迁走的备份和预案。