最近社区里关于 Flowise 停止运营的消息传得比较快很多正在用它搭建 LLM 应用、做 RAG 问答、做内部知识库的开发者都有点慌。先说结论就算 Flowise 官方后续停止维护或关闭云服务只要你用的是开源版本并且提前做好备份和自托管迁移之前搭建的流程和应用大概率能继续运行。这篇文章不是追热点而是基于“Flowise 可能关停”这件事整理一套能落地的应对方案包括影响评估、数据备份、自托管部署、迁移到替代平台的操作步骤以及常见的坑点和工程建议。内容适合三类读者正在使用 Flowise Cloud 或官方 Docker 镜像的开发者。在 Flowise 上搭了生产级 Agent、RAG、客服机器人的团队。想趁这次机会重新梳理 LLM 应用编排方案的技术负责人。1. Flowise 是什么为什么要关注关停消息1.1 Flowise 解决了什么问题Flowise 是一个基于 Node.js 的开源低代码平台本质上是把 LangChain.js 的能力可视化、拖拽化。你可以在浏览器里通过“拖节点、连线条”的方式快速搭建聊天机器人。文档问答 / RAG 知识库。多步骤 Agent。提示词工作流。PDF、网页、数据库等数据源的加载与处理。相比直接写 LangChain 代码Flowise 最大的优势是“改流程不需要改代码”。业务人员可以微调提示词和模型参数开发者只需要把 API Key、数据源和模型配置好。这也是它在前两年快速流行起来的原因。1.2 “关闭”可能影响的三种情况我们需要把“Flowise is shutting down”拆成几种不同情况看因为影响范围完全不一样。情况影响对象影响程度Flowise Cloud / 官方托管服务关闭使用云端账号的用户高需要立刻备份和迁移GitHub 仓库停止维护自托管用户、二次开发者中代码仍可运行但缺少更新和安全修复社区和官方支持停止所有用户中问题排查需要靠社区或自己解决现在很多用户其实是在自己的服务器上用 Docker 跑的 Flowise并不依赖官方云服务。这种情况下即使公司层面关停本地部署的实例依然可以继续跑只是不能再从官方仓库拉取新代码和安全补丁。1.3 开源项目不等于“马上不能用”Flowise 以开源协议发布具体协议类型要以项目仓库里的 LICENSE 文件为准。只要协议允许你已经下载或分叉的代码就可以继续使用。哪怕官方仓库后续删除、归档或停止维护只要在迁移之前把源码和用户数据完整保留下来应用仍然属于你。所以面对这个消息最不应该做的两件事是什么都不做等官方停止服务后再想办法。直接把线上节点删掉重来。正确的做法是先评估影响范围再备份再迁移。2. 收到关停消息后第一时间先做影响评估2.1 先确认你的使用方式先回答以下三个问题答案决定你接下来的优先级。你用的是 Flowise Cloud还是自己部署的 Flowise你的流程里是否接入了外部数据库、向量数据库或第三方 API这些流程是否承载着线上业务流量如果你用的是 Flowise Cloud那么优先级最高因为云端数据不在你手里。如果你用的是 Docker 自托管那么核心任务就是备份配置和数据库以及确定后续继续使用哪个版本。如果你只是本地测试、学习那压力会小很多但也可以顺手把流程导出 JSON 保存下来避免以后找不到参考资料。2.2 紧急检查清单建议按下面清单逐项检查[ ] 登录 Flowise 控制台确认当前项目和流程数量。[ ] 检查哪些流程使用了 API Key、模型 Key、数据库连接串。[ ] 检查聊天历史、对话记录、文档索引存储在哪里。[ ] 确认是否有定时任务、Webhook、外部系统依赖 Flowise 接口。[ ] 导出所有流程 JSON 文件并保存到本地仓库。[ ] 保存环境变量和 Docker Compose 文件。这里特别提醒不要只保存流程截图。流程 JSON 才是可以恢复的源文件截图只适合做文档说明。2.3 弄清楚密钥、模型账号和数据库Flowise 本身不训练模型也不保存你的大模型 API Key。它只是一个编排层调用 OpenAI、Azure OpenAI、本地 Ollama、Hugging Face 等模型服务时需要读取你配置的 API Key。这些 API Key 通常保存在Flowise 的环境变量中。Flowise 后台的“Credentials”里。外部密钥管理服务中。如果 Flowise 关闭导致你无法访问后台部分密钥可能无法找回。所以建议把模型服务商的 Key 都去对应平台重新生成或记录到安全位置但注意不要把密钥直接提交到 Git 仓库。3. 完整备份 Flowise 应用数据备份是迁移的第一步也是最容易出错的一步。下面按数据类型展开。3.1 工作区数据和对话记录Flowise 的流程、节点、对话记录默认情况下会写入 SQLite 数据库。如果你是 Docker 安装数据库文件通常挂载在~/.flowise目录下本地安装则可能位于用户目录下的.flowise文件夹。备份方式很简单把整个.flowise目录复制一份。示例命令# 假设容器名为 flowise docker cp flowise:/root/.flowise ./flowise-backup-$(date %Y%m%d) # 或直接备份宿主机目录 cp -r ~/.flowise ~/flowise-backup-$(date %Y%m%d)如果数据量大也可以先压缩再备份tar -czvf flowise-backup-$(date %Y%m%d).tar.gz ~/.flowise备份完成后检查目录里是否存在index.db或类似的 SQLite 文件确认大小非零。3.2 导出流程 JSON在 Flowise UI 里每个流程的右上角一般有导出或复制功能。你可以在流程详情页中找到 “Export” 按钮生成一个 JSON 文件。注意导出的 JSON 只包含流程结构、节点参数、提示词内容不一定包含已经存入向量数据库的文档分块。所以如果你使用了 Pinecone、Qdrant、Chroma、Weaviate 这类外部向量库还要单独备份向量库中的数据。导出的 JSON 建议放到 Git 仓库或对象存储里命名规则要规范例如flowise/export/20250601/客服知识库-workflow.json flowise/export/20250601/销售助手-workflow.json如果流程数量很多可以逐个导出也可以写一个简单脚本调用 Flowise API 批量导出。不过 API 路径和参数在不同版本差异较大这里只提供思路不写死具体接口以避免版本不兼容。3.3 备份外部存储和向量数据库如果流程中使用了外部向量数据库需要单独处理Pinecone在控制台导出索引配置记录 namespace、维度、度量方式。Qdrant备份 collection 数据或使用 snapshot 功能。Chroma复制本地持久化目录。Redis如果聊天历史存在 Redis需要执行SAVE或BGSAVE确保持久化。很多用户以为导出了流程 JSON 就万事大吉实际上向量库里的文档向量才是 RAG 回答质量的核心。没有向量数据恢复的流程只是一副空壳需要重新灌入文档。3.4 备份密钥和配置把 Flowise 启动时用到的环境变量整理成一个.env文件示例。不要把真实密钥写进博客但在你自己的工作目录里必须留一份安全副本。最小环境变量示例PORT3000 DATABASE_PATH/root/.flowise APIKEY_PATH/root/.flowise SECRETKEY_PATH/root/.flowise FLOWISE_USERNAMEadmin FLOWISE_PASSWORDyour-strong-password说明DATABASE_PATH指定 SQLite 数据库所在目录。APIKEY_PATH保存 API Key 加密数据。SECRETKEY_PATH保存用于加密密钥的主密钥。FLOWISE_USERNAME和FLOWISE_PASSWORD用于后台登录认证。这段配置在自托管时需要保持一致否则登录状态和密钥可能失效。4. 自托管部署把 Flowise 装到自己的服务器备份完成之后最稳妥的方案是在自己的服务器上部署一套 Flowise继续维持现有的业务。自托管不代表永远不需要更新但至少不会因为云服务关闭而立即停机。4.1 自托管能获得什么自托管 Flowise 带来的核心好处有三个数据完全可控流程和数据库都在自己手里。模型调用依然走你的 API Key不依赖 Flowise 官方中转。可以固定版本运行不担心上游强制升级。需要注意的是自托管不等于彻底隔离。如果你正在使用外部依赖组件比如 LangChain 集成的一些第三方服务这些服务本身的版本接口变更仍可能影响你。4.2 Docker Compose 部署示例下面给出一份完整的 Docker Compose 配置。实际部署前请确认你的服务器已经安装 Docker 和 Docker Compose。version: 3.8 services: flowise: image: flowiseai/flowise:latest container_name: flowise restart: always ports: - 3000:3000 environment: - PORT3000 - DATABASE_PATH/root/.flowise - APIKEY_PATH/root/.flowise - SECRETKEY_PATH/root/.flowise - FLOWISE_USERNAMEadmin - FLOWISE_PASSWORDchange-me - DEBUGfalse volumes: - ./flowise_data:/root/.flowise command: /bin/sh -c sleep 3; flowise start这里有几个关键点image: flowiseai/flowise:latest只是示例生产环境建议固定到验证过的具体版本号避免latest漂移导致不兼容。volumes把容器内的/root/.flowise映射到宿主机./flowise_data这样流程和数据库不会随着容器删除而丢失。FLOWISE_PASSWORD强烈建议通过环境变量注入而不是直接写死在 Compose 文件里。4.3 环境变量配置把上面的environment提取到.env文件更方便管理。示例PORT3000 DATABASE_PATH/root/.flowise APIKEY_PATH/root/.flowise SECRETKEY_PATH/root/.flowise FLOWISE_USERNAMEadmin FLOWISE_PASSWORDchange-me然后在 Docker Compose 中引用env_file: - .env注意SECRETKEY_PATH如果变化可能导致旧的加密 API Key 无法解密。所以迁移时最好保留原始环境变量不要随意修改主密钥。4.4 启动与验证在服务器上执行docker compose up -d docker compose logs -f flowise如果日志中出现端口监听和启动完成的信息就可以通过浏览器访问http://服务器IP:3000登录后台后先不要创建新流程先尝试导入之前导出的 JSON确认流程节点是否完整。4.5 数据恢复如果你备份了整个.flowise目录恢复更简单停止新容器。把备份的.flowise目录内容复制到宿主机./flowise_data。重新启动容器。检查流程列表和聊天记录是否完整。示例命令docker compose down rm -rf ./flowise_data cp -r ~/flowise-backup-20250601/.flowise ./flowise_data docker compose up -d恢复后登录后台查看流程和凭据是否还在。如果密钥丢失则需要重新录入 API Key。5. 迁移到其他可视化编排平台自托管 Flowise 能解决大部分问题但如果你担心项目长期停滞或者团队希望换到维护更活跃的平台可以考虑迁移。市面上比较流行的替代方案有 LangFlow、Dify以及更通用的 n8n。下面逐个分析。5.1 如何评估迁移方案没有完美的迁移方案关键看你的业务特征。评估时关注五个维度流程复杂度是否用了大量自定义 Python/JS 节点。RAG 完整度是否依赖内置文档加载和向量库管理。对接成本是否需要接入已有的数据库、消息平台、企业系统。运维熟悉度团队更熟悉 Python 生态还是 Node.js 生态。长期维护意愿项目社区活跃度、版本发布频率。5.2 迁到 LangFlowLangFlow 同样是可视化拖拽平台不过它基于 Python底层是 LangChain 的 Python 版本。如果你的团队以 Python 为主LangFlow 会比较合适。迁移时重点做三件事手动对照原 Flowise 流程在 LangFlow 中重新搭建节点连线。把提示词内容复制到对应组件中。重新配置模型 API Key 和向量数据库连接。由于两个平台的数据模型不通用很难做到一键导入。建议先把业务流程图绘制清楚再在目标平台逐个复刻。流程图建议用文字或表格记录方便团队核对。5.3 迁到 DifyDify 更适合做产品化的 LLM 应用尤其是 RAG 和 Agent 功能。它自带知识库管理、模型管理、日志观测和应用发布对非技术人员的友好度也比较高。迁移时重点关注知识库文档需要重新上传并切成向量。应用配置模型、提示词、对话开场白、功能开关。外部 API如果原来通过 Flowise API 对外提供服务要调整网关和调用地址。Dify 和 Flowise 都可以用 Docker Compose 部署运维模型类似迁移时可以先在测试环境把新应用跑通再切换线上流量。5.4 继续用 n8n LangChainn8n 本身不是 LLM 专用平台但它的集成生态更适合自动化工作流。如果你原来的流程偏“定时任务”和“系统对接”用 n8n 加 LangChain 模块会更灵活。这种方案的缺点是搭建门槛更高需要自己编写或组合 LangChain 节点不像 Flowise 那样开箱即用。比较适合有明确工程能力的团队。5.5 迁移流程的核心顺序无论迁移到哪个平台都建议按下面顺序执行先梳理所有线上 Flowise 流程标明用途和依赖。在目标平台搭建同功能流程使用测试模型 API Key 验证逻辑。接入真实模型 Key进行小流量测试。对比回答质量、延迟、失败率。切换正式入口保留旧平台至少两周观察期。确认稳定后再考虑清理旧平台资源。迁移期间不建议同时改多个流程。一次迁移一个核心流程能显著降低无人背锅式事故的概率。6. 常见问题与排查思路6.1 流程图导入报错问题现象在自托管或新平台导入 Flowise 导出的 JSON 时提示格式错误或节点类型不存在。常见原因原版本和新版本 Flowise 节点类型不一致。JSON 文件被编辑器自动转义或截断。导出的 JSON 中包含自定义组件目标环境没有安装。解决思路先用文本编辑器打开 JSON确认是完整结构。如果节点类型不存在需要手动替换为对应版本的节点。对于自定义组件需要在新环境重新安装。6.2 模型调用失败问题现象流程恢复后运行时提示模型 API Key 无效或配额不足。常见原因迁移后没有重新配置 API Key。原 Key 存储在云端没有同步到本地。模型服务商的额度已经到期。解决思路去模型服务商后台检查 Key 状态重新生成并填入 Flowise 的 Credentials 配置中。6.3 自托管页面打不开问题现象Docker 容器启动成功但浏览器无法访问 3000 端口。常见原因服务器防火墙未开放端口。Docker Compose 端口映射写错。服务启动过程中崩溃日志显示数据库路径不可写。解决思路docker ps docker logs flowise如果日志显示权限错误检查宿主机挂载目录权限并给容器内用户授予读写权限。6.4 向量数据库和文档索引丢失问题现象流程导入成功但问答时无法检索到文档内容。常见原因向量数据库没有备份或没有重新灌入数据。解决思路先确认原向量数据库服务是否还可用恢复 collection 快照如果外部向量库已经不可访问需要重新上传原始文档并切分向量。这是最费时间的一步务必提前处理。6.5 环境变量不一致问题现象登录后台后原本的 API Key 全部丢失。常见原因SECRETKEY_PATH指向的主密钥文件和原来不一致。解决思路恢复备份时必须连同SECRETKEY_PATH所在目录一并恢复。如果主密钥完全丢失只能重新录入所有 API Key没有更好的办法。6.6 排查清单遇到问题可以按顺序排查问题现象常见原因解决思路流程导入失败JSON 格式错误或节点版本不兼容检查 JSON 结构对齐版本模型调用失败API Key 未配置或已失效重新生成 Key 并配置页面无法访问端口未开放或容器启动失败查看 Docker 日志和防火墙聊天记录丢失SQLite 数据库未恢复恢复.flowise目录知识库无法检索向量库未恢复恢复向量库快照或重新灌库后台登录不上登录账号密码不一致检查 FLOWISE_USERNAME 和 FLOWISE_PASSWORD7. 最佳实践与工程建议7.1 把流程当代码管理Flowise 的流程本质上是配置数据和代码没有区别。建议把导出的 JSON 放入 Git 仓库并根据版本打 tag。例如flowise-projects/ ├── app/ │ └── customer-service/ │ └── v1.0.0.json ├── app/ │ └── internal-assistant/ │ └── v1.0.0.json └── README.md这样即使 UI 不可用也能基于历史版本重新构建。7.2 密钥集中管理不要把模型 API Key 直接写进 Flowise 流程中。正确的做法是使用 Flowise 的 Credentials 功能保存密钥。对外暴露环境变量注入敏感信息。对密钥文件进行权限控制避免777权限。7.3 固定镜像版本“还能拉镜像”不代表镜像永远不变。建议在 Docker Compose 中固定镜像版本而不是长期使用latest。示例image: flowiseai/flowise:2.1.0固定版本后即使官方仓库后续更新或删除 tag只要你本地有镜像备份依然能启动服务。更稳妥的做法是把镜像docker save导出保存到私有镜像仓库。docker save flowiseai/flowise:2.1.0 | gzip flowise-image-2.1.0.tar.gz7.4 备份策略建议采用“3-2-1”备份策略3 份数据副本。2 种不同存储介质。1 份离线存放。对于 Flowise 来说最小备份集包括全部流程 JSON。.flowise目录压缩包。Docker Compose 和.env文件。向量数据库快照。备份频率建议至少每周一次若业务变更频繁则每天一次。7.5 安全边界Flowise 默认没有内置复杂的用户体系。生产环境部署时建议使用反向代理加 HTTPS。在 Nginx 层配置 Basic Auth 或 OAuth 认证。限制管理端口的来源 IP。不把 Flowise 后台直接暴露到公网。7.6 避免单一供应商锁定借助这次关停风波可以反思一个工程问题你的 AI 应用是否被编排平台绑死了应对方法是把“业务流程”和“底层模型调用”解耦。具体做法尽量使用标准 API 接口封装模型调用。把关键 Prompt 和文档索引数据独立出来。将流程导出文件作为不可变资产定期归档。这样即使未来换平台也能降低重构成本。8. 总结与下一步行动关于 Flowise 关停的消息目前能做的就是尽快把主动权拿回自己手里。核心动作可以浓缩成四步备份所有流程 JSON、数据库目录和密钥配置。在自托管环境部署一套 Flowise并固定镜像版本。对外部模型 API 和向量数据库做二次确认。用一周时间评估是否要迁移到 LangFlow、Dify 或 n8n。如果你手上只有一两个测试流程这整个过程可能只需半天。如果线上跑着几十个流程建议把迁移当项目来做分批次推进。回到这篇文章的初衷技术工具的生命周期很难预测但工程上我们可以通过备份、版本固定、数据和平台解耦把风险降到最低。趁这次消息把 Flowise 的备份和迁移工作补上也许反而是让应用更稳健的一次机会。下一步你可以先做一次完整的 Flowise 备份导出所有流程 JSON然后把容器镜像保存到本地。做完这两件事无论官方后续怎么变化你的核心资产都不会丢。