Flowise закрыт, но код жив: как создали Keelflow после ухода команды разработчиков
Визуальный конструктор Flowise с его 55 тысячами звёзд на GitHub объявил о прекращении разработки. Разработчики посчитали low-code процессами устаревшим в эпоху агентов. Под лицензией Apache 2.0 проект передали сообществу, но простого «форка» оказалось недостаточно: 13% кода, включая авторизацию и роли, было закрытым. Редактор Umine Nagi рассказывает, как энтузиасты очистили репозиторий, переписали систему безопасности и создали Keelflow — полностью открытый наследник, безопасный и готовый к работе в изолированной сети.
# Flowise закрыли, но код жив: как создали Keelflow после ухода команды разработчиков
В июле 2026 года сообщество low-code столкнулось с неожиданной новостью. Команда Flowise, создававшая один из самых популярных визуальных конструкторов для разработки приложений на больших языковых моделях (LLM), объявила о прекращении активной разработки. Обоснованием стали изменения в парадигме создания ПО: разработчики всё чаще доверяют сложные задачи специализированным агентам, а жёсткие low-code-процессы, по мнению авторов, достигли своего потолка.
Проект, собравший около 55 000 звёзд на GitHub и почти 7 миллионов скачиваний Docker-образа, стал символом перехода от простых чат-ботов к сложным агентам с памятью и инструментами. Однако компания не просто закрыла проект, она предложила сообществу продолжить его под открытой лицензией Apache 2.0.
«Ваш код под Apache 2.0. Форкайте.» — так звучит призыв, который парадоксальным образом привёл к необходимости полностью переписать систему безопасности и удалить треть проекта.
Редакция Umine Nagi, следуя методу тихого маяка, отследила путь от объявления о закрытии до появления нового проекта под именем Keelflow. История показывает, что в open source иногда «форкнуть» не просто так: код требует чистки.
Лицензия как ловушка: почему нельзя просто скопировать код
В первый момент могло показаться, что задача проста: зайти в репозиторий и сделать форк. Но внимательный анализ файла LICENSE.md выявил сложную структуру. Хотя основной код открыт, папка packages/server/src/enterprise содержит 130 файлов на TypeScript с общим объёмом более 13 400 строк.
Эти файлы отвечают за:
* Управление организациями и рабочими пространствами. * Систему ролей и прав доступа (RBAC). * Авторизацию через SSO (Single Sign-On) с Google, Azure и GitHub. * Коммерческие функции, доступные по подписке.
Эта часть кода лицензирована отдельно как Commercial License. Её запрещено копировать, публиковать или распространять. Более того, в версии Flowise 3.x бесплатная установка не запускается без коммерческого кода, так как та же система сессий и авторизации зависит от модулей enterprise. Это типичная схема Open Core, где бесплатное ядро критически зависит от платных функций.
Результат однозначен: распространять форк версии 3.x с сохранением всех функций невозможно. Разработчики, принявшие решение, столкнулись с двумя вариантами:
1. Вернуться на версию 2.x, лишившись двух лет новых функций (поддержка agentflow v2, MCP, расписания). 2. Вырезать коммерческий код и написать замену, сохранив актуальность.
Выбор пал на второй путь.
Удаление истории и замена системы безопасности
Просто удалить папку с коммерческим кодом в Git недостаточно: файлы остаются в истории коммитов. Для создания чистого наследника использовался инструмент git filter-repo, который переписал историю репозитория, исключив все изменения, связанные с закрытым кодом. Из 3634 коммитов было удалено 20, касавшихся только коммерческих файлов.
Но главная работа ждала систему аутентификации. Flowise обладал сложной моделью: несколько организаций, рабочих пространств, ролей и приглашений по e-mail. Задача Keelflow, напротив, — обеспечить безопасность в упрощённой модели.
Новая модель доступа
Новый проект Keelflow предлагает минималистичный, но безопасный подход:
* Одна учётная запись владельца: вместо сложных ролей, доступ контролируется одним администратором. * API-ключи: для делегирования прав используются ключи с конкретными правами доступа (например, chatflows:view или documentStores:upsert-config). * Серверные сессии: вместо JWT, требующих чёрного списка в базе данных, используются безопасные токены в cookie с шифрованием SHA-256.
Пароли хешируются через bcrypt. Введены ограничения на попытки входа: 10 неудачных попыток за 15 минут с одного IP или e-mail. Если база данных содержит старые данные Flowise, они будут считываться, но функциональность новых сущностей будет недоступна.
typescript // Проверка прав упрощена до двух строк const hasAny = (req: Request, required: string[]): boolean => { const user = req.user; if (!user) return false; if (user.isOrganizationAdmin) return true; return required.some((permission) => (user.permissions ?? []).includes(permission)); };
Безопасность по умолчанию: что нашлось внутри кода
Процесс пересборки позволил не только удалить закрытый код, но и выявить уязвимости, которые ранее не были видны. В исходной версии Flowise, несмотря на популярность, код не проверялся на наличие сторонних скриптов в интерфейсе.
Удалённые риски
1. Партнёрский трекер: В интерфейсе админки содержался скрипт сервиса Rewardful для отслеживания реферальных ссылок. В самодостаточной установке (self-hosted) это представляло угрозу приватности, так как скрипт мог иметь доступ к данным пользователей, видимым в интерфейсе. 2. Запросы к GitHub: При каждом выборе модели из списка сервер обращался к репозиторию FlowiseAI для получения актуального списка. В изолированных сетях это приводило к ошибкам подключения. Теперь список моделей хранится локально и кэшируется. 3. Уязвимости SSO: В оригинале были найдены критические ошибки аутентификации, связанные с совпадением e-mail между разными провайдерами. В Keelflow, не имея SSO, эти риски устранены.
Работа с зависимостями
Исходный проект содержал 385 зависимых пакета, многие из которых имели известные уязвимости (CVE). После очистки от коммерческих модулей и переписывания кода количество упадо до 153 пакетов.
Список уязвимостей в Flowise был обширным, включая критические версии библиотеки vm2, которая используется для выполнения пользовательского JavaScript в узлах. В Keelflow все зависимости обновлены до безопасных версий, где возможно. Для пакетов, у которых отсутствуют исправленные версии, были найдены форки или альтернативные реализации с сохранением API.
Итог: Keelflow 3.2.0
Результатом работы энтузиастов стал проект Keelflow 3.2.0. Это наследник Flowise 3.1.4, очищенный от коммерческого кода и усиленный безопасностью.
Основные изменения: * Полностью открытый код под лицензией Apache 2.0 без исключений. * Упрощённая система входа: владелец и API-ключи без SSO. * Устранение всех критических уязвимостей, включая проблемы с vm2. * Работа в изолированных сетях без лишних запросов наружу. * Совместимость с базой данных, созданной в Flowise 3.x (при наличии старых данных).
Для развертывания используется Docker-образ, поддерживающий архитектуры amd64 и arm64:
bash docker run -d -p 3000:3000 -v ~/.flowise:/home/node/.flowise ghcr.io/perruer/keelflow:latest
Как и обещалось в начале, проект «держит курс», но уже без корпоративных оков. Киль (keel) судна удерживает его от дрейфа, обеспечивая устойчивость и независимость.
*Иногда, чтобы спасти корабль, приходится не просто починить паруса, а перестроить весь корпус.*